# Memtest86 alternative?

## Tim77

Hi there,

I have some problems with random crashes either on Windows and Gentoo. I didn't overclock, my Athlon is always below 60 degree and the RAM speed is set up correctly.

I think it's the Ram, but Memtest86 doesn't show any errors. Are there other memory tests which could help?

----------

## neuron

how long do you let it run?  If there are memory errors, that should most defenatly show it.

----------

## bsolar

Also you might want to do all the test and not only the basic ones, it will take hours though.

----------

## zhenlin

Consider other tests, such a HD bad sectors test, or a VRAM test, or a PCI bus test, or an IDE/SCSI/ATAPI bus test, or a processor test, or a cache test, etc.

Compiling a Linux kernel repeatedly is the best way to test a processor, memory and hard disks. Unless you compile on a RAM disk.

----------

## Malakin

memtest86 hasn't failed me yet, if you run it for a full loop and your computer is running at regular temp (not with the case off) and it passes then your ram is good.

zhenlin's suggestion of doing a looping kernel compile is a great way to test the cpu, if it fails then you can take the case off the computer and put a desk fan up to it, loop the kernel compile some more and if it passes then you know something is overheating, likely the cpu. I've seen a cpu cause errors when the temp was reported to be only 54C, reapplying the cpu with some silver heatsink compound fixed it but I think the reported temps are often fairly off so they're not all that reliable.

----------

## Krookednek

In windows, I use prime 95 for stress tests and it always catches everything before anyone else.  I am pretty sure there is a linux equivalent, but Im not sure what it is called.  Does anyone else know?

----------

## lucasjb

Hi All,

I too am looking for a way to stress test hardware.  For those interested, a topic similar to this is in the FAQ, with a link to the SIG11 FAQ with lots of hints about catching flakey hardware.  In regards to Memtest86, I ran this for a couple of hours and it came up clean.  The SIG11 FAQ mentions that Memtest86 is not particularly reliable, it could be wrong of course.

I myself experience constant crashing (usually segfaults) in certain applications (mostly Gnome, but other things like Vim and Gimp also crash from time to time, Mplayer has been known to produce hard lockups, so I have stopped using it in favour of Xine which never fails), I have problems emerging KDE (3.1.1 wouldn't get past compiling kdebase, 3.1.2 is stuck at kdeartwork, it always bombs out at the same point though, so it doesn't convince me 100% that my hardware is at fault).  My kernel thus far has been stable.

Presently I'm trying to stress test using a method described on the aforementioned SIG11 FAQ, that is, repeatedly compiling kernels and logging the output.  At the same time, in a another console, I've been exercising my disk (and RAM I think) with

```
dd if=/dev/hda of=/dev/null
```

I'd really like some more (hopefully more up to date) info on stress testing hardware.  So far I've done 63 kernel compiles in a row with no problems.  In particular I'd like to give my RAM a good thrashing, but I have 1024MB of it, I'm not sure that a kernel compile will use all of that.  I've read that unzipping a file that's slightly smaller than your RAM will exercise it, I was thinking of trying this while compiling kernels.  Anyone have any advice on this (like where I can find a 1020MB zip file  :Wink:  )?

For the record, my specs:

* Asus A7N8X Deluxe

* Athlon XP 2100+

* 2 x 512MB PC2700 Kingston DDR SDRAM

* Linux 2.4.20 (Gentoo Gaming Sources)

None of my stuff is overclocked.

I'd really like a good, reliable, really tough stress test so I can sort this out once and for all, I'm tired of my crashy Gentoo... coming from the Debian world (and still living in it at work) an unstable system is hard to take   :Sad: 

Regards,

Lucas

P.S.  I just noticed that on my 52nd kernel compile, it failed with:

```

In file included from xfs.h:65,

from xfs_dquot_item.c:33:

xfs_ag.h:232: internal error: Segmentation fault

Please submit a full bug report,

with preprocessed source if appropriate.

See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

make[3]: *** [xfs_dquot_item.o] Error 1

```

Eek!  OK, how do I go about tracking down the problem?  I think I'll start by removing one of my RAM DIMMS... other suggestions?  I'm guessing it's not overheating, because you would expect it would fail earlier than this and get worse as time goes on, plus it's been cold overnight  :Smile: .

P.P.S  Sorry for the essay --- somebody please reply I've been working on this all morning!!!

----------

## BradN

It's hard to tell what the problem is.  Things like that might be partially the motherboard, and partially the CPU or memory.  You could try swapping out different parts (memory, CPU, MB) and seeing what helps - but I wouldn't be suprised if changing one or the other makes the problem go away.

I'd tend to think it's not a memory problem though, because memtest86 doesn't report any problems, and in my experience, it WILL find bad memory.  Take a look at the CPU and motherboard.

good luck

----------

## lucasjb

Hi All,

Thanks BradN, I'll give Memtest86 another shot (do all the tests now that I suspect something is wrong), try to eliminate RAM from the list of suspects.  You suggest "swapping out" the motherboard and CPU... nice idea, but unfortunately I don't have a spare A7N8X Deluxe or Athlon XP 2100+ lying about  :Wink:   Point taken though, it's trial and error I guess.  Thanks for your suggestions and experience.  It's going to be a slow process I expect... I suppose I can adjust bus speeds and the like, I'll need to do some research as well (I don't know much about hardware).

To get back to the original theme of this post (sorry to have hijacked it ;p), is there any kind of hardware test software that can be run from within Linux?  Krookednek mentioned something called prime 95 for Windows, is there a Linux equivalent?

Regards,

Lucas

----------

## lucasjb

Hi All,

To reply to myself (as I sometimes do), I've now compiled 103 kernels in a row.  Only one did not complete properly (seg faulted).  This suggests to me that each time I replace a component, it'll be at least 24 hours of cranking my machine before I can rule it out, I'd like something that works a bit quicker.  I have taken two suggestions from the SIG11 FAQ.  One is running dd if=/dev/hda of=/dev/null while compiling kernels, the other is unzipping a file that is slightly smaller than the amount of RAM I have (not sure if I should be compiling at the same time or not in this case).

Can anyone tell me what these will actually do (I know what the commands do, but what effect will it have on my system)?  Are either / both of these a good idea?  How should I do the unzipping? Can I use g[un]zip or does it have to be [un]zip?  Should I run these in a loop while compiling?  Anybody have further experiences to share?

... I am yet to try the Memtest86 again of course, I hope that points the problem out to me...

Thanks,

Lucas

----------

## lucasjb

Hi All,

See I told you I like replying to myself.  I pulled out one of my DIMMs, and booted up, tried to start Gnome, crashed after 5 seconds, tried again, crashed in less than 1 second... "Ah ha!" I thought, it must be the other one.  Shutdown, swapped the DIMMS booted backup... same thing!

OK, so it's not a faulty DIMM (could be two faulty DIMMs).  I decided to take a look at the BIOS setup again.  One option caught my eye "Memory Frequency".  The default [by SPD] is recommended by the manual, which doesn't mention anything about the other option [Auto]... so I switched it to auto --- haven't had a segfault or other kind of crash since and the KDE packages that refused to compile now magically work perfectly!

Does anybody else wish that motherboard manufacturers would put just a little more effort into their manuals?  They could have saved me a lot of pain by explaining properly what this does (I still don't really know) and which option is most stable.

Anyway, I'm still interested in methods of stress testing hardware if anyone wants to follow this up.

Lucas

P.S.  Now very happy and looking forward to enjoying my stable Gentoo   :Very Happy: 

----------

## neuron

you could/should set the memory to 100% / sync on the nforce2 chipset.  It will be a boost in performance.  I'm not sure if auto is choosing sync though.

----------

## Bangz

 *Krookednek wrote:*   

> In windows, I use prime 95 for stress tests and it always catches everything before anyone else.  I am pretty sure there is a linux equivalent, but Im not sure what it is called.  Does anyone else know?

 

It's called Prime95  :Smile: 

----------

## Malakin

If you suspect it's heat you can put your computer in a big garbage bag and it'll start crashing like crazy pretty quick if it's a heat problem. Keep an eye on it though as it can get really hot, you probably don't want it in a bag for more then 15 minutes or so if it's a newer system since newer systems these days all produce quite a bit of heat.

----------

