# GCC Segmentation Fault with 1T Command Rate

## Crunchy

I've been using x86 Gentoo for a while but thought I'd try the AMD64 version.  Everything installed fine but as soon as I tried to upgrade to gcc 4.1.2 the emerge failed with a segmentation fault mid build.  I went to the bugzilla site and saw the top bug about flakey hardware so I didn't bother to report the bug.  I followed the advice on finding the hardware fault and found that if I used a Command Rate of 2T and no other change the segmentation fault stopped.

Does anyone have any advice or knowledge about this?  Any kernel options I can tweak to get back 1T Command Rate?  I might try raising the CPU/mem voltage, I also have another set of mem sticks but I'm pretty sure the mem is ok.

My hardware:

AMD Athlon 64 X2 4200+ (Toledo, has SSE3)

MSI K8N Neo2 Platinum mobo (nForce3 Ultra)

OCZ Platinum EL Dual Channel Kit 2x512MB PC3200 CL 2-2-2-5 Revision 2

My CFLAGS:

CFLAGS="-march=k8 -O2 -pipe -msse3"

I tried CFLAGS="-mcpu=k8 -O2" but that had the same problem.

My software:

Base AMD64 Gentoo 2007.0 with only Links in "world".

----------

## Keruskerfuerst

Check out the OCZ website for voltage and time settings.

----------

## Crunchy

 *Keruskerfuerst wrote:*   

> Check out the OCZ website for voltage and time settings.

 

I checked and the timings are fine (2-2-2-5) and I set the voltage manualy and I have the same problem.  I've tried increasing the memory voltage by 0.1V but that didn't help.  I'm trying adding 5% to the CPU voltage now to see if that helps.

----------

## Keruskerfuerst

Check out, if the command rate can be set to 1T.

----------

## Crunchy

 *Keruskerfuerst wrote:*   

> Check out, if the command rate can be set to 1T.

 

Theres no mention of it on OCZ's website, I think all high performance RAM can do the 1T.  I've seen a test of 2T vs 1T where the real world performance was about 2-3%.  I'm not sure if to live with it or go back to 32 bit.

----------

## Keruskerfuerst

Yes, all high performance RAM can do 1T.

You should read the SDP EEPROM of the RAM modules.

----------

## Crunchy

I'm looking at the SPD section in CPU-Z under windows and it shows timings and voltage but the Command Rate line is blank.

----------

## Keruskerfuerst

Then you should try to use the command rate of 2T.

----------

## Crunchy

If I want to use 2G of ram, ie 4 x 512 MB sticks I have to use 2T command rate so I guess it could be the same restriction for going 64bit?

----------

## Keruskerfuerst

Yes, I think so.

----------

## Cyker

If you only have 1 bank used (i.e. 2 matched DIMMs or a single DIMM depending on system), then you can use 1T

If you have 2 banks then you're supposed to use 2T, probably for the reasons you're finding, assuming you are using two dual-channel kits?

If you're not... mmm, I'm not sure...

I know some mobos just can't do 1T, but yours is an nForce chipset so it should be able to handle it...

----------

## Crunchy

I'm using 2 sticks of dual-channel 512MB RAM in the first channel.  I've been running 1T under windows for a year or so.  I was using 1T under 32bit Gentoo but as soon as I switched to AMD64 it became unstable.  2T is perfectly stable in AMD64.  I'm guessing going 64 bit put extra strain on the on-CPU memory controller.

----------

## Cyker

Possible, but really it shouldn't happen  :Sad: 

Is the CPU overclocked at all?

And are you using the CnQ/Powernow! stuff in the kernel?

TBH 'tho, I don't think 1T vs 2T makes a significant difference. Certainly not big enough to justify the loss in stability!

----------

## Akkara

I recently had some *very* strange memory problems (I was certain it was the disk controller because it only showed up when copying data between two different disks - it's all good now after replacing a bad stick).

Try memtester, it is in portage.  It is a user-level (well, as root) memory tester that seems much better at finding iffy memory than the usual memtest86+ .  It is possible even 32-bits might have had subtle issues that just didn't happen to make themselves as noticable.

----------

