Re: >128 MB RAM stability problems (again)

[Bill Pringlemeir <bpringle@sympatico.ca>]

>>>>> "Ragnar" == Ragnar Hojland Espinosa <ragnar@ragnar-hojland.com> 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 "http://www.memtest86.com/"
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!

regards,
Bill Pringlemeir