[lkml]   [2001]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: >128 MB RAM stability problems (again)
>>>>> "Ragnar" == Ragnar Hojland Espinosa <> writes:

Ragnar> And here's a counter claim: At home have 128 + 64, both of
Ragnar> different speeds and brands. Of course, to run properly you
Ragnar> have to force the pc100 to run at 66, but other than that
Ragnar> they're happy (96MB swap)


Yes, I imagine Linux does work ;-) The fact is that SDRAM is
problematic (from a hardware perspective). For the OP, it could be a
bus capacitance problem. If the boards are older, they might not be
designed for larger memories with have a higher capacitance. Slowing
down the accesses will stop the problem. You would do this by going
to the BIOS and changing the CAS and RAS timings (or maybe you can
change the SDRAM clock). SDRAM has a `NOP' state so that you can run
at a higher clock speed, but delay a command. Anyways, I don't think
that Linux is messing with the SDRAM controllers, but I am not an
authority. Also, a single stick is always better than several
smaller memory sizes.

I was looking at the memtest86 web sight ""
and I didn't see anything that test for SDRAM cache lines. Single
beat SDRAM read/writes are less stressful than BURSTS. It is typical
for single beats read/write to work while bursts fail as four 32 bit
values are written and read in quick succession. The `algorithm'
description on the web page doesn't seem to test for this issue from
what I see... of course I have been wrong before!

Bill Pringlemeir

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:56    [W:0.051 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site