On Monday 10 March 2003 12:23 am, Carroll Grigsby wrote: > 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 checkIt and PCtools were only about as good as (imho) lspcidrake and fell short of hadrdrake
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
