Bruno Buys wrote:
Marty wrote:
Finally you may want to think about testing the memory, especially if
you suspect any instability, but that's a different thread.
I did. That was the very first thing I did after hooking up the
module. I was afraid what a defective module could do to my beloved
debian system, so I run memtest86 for 30 min without problems, before
booting debian with the new module. My prior experience with memtest
was that it would find problems before 2 or 3 min running. What do
you think?
I've had modules that require hours or even days of heavy stress
testing to elicit failure. Under normal curcumstances they might
run for weeks or months without any obvious failure. I think this type
of marginal defect is much more common than any that can be found in
a few minutes of testing, because thr latter are much easier to screen
by the retailer, middleman or manufacturer.
I used the same set of tests whether I'm adding or changing memory, a
processor or a motherboard. Even if one combination of components tests
good, I retest them all if any one component is changed.
To invalidate the kernel's file cache, I use custom shell scripts to
continuously read and check a large number of files (e.g. looping debsums
runs, checksum tests of my local debian archive, or copying and then
checking
the contents a DVD). In addition I run memtest and/or do looping kernel
compiles while checking the results using a modified version of the old
"burnit" script which was used years ago to test for defects in certain
types of AMD processors. This test is a particularly effective memory
test
due to the use of self-modifying code by GCC.
While monotoring a temperature probe inside the box, and temperature
monitoring tools like mbmon and hdtemp, I reduce airflow and/or test
in a small enclosed space, allowing the (modules') ambient temperature to
rise to 40C or higher. Under these conditions I allow the tests to run
from overnight to as long as a week in duration. In case of a crash I
run the tests from a remote system via ssh sessions, so that the results
are logged in the terminal sessions.
These tests are probably overkill for a personal desktop system, but
I run them because I dislike flaky hardware and because I always buy
the cheapest hardware I can find with the expectation that a certain
percentage of it will be returned or scrapped.