Date: Wed, 24 Apr 1996 01:49:05 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@GndRsh.aac.dev.com> To: scrappy@ki.net (Marc G. Fournier) Cc: msmith@atrad.adelaide.edu.au, jkh@time.cdrom.com, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Intelligent Debugging Tools... Message-ID: <199604240849.BAA04097@GndRsh.aac.dev.com> In-Reply-To: <Pine.NEB.3.93.960423234546.5610A-100000@freebsd.ki.net> from "Marc G. Fournier" at "Apr 23, 96 11:46:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> On Wed, 24 Apr 1996, Michael Smith wrote: > > > Don't waste any money on it. If you get it as a freebie, that's fine, > > but they're honest enough in the manual to point out that their tests > > aren't anything compared to the load a mutltitasking VM OS imposes. > > > > (We got it Real Cheap when we were having RAM trouble; it didn't find the > > problem, and this was a RAM error so bad that _Windows_ would barf.) > > > > I've got 9 make processes running in /usr/src/lib right now, > and will cycle those through for the next little while...that should give > it a good test, shouldn't it? That with the rest of its normal load? One of the bests tests I use for doing the divide and conquere (swap parts) in locating hardware related system failures (something I do as a weekly event) is simply repeated ``make worlds''. Unless you have _lots_ of memory (>32MB) multiple builds of /usr/src/lib are just going to thrash the paging/swap area to death. Besides library code compiles easily do to the small sizes of the source and produced object files, use a monster compile like gcc/g++. What you are looking for is signal 6's, 10's and 11's, which generally point to memory (cache or main) related system failures. Panics can be just about anything from the CPU chip to the I/O cards. -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Reliable computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604240849.BAA04097>