26 Mar
2005
26 Mar
'05
4:20 a.m.
On Fri, Mar 25, 2005 at 05:47:56PM -0600, Jim Leonard wrote:
Philip Pemberton wrote:
Of course you can't. It only tests a limited set of patterns - those
which are expected to be best for triggering faults - but it simply
_cannot_ test all possible patterns. memtest86 is a positive only
checking tool: it can only detect the presence of memory errors, but
cannot prove their absence. Especially since there are some rather
"interesting" failure modes for memory cells.
The only surefire RAM check is MemTest86 left for
a few hours
in "burn in" mode.
You can't trust this 100%. We had a problem with a SuperMicro board;
database kept getting scrambled occaisionally. Ran memtest86 on burn-in
mode for 24 hours -- never found a problem -- boot back into the OS and
bam, scrambled data again. When we replaced one of the memory sticks as a
last ditch effort, it fixed the problem.
Usually compiling a very large software package under Linux is a good
memory stress test for finding faults. Traditionally, one used the full
Linux kernel compile run for that, but nowadays I would also add a full
compile of OpenOffice to that. If any SISEGVs are being thrown during
compile, then the memory is highly suspect.
Regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison