Re: >128 MB RAM stability problems (again)

Andreas Bombe (andreas@bombe.modem.informatik.tu-muenchen.de)
Mon, 9 Jul 2001 16:24:51 +0200


On Fri, Jul 06, 2001 at 07:55:50PM +0200, Ronald Bultje wrote:
> So, basically, my bios must have loaded the wrong options for my memory
> which must run above it's limits which causes data corruption... Then,
> my stupid question, why doesn't memtest86 detect that?

Because it's a memory tester and not real work load. It tries special
access patterns to find hard memory errors (i.e. memory cells that are
damaged). Timing and configuration errors are harder to find. For one
thing, these might depend on temperature, and memtest86 won't stress the
CPU into generating as much heat as real work will do.

> Anyway, I'll go look at the bios settings of the computers, look at the
> CAS/RAS/clock timing settings like two people suggested (thanks :-) )
> and hope to be happy and have a stable machine after that.

According to your posts, you are using no-name SDRAMs, and two different
ones. I have already posted that, their configuration data is often
incomplete or just erronous and the BIOS will be confused or has just
errors itself (like configuring all SDRAMs to the values of the first
one).

The German computer magazine c't has some time ago bought no-name
and branded SDRAMs and tested them extensively (checked config ROM data,
put them in a lended $500000 memory tester). Results were that no-names
were on average pretty crappy. The branded ones weren't perfect, but
much better. A month after that article pretty much every computer
store here had brand SDRAMs in addition to the cheap no-name stuff.

If you can get hold of the timing values for your RAM (might be hard
with no-name, use conservative values otherwise) then it's better to set
these directly instead of letting the BIOS go around playing with that
stuff.

autodetection, left it out of the BIOS and require the user to configure
it themselves if they want some performance.

-- 
Andreas E. Bombe <andreas.bombe@munich.netsurf.de>    DSA key 0x04880A44
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/