On Sunday 09 March 2003 09:05 pm, David E. Fox wrote: > > Unless you're sure your case and cpu cooling is adequate, take the > > diag's in the above order. Otherwise go right to cpuburn. The acid > > test for cpu/cache/ram/PSU/motherboards. > > Someone also mentioned recompiling the kernel - using many > gcc forks (make -j 100) as a good test for the system. > > Obviously you have to have enough RAM for that many simultaneous > compiles, but it might be a good way to test the entirety of the > emmory / cpu / bus environment. The others are good as well, but > with the exception of memtest, they won't use a large enough portion > of the RAM. For instance, cpuburn runs a *very* tight loop - it would > easily fit in the CPU's primary cache. mprime does a little better - > maybe 13-20 megs of RAM involved here. Eitehr way, if there's a RAM > problem, cpuburn or mprime may never pick it up. The real difficulty > is if there is a RAM problem, there's likely no way to tell where it > is. But then the recourse is to just replace the module anyhow :).
Reframing the original question: Are there any Linux programs for diagnosing problems with hardware subsystems? With the exception of memtest, it strikes me that everything mentioned to date in this thread is some form of stress test. While stress testing is useful to establish that the whole system is either OK or NFG, there are times when a more specific diagnostic is required. I'm thinking about something similar to the old CheckIt or PC Tools that I used back in the days of MSDOS 3.31. Or have these critters become so complex that it now takes a lab full of equipment to get any meaningful results? -- cmg
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
