Date: Wed, 3 May 2000 17:53:46 +0930 From: Greg Lehey <grog@lemis.com> To: Howard Leadmon <howardl@account.abs.net> Cc: freebsd-stable@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Debugging Kernel/System Crashes, can anyone help?? Message-ID: <20000503175346.S8284@freebie.lemis.com> In-Reply-To: <200005030748.DAA84934@account.abs.net> References: <200005030748.DAA84934@account.abs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 3 May 2000 at 3:48:42 -0400, Howard Leadmon wrote: > > Hello, > > I know I posted a few messages here in the past, but maybe someone who is > good at tracking kernel problems can step up and lend a hand. > > I have a machine running FBSD 4.0-STABLE, and have been experiencing almost > daily kernel panics or reboots on the machine. I have replaced ALL of the > hardware, and reloaded the OS, but still having troubles. I am at a bit of > a loss as to what is going on. From one panic, I thought well maybe this > is an SMP issue, but removed one of the CPU's and still the box crashes. As > I have basically replaced everything, I am at a loss as to where to go from > here, so looking for some type of pointers or help with this.. Indeed. We need to address this issue in some detail. We need both documentation and tools. > The other day I was there, and got the following from one of the > crashes, as many times I am gone and luckally in some ways the box > will just panicboot and go on it's way. Here is what I was able to > copy down: > > > Fatal trap 12: page fault while in kernel mode > mp_lock=01000002; cpuid=1; lapic.id=01000000 > fault virtual address= 0x30 > fault code= supervisor read, page not present > instruction pointer= 0x8:0xC01CAF71 > stack pointer= 0x10:0xFF80DE48 > frame pointer= 0x10:0xFF80DE4C > code segment= base 0x0, limit 0xFFFFF, type 0x1B > = DPL 0, pres 1, def 32, gran 1 > processor eflags= interrupt enabled, resume, IOPL=0 > current process = idle > interupt mask= bio <- SMP: XXX > trap number= 12 > panic: page fault > > The formatting of it may not be perfect, but the information should be > accurate, as I tried to be precise on what I wrote down. Also here are > a few previous messages I had posted a while back when I thought this > might be network related, but after trying several different NIC's I still > have the same issues. I will include the info below, as maybe it will > have some value in trying to debunk this problem. The sad thing is that this information is that most of this information is almost useless. I'm thinking of printing out a stack trace instead (comments, anybody?). Without tedious comparison with your kernel namelist, all we can say here is that you died somewhere in the kernel, that you have an SMP machine, and that the block I/O subsystem is probably involved. If this is happening daily, you should build a kernel with debugging symbols enabled and take a dump of the next crash. We can then use gdb to analyse the dump. > Hello, I am running a 4.0-STABLE machine which is being used to host an > Undernet IRC server, and the machine keeps dying at times, or should I say > the networking side of it is at least dying. At first I thought it might > have been related to the dc (DEC Chip) based drivers, so I replaced it with > a EEpro board using the fxp driver, but the same results. > > <snip> If all your dumps have the interrupt mask set to bio, I don't think it's a networking problem. With one possible exception... > Mar 27 12:39:00 u2 /kernel: fxp0: device timeout Søren and I are trying to find out what is causing some weird Vinum problems. He stated that the problem happened more frequently when an fxp board was in the system. I don't believe him, and I've found at least one bug in Vinum that has nothing to do with networking (but does have to do with the bio mask); possibly, however, there's some other problem with the fxp driver. It's possible that the other information will be of use, but I think we first need to look at a dump. 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-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000503175346.S8284>