Date: Wed, 8 Dec 2004 13:16:46 +0100 From: Michael Nottebrock <michaelnottebrock@gmx.net> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-stable@freebsd.org Subject: Re: crashdumps not working Message-ID: <200412081316.50578.michaelnottebrock@gmx.net> In-Reply-To: <Pine.NEB.3.96L.1041208115235.98791H-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1041208115235.98791H-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1734767.4xPNOPy8dT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday, 8. December 2004 12:54, Robert Watson wrote: > On Wed, 8 Dec 2004, Michael Nottebrock wrote: > > On Wednesday, 8. December 2004 12:20, Robert Watson wrote: > > > On Tue, 7 Dec 2004, Michael Nottebrock wrote: > > > > I recently enabled SW_WATCHDOG in my kernel, but when watchdog > > > > triggers a panic, no crashdump is taken although dumps are enabled. > > > > What could be causing this? > > > > > > If you drop to the debugger by using the debug.kdb.enter sysctl, and = do > > > "call doadump", followed by a reset, does a dump get generated > > > successfully? > > > > I don't have kdb enabled in my kernel configuration at all... > > I'm guessing it might be useful at this point, if possible :-). Useful for what exactly? I'm mainly interested in getting this machine to=20 auto-reboot after a (watchdog-triggered) panic, crashdumps are a bonus. At= =20 the moment, it will just hang on a panic (even if I do not enable crashdump= s=20 in rc.conf, it won't reset), and since it's usually running X, it will just= =20 stand there while the CRTs burn in. If you think you can get a clue as to w= hy=20 it wouldn't crashdump or reset by something I can do in kdb, I will enable= =20 it ... > Do you=20 > have a serial console on the box, or could you set one up? Nope, this is the only machine with a keyboard and a monitor attached. > > > > I.e., are they completely broken on your system, or is this > > > somehow a property of the particular hang you're seeing. > > > > See my other mail, a different (non-watchdog) panic didn't trigger a du= mp > > either. I even had the panic message in dmesg: > > > > kernel trap 12 with interrupts disabled > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address =3D 0x14c > > fault code =3D supervisor write, page not present > > instruction pointer =3D 0x8:0xc0521397 > > stack pointer =3D 0x10:0xe9794b84 > > frame pointer =3D 0x10:0xe9794b90 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D resume, IOPL =3D 0 > > current process =3D 1281 (beep-media-player) > > trap number =3D 12 > > panic: page fault > > This is a NULL pointer dereference; you can use addr2line or gdb on your > kernel.debug to turn it into a line number even without a core. That > might well be worth doing, as we might be able to debug that even without > getting dumping working on the box. It's a SCHED_ULE + PREEMPTION triggered panic, probably there's no point in= =20 investigating it at this point, as _ULE has been demoted to abandonware :-(. > Syncing on panic is, in general, probably not going to make it work better > than not. I guess there's no chance the box has an NMI button? Right. I just enabled it for the SW_WATCHDOG experiments (which made me=20 discover that this machine would just get stuck on panics in the first=20 place), I already turned it off again. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1734767.4xPNOPy8dT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBtvCyXhc68WspdLARArbWAJ9LI0bhZZ2ay89CUPfDTrI8mc1WCQCfV/qe Q2ivCNWfcbygQawZbF+gYWA= =WJha -----END PGP SIGNATURE----- --nextPart1734767.4xPNOPy8dT--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200412081316.50578.michaelnottebrock>