Totally OT, but frustrated.....

[Alexander Schreiber]

On Fri, Mar 25, 2005 at 05:47:56PM -0600, Jim Leonard wrote:
> Philip Pemberton wrote:
> >The only surefire RAM check is MemTest86 left for a few hours
> >in "burn in" mode.
> 
> You can't trust this 100%. 

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.

> 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