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.
