# CPU Test

## MasquedAvenger

Ok, so I have a couple of questions.  The first is, are there any programs out there for *NIX (either in portage or something that I can compile myself) that will keep the CPU busy with computations, as well as check the integrity of the calculations to make sure the CPU is working properly?  I've seen applications like this for Windows, but not for *NIX.  I don't want something that only stresses out the CPU; I need something that will actually check to make sure that the CPU is operating properly under stress.

The reason I ask is that I've been having a lot of random kernel hangs and segfaults, and I'm trying to see if my CPU could be to blame.

Also, is there a way for me to boot up the machine with the root filesystem mounted read-only?  That way, if I hang the machine during my testing, I can shut it down without worrying about filesystem integrity.

Thanks  :Smile: 

James

----------

## likewhoa

emerging glibc would usually find instability with the cpu, but you can also run gimps, let that run for at least 2hours alternatives are running rosetta@home,folding@home & world community grid which will stress out the cpu well.

are you sure it's not your memory that's the problem? and have you checked your cpu idle/load temps?

please post your specs.

----------

## PaulBredbury

```
emerge cpuburn
```

----------

## jexxie

mprime is excellent for this, as it also compares the calculations with known-good ones.

(mprime is a GIMPS client, just set it in benchmark mode)

http://www.mersenne.org/freesoft.htm

----------

## MasquedAvenger

 *likewhoa wrote:*   

> emerging glibc would usually find instability with the cpu, but you can also run gimps, let that run for at least 2hours alternatives are running rosetta@home,folding@home & world community grid which will stress out the cpu well.
> 
> are you sure it's not your memory that's the problem? and have you checked your cpu idle/load temps?
> 
> please post your specs.

 

I could try emerging glibc, but then there's the possibility that it's going to crash and take my filesystem with it (a small chance, but one I'm not willing to risk all the same.)  Perhaps I could build glibc manually in a ram disk, since it can check a read-only root filesystem for dependencies (I have 2GB of memory, so I can spare enough for that.)

I ran memtest on it more than once, and each time, it passed, so I'm pretty confident that it's not the memory.  I also let the machine heat up during the memory test, so it's not flaking out due to heat issues.

As for the CPU, I'm not so sure.  I'll boot up the machine again when I have the chance, and post what I can.  What's a good way to monitor the temps so I can post them?

James

----------

## MasquedAvenger

 *jexxie wrote:*   

> mprime is excellent for this, as it also compares the calculations with known-good ones.
> 
> (mprime is a GIMPS client, just set it in benchmark mode)
> 
> http://www.mersenne.org/freesoft.htm

 

Cool.  I'll have to check that out.

James

----------

## MasquedAvenger

I should also mention that this system is a laptop, so I have to be extremely careful that I don't overheat my computer, much more so than an ordinary desktop machine.  I'm probably going to place fans under the laptop to wick away some additional excess heat.

James

----------

## MasquedAvenger

Ok, so here's an update on where I am so far.  I made sure I had a backup of the root filesystem, so now I don't have to feel weird about messing it up in case something goes wrong.  Thus, I don't need to mount read-only, and have decided to emerge glibc to see if it's successful.  My computer is currently sitting ontop of a fan designed to keep the underside of laptops cool, so I'm first going to see if the build is successful when on the fans, then see if it's also successful when off the fans.  If it's successful on the fans but not off the fans, then I know the CPU is flaky when it comes to heat (though I've been able to compile even larger applications like Open Office without it sitting on the fans and without a crash, so I don't know that this is going to reveal a problem.)

Here's a summary of some of the problems I've been having, just in case anybody can confirm or deny anything.

1) Two times so far within days of each incident, when I've been building packages AND playing games at the same time (they may have all used the SDL library, but I'm not positive on that), the kernel has hung completely (I couldn't even SSH into the machine) and I had to do a cold reboot.  The display simply hung at first (sounds were working for another moment or two), then became garbled (I was logged into X.)

2) A couple days ago, booting up the laptop revealed that while the keyboard worked after system POST, it didn't work after booting the Linux kernel, and so I had to use the power button to do a clean shutdown (acpid reads such events and handles them appropriately.)  Sometimes when I booted the machine, the keyboard worked, and othertimes, it did not.  It randomly started working for me and has been working since.

3) Randomly, maybe once or twice a week, the bootloader refuses to start, and I have to reboot the machine.  In a couple of incidences, I've had to reboot two or three times to get to the bootloader (GRUB.)

4) I have an Intel 3495ABG wireless miniPCI card in this machine.  Yesterday, without a warning, the network stopped working.  I tried to run ifconfig, but the process wouldn't respond and I couldn't kill it.  A dmesg revealed that the module caused something that looked like a segfault in the networking drivers of the kernel (everything else was working.)  I tried to shutdown, but it wouldn't finish shutting down because it couldn't kill the ifconfig process, so I had to shutdown uncleanly.

If any of these things had happened with less frequency or if only one or two of these things had occured, I wouldn't think much of it, but lots of random events like this, combined with the frequency in which they have occured thus far, leads me to believe, from past experiences, that this could indicate a problem with either memory, CPU or motherboard.  I've eliminated the memory as a cause (I hope) using memtest86, so the cause remains to be seen.

James

----------

## jexxie

Updating the BIOS version from the manufacturer would be the step I would take first, this does two things:

1. Updates / fixes any known hardware problems or stability problems

2. Triggers a CMOS reset of your BIOS settings, which can fix a LOT of problems. (It's magic.)

Give that a try.

----------

## likewhoa

how long did you run memtest86 for? also make sure to run gimps for 2hours but i recommend 8hours to be sure.

----------

## MasquedAvenger

 *likewhoa wrote:*   

> how long did you run memtest86 for? also make sure to run gimps for 2hours but i recommend 8hours to be sure.

 

Memtest was up for about an hour, long enough to pass twice.  In my past experience, that's been enough to reasonably assure that the memory is working properly, but I suppose I could do it for longer if nothing else seems to turn up.  I'll make sure I give GIMPS a try as well.  I assume it's in portage, correct?

James

----------

## likewhoa

 *MasquedAvenger wrote:*   

>  *likewhoa wrote:*   how long did you run memtest86 for? also make sure to run gimps for 2hours but i recommend 8hours to be sure. 
> 
> Memtest was up for about an hour, long enough to pass twice.  In my past experience, that's been enough to reasonably assure that the memory is working properly, but I suppose I could do it for longer if nothing else seems to turn up.  I'll make sure I give GIMPS a try as well.  I assume it's in portage, correct?
> 
> James

 

yes, gimps is in portage & no, 2hours of memtest86 is not really enough. I have had it fail on me at 4hours before and it's recommended to run 20 loops on each test about 12hours. run gimps for 7-8 hours and if you're using dual-cores then run two copies of it at the same time, one for each core.

----------

## MasquedAvenger

Still haven't had the chance to run gimps yet, or do a longer memory test (will be busy this weekend, but will post the results when I have the chance), but I had the opportunity to compile a large number of packages that needed installing (GCC 4.1.2, GCC 3.4.6 and OpenOffice 2.3.0), and so far, the machine hasn't failed me (and it's not running too hot either, even without the fan underneath.)

There's a lot of compiling left to do, so we'll see what happens.  The day is young...  :Razz: 

James

----------

## MasquedAvenger

Sorry for the lack of an update for so long.  Still haven't had the chance to run any tests yet (been really busy in school; my semester ends in two weeks, and then I'll have more time), but I did verify that the wireless driver's kernel oopses were actually most likely the result of a known bug in version 1.2.0 of net-wireless/ipw3945.  It was fixed starting with 1.2.1, so I installed the latest version (had to add an entry to /etc/portage/package.keywords because the version marked "stable" is a little stale) and I'm hoping that this will at least fix that issue.

We'll see what happens.

James

----------

