Date: Sun, 24 Sep 2000 09:54:10 +0930 From: Greg Lehey <grog@lemis.com> To: Steve Roome <steve@sse0691.bri.hp.com>, freebsd-stable@FreeBSD.ORG Subject: Re: Makeworld is dying... Message-ID: <20000924095410.A65590@wantadilla.lemis.com> In-Reply-To: <20000918154418.P8111@moose.bri.hp.com>; from steve@sse0691.bri.hp.com on Mon, Sep 18, 2000 at 03:44:18PM %2B0100 References: <39C42DF4.978A63C@urx.com> <Pine.LNX.4.10.10009170918240.13465-100000@shark.harmonic.co.il> <20000917160006.D67912@wantadilla.lemis.com> <20000918154418.P8111@moose.bri.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 18 September 2000 at 15:44:18 +0100, Steve Roome wrote: > On Sun, Sep 17, 2000 at 04:00:06PM +0930, Greg Lehey wrote: >> What you *should* do before sending out a reply like this is to check >> whether it's really in the FAQ or not. It is >> (http://www.freebsd.org/FAQ/troubleshoot.html#AEN1570): > > There's a lot of people who are quick to step up to the podium and > proclaim that all these signal elevens are caused by bad RAM, or bad > RAM settings. It *could* be a pointer arithmetic problem. > > The FAQ ought to comment on this, and from recent personal experience, > the number of people who respond to these just quoting the FAQ gets > more annoying each time, mainly because it's something that doesn't > need to be said on the mailing lists... again. OK, there were a couple of things in the original message which suggested bad hardware rather than buggy software. In particular, it happened during a 'make world', and it happened in different places every time. > In this case, it is possibly bad hardware, so maybes it's a fair > call, then again it can be caused by, e.g. freaky optimizations in > gcc... Not if it happens in different places each time. > So could we change the text (something like, but better worded than > the following) in the FAQ, e.g. : > > Q: My programs occasionally die with Signal 11 ( or 10 ). > > A: Signal 11 errors are caused when your process has attempted to > access memory which the operating system has not granted it access > to. > > This could be caused by a number of different circumstances : > > a) Most likely, if you're developing it yourself it's buggy > code. (We've all been there!) > > b) If it's a problem with part of the base FreeBSD system, > it might be buggy code, but more often than not these problems > are found long before us general FAQ readers get to use these > bits of code. > > If these problems are only affecting you, it's probably bad > hardware. > > In the case of a) you can use a debugger and find the point > in the program which is attempting to access a bogus address > and then fix it. [ you probably already know this if you're > a programmer! ] > > In the case of b) You need to verify the settings on your > motherboard. Checking for hardware you might be running slightly > out of spec, too fast, or mismatched hardware. Often setting > memory wait states too short will trigger random signal 11's. > An overclocked CPU will possibly also exhibit strange or similar > symptoms. > > Try running some memory testing programs, or do a make buildworld > if you have the full source available for FreeBSD (after a few > successful buildworlds it's probably safe to say the hardware > is okay.). > > See the SIG11 FAQ (LINK) for more information. > > That's my idea for a rough draft anyway. I'm clearly illiterate > though, please don't flame me for that! You need to work in the observation that if it always happens in exactly the same place, it's probably software, and if it happens at random, it's probably hardware. While you (collective you) are at it, there are plenty of other things in the FAQ which could do with looking at. The doc project would welcome you with open arms. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000924095410.A65590>