Date: Tue, 23 Apr 1996 22:28:37 -0400 (EDT) From: "Marc G. Fournier" <scrappy@ki.net> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: hasty@rah.star-gate.com, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Intelligent Debugging Tools... Message-ID: <Pine.NEB.3.93.960423221546.3520F-100000@freebsd.ki.net> In-Reply-To: <199604240151.LAA13635@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Apr 1996, Michael Smith wrote: > Ok. This guy is known to work pretty well, as long as you avoid ISA > busmasters. > Nope, only cards are the NCR SCSI, ATI video and SMC8013 Ethernet > > sctarg0(noadapter::): Processor Target > > Wozzis? You have a scanner or something? > *shrug* nothing else other then those three cards in the machine... > > Oh, the motherboard is an ACER AP43 with a 486DX4-100 > > CPU, and sio[01] are both onboard serial. > > Jumpered for write-back or write-through? Which cache Tagram are you > using? Is the board jumpered correctly for it? > will check the wb/wt...what do you mean by cache Tagram? > > The memory is one 16Meg SIMM, and pstat shows: > > Speed? Manufacturer? > Unknown...will have to shut down to check, but will do so after I send this out... > > My two most recent panics had to do with vm_page_alloc(), which > > I *think* have to do with swap -or- RAM, and pmap_zero_page(), both of > > which I've been told no one else is experiencing (and I've gone through > > the GNaTs database for anything similar to no avail), which I believe. > > The problem, such as it is, is that these pieces of code depend intimately > on some _very_ heavily accessed parts of memory, and if there's anything > wrong with these parts of memory, they cause a panic. > Okay, that part I don't have a problem with, but, if it detects that something is wrong, why doesn't it try (or does it?) to work around the problem? Map out the offending area of memory? As well, does this restrict the problem to cache/RAM vs swap space? I'm don't yet understand how swap space works (I know what it does, just not how), but I presume that the swap space is a psuedo-file system? Since I'm on SCSI, I would assume that it would auto-remap defective areas in the swap space, if my first assumption is correct? I can understand having bad luck with one machine, but I have three machines here, all with different hardware and they all have "hardware related" panics, two are -stable, one is -current (so I kind of expect problems with the third) After getting rid of that bad drive that cause the SCSI locks (which, mind you, is running great in another machine, solo on the SCSI bus...go figure), I've been able to get 7+days uptime on my machines. -current machine == 8+ days (rebooted to install new kernel) -stable machine 1 == 9+ days (panic'd...vm related) -stable machine 2 == 5+ days and still running) So I'm getting *somewhere*...just very slowly :( Will check the RAM/cache and get back to you... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.93.960423221546.3520F-100000>