Bootstrapping = GCC segfaults

[joaopft]

Had problems with this board while bootstraping. 32 bit operating systems (windows, linux) are OK. I think gcc running on AMD64 stresses memory subsystem a lot more than any stress tests running in a 32 bit environment, so hardware problems reveal themselves in AMD64.

Later, I got Crucial Ballistix PC4200 memory and the problem went away. Then the problem returned when I overclocked the system (to try to run memory at its spec clock speed, which is 500 MHz).

I eventually solved the problem by putting memory slightly below specs.
_________________
Fiction is obliged to stick to possibilities. Truth isn't.
Mark Twain

[deepspace9]

Hi there,

I just got my brand new AMD64 X2 system this weekend. After installing the hardware:

- Geil Ultra-X PC3200 400MHz CL2 5-2-2 DDR
- MSI K8N Neo4 FI
- X2 3800+

All default settings, with the 2005.1 livecd. At first I found out that one of the memory sticks is bad, the other one ran just fine after a long night of memtest86. But still, emerge sync segfaults, gcc segfaults, glib segfaults... This is just crap! The emerge segfault was a kernel setting, I found that in another topic, but the other segfaults still remain.

Since the liveCD kernel seems to be kind of sucky, i'll try an "experimental" liveCD tonight. I'll also try some of the voltage and timing tweaks, but I'm not really convinced that that will help me much I'll also try the "noacpi" option.

And if it's memory, what memory will work for sure? I mean, this should work just fine... Are there compat lists? And why do all there crappy errors never occur on systems running Windows for instance? Memory pattern of compiling can't be that special, and even if so, the controller should easyly be able to cope with it...

Well, I'll keep you posted!

[BlueByte]

i got the same problem! i cant compile gcc 3.4.4 nor glibc. Im running amd64 athlon 3500+ and dfi nf4 sli-d

[pafisher]

I had the same problems trying to bootstrap the 2005.1 and 2005.1-r1 CDs on two of my three Athlon64 (X2 & Opteron 175) systems. My experience is that the problems were not anything to do with my hardware/bios, as many have suggested in this thread, but instead with the kernel used in the livecds (2.6.12-rx). (I saw the lost ticks and segfault issues.)

My suggestion to anyone having problems is to do the following:
0) Boot the livecd.
1) Install with stage3 onto the target disk.
2) Build the 2.6.14-rx kernel (I've used r2 and r4 successfully)
3) Emerge any *critical* system utilities missing
3) Reboot to the new kernel
4) emerge -e system && emerge -e system
5) Continue doing whatever you normally would do

The point is to do as little as possible on the livecd kernel (above just builds genkernel, the kernel, and system utilities), and then continue on the new kernel. This worked for my on several different hardware combinations.

If a 2005.1-r2 livecd was released with the 2.6.14 kernel, many of the problems people are experiencing would go away.

paul
_________________
paul

[viniciusferrao]

This is ridiculous, but I solved this problem setting Command Rate Off (yes, 2T)

I don't know why this... in 32bits envy 1T is just fine at 260MHz (what I use), in 64bits envy not even stock hardware setting, not even UNDERCLOCKED settings compiles gcc 3.4.4...

Compile was only successfull with 2T timing

My box:
DFi NF4 Ultra-D
Winchester 3000+ at 260x9 = 2340MHz @ 1.55V (sucks hard, 0509 LBBID stepping)
2x512Mb OCZ EL Rev2 PC3200 2-2-2, Samsung TCC5 chips

[]'s

[Bushmann]

Very strange indeed. I tried to convert my system to amd64 yesterday (used 32bit before), and run into the same problem. I have a DFI Lanparty UT Ultra and compiling gcc fails always at the same line.
Yes my system is overclocked, but that shouldn't be the problem since it's been running stable for months, passed all stresstests, is below the limit and ran fine under 32bit. Also it's no random crash but always the same error.
I'm a bit irritated as to why amd64 seems not to work while x86 did fine, and think I'll switch back to 32bit if I can't get this to work.

[pafisher]

I've had no problem since getting my system to a recent kernel (>= 2.6.14). The problem was getting there from the 2005.1 install.

pau
_________________
paul

[viniciusferrao]

[Ohmay]

Same problem here, with one difference. My box is an ancient Pentium 200 MMX, so i dont think that this is a amd64 specific problem. Perhaps compile in a different machine using distcc do the job. What do you think?

[PaladinOfKaos]

I've read every post I can find on the subject, and I've decided that this is mostly a glibc-2.3.5 issue. (or perhaps just a one-day-later issue, as happens sometimes).

One thing that's somewhat important to this conclusion is that I'm running a Pentium 4 (prescott), on a 925-based ASUS board. Everything that I've read about this has been on AMDs.

So, after fighting with glibc 2.3.5 for all of sunday, I let memtest86 run overnight, which ended with about 15 passes, and no errors. Moving on.

Monday, I decided to try the unstable branch. I fixed make.conf to accept ~AMD64, and re-started the whole bootstrap process. glibc-2.4 was selected. It told me that it no longer supported pthreads, so I needed to set the nptlonly use flag (so applications wouldn't default to the non-existant pthreads, perhaps?)

I set the flag, and restarted. It worked, even though the gcc that was running had been compiled against the exact same glibc as before (the 2.3.5-r* that came on the live CD). GCC isn't recompiled agains the new glibc until emerge system.

So, why did 2.3.5 segfault, but not 2.4? my best guess is that 2.3.5 has broken pthreads support, which the nptlonly flag would have made irrelevent. I'm going to finish the setup today (I only had time to bootstrap last night, I still need to emerge system). If everything works, I'd say just go for it. 2.4 is considered stable by it's developers, if not by the gentoo teams yet. There shouldn't be any major problems.

One thing about 2.4, though. It's not binary-compatible with 2.3.*, so you'll have to rebuild everything if you want it to use 2.4. I would expect that 2.3.* should still be on your systemsince gcc would break if it wasn't, and then you couldn't re-build anything against 2.4

edit: some grammar and clarification