Signal 11's all over the place.

[readpunk]

That is what I believe is happening, which is why I suspect the cpu and
not memory. If I do anything that stresses the server (raises the cpu%
even when the server is reporting more than enough ram) it will just
completely lock and sometimes reboot on it's own. I mention the sig. 11's
because I am seeing them in the logs httpd/perl/hlds/top etc. The box has
locked up while _only_ running memtest, ha ha. I suppose I need to take
out each dimm and really stress the box. If it does well with one and not
the other I suppose my answer is found, if not then it has to be the cpu.
Thanks for the help all.

Nick

On Tue, 26 Aug 2003, Matthew Seaman wrote:

> Date: Tue, 26 Aug 2003 11:53:45 +0100
> From: Matthew Seaman <m.seaman at infracaninophile.co.uk>
> To: readpunk <readpunk at sdf1.org>
> Cc: freebsd-questions at freebsd.org
> Subject: Re: Signal 11's all over the place.
>
> On Tue, Aug 26, 2003 at 05:10:20AM +0000, readpunk wrote:
> > Signal 11's from different programs and near complete instability usually
> > means a fan/heatsink issue, correct?
> >
> > FreeBSD 4.8-release
> > Athlon 2400 XP+
> > 1 gigabyte of RAM
> >
> > Is anything else really necessary? Occasionally right after a reboot when
> > I run top the thing crashes (the machine is remote) when it does get a
> > little spat of stability for whatever reason it seems to allocate ram fine
> > and run properly. Thanks to anyone who reads this.
>
> It might be overheating -- but that generally results in the system
> simply freezing up when the CPU thermal cutout engages.  Instinct
> tells me that seeing a lot of Sig 11's like you are could very well be
> due to duff memory -- it's not impossible for the memory sticks to
> overheat but more likely they've just developed a bad spot.
>
> If you have console access to the machine, try running a memtest86
> floppy (http://www.memtest86.com/) for a few repetitions (or get the
> NOC people at your hosting center to do it for you) That will take
> most of a day probably.  Note that when memtest86 does find a problem
> then it's almost always genuine, but some subtle problems can elude
> it, so getting the all clear from it doesn't completely discount
> problems with the memory.
>
> Otherwise, try pulling out each half of the memory sticks in turn and
> see if that can isolate the fault.  However, that won't help you if
> the problem is within the CPU, unless you can lay your hands on a
> known good spare to swap in and test with.
>
> 	Cheers,
>
> 	Matthew
>
> --
> Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
>                                                       Savill Way
> PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
> Tel: +44 1628 476614                                  Bucks., SL7 1TH UK
>

/* Try unix. Then ./revolution */