Date: Thu, 21 Dec 1995 17:48:42 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: jgreco@mei.com Cc: hackers@freebsd.org Subject: Re: Problems with crash dumps not dumping Message-ID: <199512211648.AA12735@Sysiphos> In-Reply-To: Joe Greco <jgreco@solaria.sol.net> "Problems with crash dumps not dumping" (Dec 21, 9:53)
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 21, 9:53, Joe Greco wrote: } Subject: Problems with crash dumps not dumping } I've been trying to catch a useful crash dump under 2.1.0R on my news } server. John Dyson had suggested that it would be helpful to see a crash } dump in order to debug some VM/mmap issues (? etc) or something or other, I } don't quite remember exactly what since it's been a few weeks. } } Anyways. I enabled the crash dump stuff, and when the machine panics with a } "panic: free vnode isn't" error, it appears to start the dump but then locks } with "dumping... XXXX" where XXXX is some fairly large number. The root } drive light and controller activity light are both on (NCR-810). I've seen } this happen several times now. I believe it worked correctly before the } dumps were enabled. I never tested, whether writing kernel cores works with the NCR driver. This is a special situation, since the driver is called with interrupts disabled, and I just never tested, whether this is supported by the driver. (It IS supported at SCSI bus probe time, since the kernel probes with interrupts disabled. But I'm not sure, whether the driver will work in this mode again, later, wenn it once had been running on interrupts). This could also be a bug outside the driver, since the driver needs the SCSI_NOSLEEP flag set, if interrupts are disabled, and I did not yet check, whether this is actually the case in the dump code. } Also, again, I am noticing a direct correlation to running out of inodes and } this particular panic. When my alt.* drive (4096/512) died, I moved the } alt.* hierarchy onto my alt.binaries.* drive (8192/1024, less inodes) and } I've been hitting 100% inodes every once in a while. If an "out of inodes" situation crashes the system, then any user could bring it down easily. This looks like a bad thing. Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512211648.AA12735>