Date: Wed, 24 Apr 1996 11:21:37 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: scrappy@ki.net (Marc G. Fournier) Cc: hasty@rah.star-gate.com, current@FreeBSD.org, hackers@FreeBSD.org Subject: Re: Intelligent Debugging Tools... Message-ID: <199604240151.LAA13635@genesis.atrad.adelaide.edu.au> In-Reply-To: <Pine.NEB.3.93.960423174633.1690B-100000@freebsd.ki.net> from "Marc G. Fournier" at Apr 23, 96 06:00:06 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Marc G. Fournier stands accused of saying: > FreeBSD 2.1-STABLE #0: Tue Apr 23 10:33:56 EDT 1996 > scrappy@ki.net:/usr/src/sys/compile/kinet > CPU: i486 DX4 (486-class CPU) > Origin = "GenuineIntel" Id = 0x480 Stepping=0 > Features=0x3<FPU,VME> > real memory = 16777216 (16384K bytes) > avail memory = 14835712 (14488K bytes) > Probing for devices on PCI bus 0: > chip0 <SiS 85c496> rev 49 on pci0:5 Ok. This guy is known to work pretty well, as long as you avoid ISA busmasters. > sctarg0(noadapter::): Processor Target Wozzis? You have a scanner or something? > 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? > The memory is one 16Meg SIMM, and pstat shows: Speed? Manufacturer? > 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. > And I have no problems believing that it *may* be a hardware > problem, but what would be nice is some non-"trial and error" method of > narrowing down the problem. Some way of having the panic that vm_page_alloc() > produces send out an error message that states *where* the panic occurred... > ie. in RAM or in swap space, or as a result of either. Check the source of the panic in the code, and there you have it. > Marc G. Fournier scrappy@ki.net -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604240151.LAA13635>