Install from stage1, segm.fault at emerging gcc at bootstrap

[FDK]

I want to build my gentoo from stage1, when i make bootstrap.sh i has error segmentation fault at emerging gcc =\
_________________
Dell Lattitude D610 & gentoo box: Gigabyte PC1000 MB (VIA C3 800Mhz) + 512Mb RAM + 1Gb IDE Flash

[ansient]

do this instead: http://forums.gentoo.org/viewtopic-t-319349.html

[ShadowHawkBV]

Have you tested your RAM with memtest95 for a minimum of 3 hours?
Is your CPU overclocked?
Does it happen everytime you run bootstrap.sh or is it a one off error?

I'd personally avoid doing the stage 1/3 install. But that's just my opinion. (It gets a working system faster, but takes longer to get a truly optimized system)
_________________
This space for rent... Well maybe to give away.. Heck.. i'll pay you to take it.

Lost Linux Neophyte
AMD Phenom(tm) II X4 955
Socket 939 AMD64X2 4200,
Intel Core i7-2670QM
Intel Core i5-2557M
Pure 64bit frustration

[ansient]

[dhduvall]

FDK, what errors are you getting?

My gcc compile dies in exactly the same spot each and every time -- when using the stage1 (gcc stage1, that is) compiler to build insn-attrtab.o. cc1 is the offending binary.

This only happens when trying to install in 64-bit mode. I've got a 32-bit installation already on the box, and when I compile 3.4.3-r1 on that side, it works just fine. Of course, it's compiling a 32-bit compiler using a 32-bit compiler and is running on a 32-bit kernel, but it would seem to rule out CPU overheating issues, which is certainly what this problem looks like. I even tried booting a 64-bit kernel (built on a different box), which worked okay, and I was able to build gcc in the 32-bit userland there, too. It's only the 64/64/64 combination that doesn't work.

I have run memtest86+ (1.5.1) overnight, so I'm reasonably confident it's not the memory. I still think it might be a CPU overheating issue, but that kind of thing tends to break in random places. And I've even paused the build for a few minutes to let the CPU cool off, and after continuing, it still breaks in the same place.

My hardware is a 3000+ Venice on a DFI Lanparty Ultra-D, FWIW.

Any ideas what I should try?

[Corona688]

What version of gcc is this?
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html

[dhduvall]

3.4.3-r1. Though I swapped out my memory for an older, slower DIMM (and also down to 512MB from 2GB), and it compiled without a hitch. I'll test each of the two 1GB modules in the set that was causing me problems, but I'm probably going to have to return them. Pity, they should have been just fine ...

[Corona688]

I've noticed a couple threads like this, memtest finds nothing wrong but the RAM turns out to be bad anyway. I wonder what's missing? Maybye there are some different transfer modes in 64-bit or something.
_________________
Petition for Better 64-bit ATI Drivers - Sign Here
http://www.petitiononline.com/atipet/petition.html

[dhduvall]

Still dunno what might be wrong, but each of the two 1GB modules manages to compile gcc file (inasmuch as a memory module compiles anything, at all). My next guess is that there's something wrong with the motherboard -- or the chipset -- when operating memory in dual channel mode. This is obviously harder to test.

I can still do a BIOS upgrade, and I'll google around for dual channel memory problems, see if anything comes up.

And it's such a pretty day outside ...

[dhduvall]

Success! Well, at least in the "simple" gcc-compile test. The BIOS update didn't do diddly, but a little bit of googling and good luck helped. Turns out that a number of folks have reported some issues with nForce4 on various motherboards when running dual channel memory. It was never very specific, but the advice that was given most often was to dork with the memory timings and voltage until things worked. Heh.

So my wild-assed guess that worked was pretend that the memory I got was the same as one of the memory boards tested in AnandTech's value memory roundup. What I actually have is OCZ4002048V3DC-K, with a sticker that says 3-4-4-8, and it's supposed to run at 2.6V. The similar boards Anand looked at had the same part number (except that they were 2x512, so OCZ4001024WV3DC-K -- no idea what the W is there), but with timings of 2.5-3-3-7. So I tried that -- CAS2.5 on its own just made things blow up a bit more spectacularly -- the kernel itself paniced -- but those settings, as well as setting the voltage to 3V got me these results. And gcc compiled about 5% faster, to boot! Heck, I might even try the 2-2-2-6 settings Anand did.

I'll check back in if things blow up again, but I think my problem's solved.

[bbkr]

same error. also DFI NF4 board. fighting with that for almost a week.

i'll try play with mem timings and i'll post results here.

[FDK]

Try to use 2T - it work for me.
_________________
Dell Lattitude D610 & gentoo box: Gigabyte PC1000 MB (VIA C3 800Mhz) + 512Mb RAM + 1Gb IDE Flash