Re: CPU-Test similar to Memtest?

[Samuel Flory <sflory@rackable.com>]

bill davidsen wrote:
> In article <1067379433.6281.575.camel@tubarao>,
> Thayne Harbaugh  <tharbaugh@lnxi.com> wrote:
> 
> | On Tue, 2003-10-28 at 09:05, Robert L. Harris wrote:
> | > I'm going to run MEMTEST today when I get home and get a chance to make
> | > a bootable CD
> | 
> | Memtest86 is good, but it isn't as good as it could be.  Many times I
> | have seen it run 24 hours without error even though the the system has
> | bad memory.
> | 
> | >  but I'm wondering if there might be a "CPUTEST" or such
> | > utility anyone knows of that'll poke and prod a dual athalon real well
> | > and make sure I don't have a flaky cpu.
> | 
> | Run Linpack (or other computationally intensive program) while
> | monitoring ECC errors with either
> | http://www.anime.net/~goemon/linux-ecc/files/
> | or
> | ftp://ftp.lnxi.com/pub/bluesmoke
> 
> I agree with almost everything you said, but I have seen cases in which
> no CPU use would generate an error, but using heavy DMA io in addition
> triggered the problem. If all else fails add your favorite disk test.


   Cpuburn is a good test to run on x86's.  That said I've only seen it 
fail in 2 systems out of ~20,000.  Generally cpu erros will crash your 
system before the error is printed to the screen.

   Also compiling your kernel in a loop is a good way to shake loose 
cpu, and memory issue.  I've often found this finds errors much quicker 
many memory tests.

   You might want to try ctcs.  "Make ; "./new-burn -t"
http://sourceforge.net/projects/va-ctcs/
-- 
Once you have their hardware. Never give it back.
(The First Rule of Hardware Acquisition)
Sam Flory  <sflory@rackable.com>