LinuxSA Mailing list archives

  From: Mark Smith <marks@senet.com.au>
  To  : Mark Pulford <mark@kyne.com.au>
  Date: Fri, 27 Nov 1998 20:36:42 +1030

Re: Memory Fault ?? maybe

Hi All,,

I have  used the "memtest86-1.3" program to test out non-parity RAM. Having
grown up with parity checking on RAM (starting when 16KB was big, and 2 KB of
video RAM was enough), when I built a new machine using non-parity RAM, I wanted
to make sure that the RAM was good.

Memtest was written by a guy at Cray computing (I figure somebody who works at
Cray, and can write a memory testing program probably knows what he is doing).
From the readme :

"Memtest86 is thorough, stand alone memory test for 386, 486 and Pentium
systems.  Memtest86 uses a "moving inversions" algorithm that is proven
to be effective in finding memory errors.  The BIOS based memory test is
just a quick check that will often miss many of the failures that are
detected by Memtest86."

......
which is a good reason to speed up boot of your machine by switching of the
memory test
.....

"A provision to disable L1, L2 caches was added in release 1.1.  With this
enhancement cache is on for even numbered passes and off for odd passes.
The test algorithms used by Memtest86 are able to do fairly effective
testing of memory with cache on.  However, in some instances testing with
cache off may be more effective.  In addition the test algorithms will not
work correctly on systems with write-back cache when cache is enabled.  The
down side is that execution time is much, much longer when cache is off.
This feature may be disabled by commenting out the "CACHE=-DCACHE" line in
the Makefile.

Memtest86 has the ability to test memory using longer refresh rates.  This
makes is possible to detect marginal errors that otherwise would go
undetected with the normal refresh rate.  Two refresh rates are used, the
normal of 15ms and an extended refresh rate of 150ms.  The test alternates
between normal and extended refresh every two passes.  This allows for
testing with cache both on and off before switching refresh rates.  This
feature may be disabled by commenting out the "REFRESH=-DREFRESH" line in
the Makefile.  If this feature is disabled the refresh rate set by the BIOS
will be used.
"

This means that to do a full and thorough test of your RAM you have to let the
program do 4 passes.

Compiling a kernel is a good test, however, with more and more RAM in your
machine, you can't guarantee that *all* your memory will be "excercised" by the
kernel compile.

For example, I was having some sig11 faults during kernel compiles due to my
motherboard setting the Cyrix PR-200 core speed to 75 Mhz and multiplying it by
2 to get 150 Mhz. However, the only time I would get sig11 faults was if I was
compiling a kernel and my machine started to swap to my ISA based SCSI disk.
These sig11 faults seemed to be related to the 75Mhz bus speed being too fast
for my ISA SCSI controller.

Setting the core speed to 50Mhz and multiplying it by 3 fixed the problem. Since
that time I have added another 32 MB of RAM to my machine (total of 64MB), and
just to get my machine to swap while compiling a kernel, I have to fire up X,
Netscape, a few versions of XV with some big pictures open etc, just to fill
enough RAM to get the kernel compile to swap.

Scary huh ... a year or two ago I used to run X on a 486 with 8 MB of RAM, and
only have 500 KB left over to run any programs. Running Netscape meant my disks
were constantly reading / writing to swap. Now I have to work hard to get them
*out* of RAM, and into swap. :-)

HTH,
Mark.

--

+-----------------------------------------------
| Mark Smith | email: mailto:marks@senet.com.au
|
| "IP Over Everything" - Vint Cerf.



-- 
Check out the LinuxSA web pages at http://www.linuxsa.org.au/
To unsubscribe from the LinuxSA list:
  mail linuxsa-request@linuxsa.org.au with "unsubscribe" as the subject