OT: Re: Memtest86 doesn't work - Was Re: Fedora Updater

[Keith G. Robertson-Turner]

On Tue, 24 Feb 2004 08:34:37 -0300, Alexandre Strube wrote:

> do you know any kind of open-source swiss-knife tool which could do such
> a stress test, I say without compromising the system (as with kernel
> segfaults?)

Do you mean compromising as in security, or as in subjecting the system to
further damage?

Either way, (and IMO), if you have damaged hardware, there's no
software on earth (OSS or otherwise) that can be guaranteed to run 100%
safely on such a system. The best you can hope for is to diagnose the
problem as quickly as possible, then repair or replace the damaged
hardware.

If you're looking for a diagnostic toolkit, don't bother with dedicated,
so-called, test software (unless it's the kind of thing that hooks up to a
multimeter, oscilloscope and a wet-bench ... but that's a whole different
game).

Anything which simultaneously pushes the main I/O subsystems hard, should
be fine. Examples include intensive graphics processing, the creation of
compressed archives, and rebuilding sourcecode, where the data (including
the resulting and temporary data) you're working with is huge (larger than
the available "real" memory).

Software that just pushes the CPU, such as crypto-cracking software,
doesn't usually have a high memory overhead - you'll test the CPU, but not
much else. Software that repeatedly writes 1's and 0's across memory
regions will not (should not?/can not?) touch areas reserved for DMA and
I/O buffers, only the respective hardware component (hard drive for
example) can do that. For software that *can* do that (and if such a thing
exists, surely it would cause all kinds of problems for the DMA dependant
hardware) I doubt that it is pushing it as hard as the hardware itself
(burst transfers, asynchronous access, multiple pipelines etc).

It seems to be Murphy's law, that when memory fails, it's invariably in
regions reserved for hardware in the BIOS, maybe because it's subjected to
heavier daily use. This would explain why memtest86 is seldom useful.

_
K.