shaky support or my system?

Bill Squire billsf at
Mon Feb 9 02:03:18 PST 2004

On Mon, Feb 09, 2004 at 09:40:18AM +0100, Janne Johansson wrote:
> Hash: SHA1
> |>>>in either fbsd5.2 nor the recent 5.2.1RC. One of the things that makes
> |>>>it crash for sure is the /usr/ports/benchmarks/ubench program. It does
> |>>
> |>>Don't run that, it'll just tell you that the system is only
> marginally faster
> |>>than the athlon XP it replaces.
> |>
> |>I've reproduced Janne's panic with ubench twice.  Both show similar
> |>outputs from the panic.  Panic #3 is proving more elusive: I'm running
> |>ubench for the fourth time in a row now waiting for crash #3.
> |
> | Unfortunately it appears my case was a false alarm.
> | My Tyan K8W S2885 is not stable unless ECC is turned off in ROM setup.
> I switched my memory chips around and found that one seems to cause more
> instability, and removing it made me be able to run that stupid app
> "ubench". ;-)
> Now I can build several ports in a row without hanging, but I do still
> get the odd freeze sometimes. Since memtest86 wont work (on my) A64, is
> there something else I can do to stress my memory chips? Which
> bench/whatever for FBSD would you recommend to me so I know when/if I
> have a stable setup?
> I got more or less all available kernel errors, I started listing them
> on a postit, from a "GPF" to "freeing membuf twice" but when I had some
> 10 or so different error messages, I realised it couldn't be the code or
> so and went to my hardware. Thanks for you help though.
> Version: GnuPG v1.2.4 (FreeBSD)
> Comment: Using GnuPG with Mozilla -
> iD8DBQFAJ0dyKWyDo3z7ubcRAklyAJ9TQUkUzuQmcZeqxVVVvq+xLtdEfACff5mm
> Qy1nshfEFqwfojPYvRTyS4g=
> =scS5

Run 'memtest' which is a small standalone program to test your memory in 
patterns you choose. I used it from a Gentoo install CD but it does fit
on a floppy if anyone uses the things anymore. (Maybe the 64bit version
is different, but i don't why it would be.)

If you can produce any errors, either replace the offending module or reduce
the memory clock speed slightly.

Adjust the voltage to the memory slightly, up or down by about a tenth of
a volt each run and see if you can produce a repeatable no-error condition.

Experiment with reducing the memory clock speed and increasing the processor
clock speed. This can be tweaked to achieve complete stability. You will
probably find the optimum operating points are __not__ the defaults. The
amd64 is completely stable and should not crash randomly.

Keep in mind that each run can take several hours so start with the default
test first which takes a reasonable time to run and make it more complex if
you cannot get errors with the default settings. 

Ofcourse, make sure your hardware is solid and the voltages are stable. If
you are on the same power with fridges, vacuum cleaners, wash machines, etc.
try cleaner mains power! Strong RF energy can crash a computer. A friend 
put his GSM mobile phone on my keyboard, it happened to ring and the machine
crashed. This is a well known problem. 

Good luck,



More information about the freebsd-amd64 mailing list