Buildworld fails -- always on same spot

G

GeorgeLinn

I am trying to upgrade 8.0 release to 8.1 stable and my buildworld fails in the same exact spot each time. I initially used cvsup to update the src tree from 8.0 to 8.1. After a few failed buildworlds I removed the src totally and ran cvsup with an empty /usr/src, buildworld failed after that too.

The system actually reboots when the buildworld fails. The last few lines of the buildworld putty session shows:

Code: 
cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" -
I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H   -
I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/genautomata.c
cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" -
I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H   -
I/usr/obj/usr/src/tmp/legacy/usr/include  -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o genautomata genautomata.o rtl.o read-rtl.o ggc-none.o 
vec.o min-insn-modes.o gensupport.o print-rtl.o errors.o libiberty.a -lm
./genautomata /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config/i386/i386.md insn-conditions.md > insn-automata.c
 
I removed everything under /usr/obj and I'm running a make cleanworld && make cleandir and will continue with [cmd=]make buildworld[/cmd] I'll keep my fingers crossed.
 
Pump the output through tee(1) (something like # make buildworld | tee /var/tmp/buildworldoutfile) so hopefully you'll get something slightly more meaningful when(if) it barfs. Also, make sure you have any and all -j turned off, else none of your output will be human readable.

I'm betting on hardware overheating, but I'm only staking 2.113 millibeers on it, so I'm not that confident.
 
After removing everything under /usr/obj and running [cmd=]make cleanworld && make cleandir[/cmd] the process failed in the exact spot as my original post.

I ran the exact process again, this time dumping the output of the buildworld process to a text file, the process failed in the exact spot again according to what was displayed in my putty session, but the end if the text file showed the following:

Code: 
cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" -
I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H   -
I/usr/obj/usr/src/tmp/legacy/usr/include  -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o genconstants genconstants.o rtl.o read-rtl.o ggc-
none.o vec.o min-insn-modes.o gensupport.o print-rtl.o errors.o libiberty.a -lm
 
When using script, here is the that last few lines captured before the process stops and the system reboots:
Code: 
cc -O2 -pipe -I. -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" -
I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_tools/../cc_tools -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -
I/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H   -I/u
 
If your system is rebooting my first suspicion is either insufficient cooling, or bad power supply. What kind of system do you have? Many CPUs reboot themselves when they're overheating.
 
It is a dual processor Compaq DL 320 or 360 pentium III with ~ 1 gig of RAM. My machine never reboots at any other time besides the buildworld process. If it were a bad piece of hardware or heating issue, that would not explain why the buildworld process fails at the exact-same-spot each time, I would think the crashes would be a bit more random during the buildworld process. No?

I guess I will just install 8.1 from scratch and then try a buildworld and see if I run into the same issue...

Thanks.
 
*IF* you can underclock the machine in the bios, even
slightly, that *may* fix the buildworld issue. (Just in
case it occurs also on 8.1)
 
Buildworld fails

Could you post the contents of your /etc/make.conf ?
I have found that buildworld often succeeds only with an empty /etc/make.conf file. Any customizations can trigger errors.
Strangely enough, you can often set custom options while doing a buildkernel without problems.
Good luck.
 
My /etc/make.conf file just has

Code: 
PERL_VERSION=5.8.9

I tried # make –j1 buildworld thinking this would throttle the build process, but that did not help.

I also disabled one of the CPU’s by adding
Code: 
hint.lapic.0.disabled=1
to /boot/loader.conf and while that did disable one of the the CPU's it did not help the build process.

Lastly I tried limiting the amount of RAM that FreeBSD uses to 384M by adding
Code: 
hw.physmem="384m"
to /boot/defaults/loader.conf and that failed to help the make buildworld process too.

I will install 8.1 tomorrow and see if the # make buildworld process works.


Thanks!
 
I installed 8.1 from CD and that went fine. Before getting around to a buildworld
I tried installing some ports that were installed in 8.0, the smaller ports installed fine, but the first port that compiled for more that 10 minutes crashed the machine. It must be failing equipment. Thanks for your time everyone. Much appreciated.

George
 
BTW another alternative to underclocking is installing a
pci-slot exhaust fan. (Worked here for a long while,
seemed to halve the spontaneous reboots). (If your computer
case has not enough airflow near the CPU).
 
Ok. I took the machine apart and cleaned out a bunch of dust bunnies and removed (2) 128MB sticks of RAM, leaving in a single 512MB stick. I can now compile all of my usual ports and buildworld completes too! I initially did not think this was RAM related because of the way buildworld was failing in the exact place over-and-over, I was convinced it was something being caused by the build process itself.

After thinking about this problem knowing the cause was bad RAM it makes sense to me now. After the OS loads, and the services load, there is not much else at all being executed or loaded on the machine, very static situation. This is why the buildworld process failed in the same spot over-and-over. During the troubleshooting process, if I had executed\loaded anything additional\different prior to the each subsequent buildworld test, the machine would have consumed additional RAM prior to the build process and failed sooner each time because the bad area in the RAM module would have been reached quicker, causing the machine to reset at earlier locations while building world.

Long live my Pentium III. Thanks again everyone.
 
You must log in or register to reply here.
Back
Top