From owner-freebsd-stable@FreeBSD.ORG Wed Dec 8 12:17:04 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3425F16A4CF for ; Wed, 8 Dec 2004 12:17:04 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0DA8243D58 for ; Wed, 8 Dec 2004 12:17:03 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail 20406 invoked by uid 65534); 8 Dec 2004 12:17:01 -0000 Received: from p3EE2699E.dip.t-dialin.net (EHLO lofi.dyndns.org) (62.226.105.158) by mail.gmx.net (mp024) with SMTP; 08 Dec 2004 13:17:01 +0100 X-Authenticated: #443188 Received: from kiste.my.domain (kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id iB8CGpLw013265 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 8 Dec 2004 13:16:55 +0100 (CET) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: Robert Watson Date: Wed, 8 Dec 2004 13:16:46 +0100 User-Agent: KMail/1.7.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1734767.4xPNOPy8dT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200412081316.50578.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: freebsd-stable@freebsd.org Subject: Re: crashdumps not working X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2004 12:17:04 -0000 --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--