Date: Wed, 7 Sep 2011 12:50:49 -0700 From: mdf@FreeBSD.org To: Charlie Martin <crmartin@sgi.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Understanding panic and exit in the kernel Message-ID: <CAMBSHm8XSDB59=JnPB1B0BLWvoQ2AYxMobghh4h=bX2Y1POw3g@mail.gmail.com> In-Reply-To: <4E67C4E6.40009@sgi.com> References: <4E67B323.8000602@sgi.com> <CAMBSHm98=FykYxuWKEEvwA5fZsiDiUTtbCYhGEMig_gfyOa5cg@mail.gmail.com> <4E67C4E6.40009@sgi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 7, 2011 at 12:24 PM, Charlie Martin <crmartin@sgi.com> wrote: > > > On 2011-09-07 12:53, mdf@FreeBSD.org wrote: >>> >>> For my immediate purposes, I'd be happy with any way in which I could >>> > =A0brutally kill the kernel and force it to the debugger, say by >>> > replacing the >>> > =A0panic call with a printf followed by "1/0;". =A0But I'm a little >>> > confused by >>> > =A0the panic.c code -- it prints the arguments using a var_args, and = then >>> > calls >>> > =A0"exit(1);' >> >> What file are you looking in? =A0The kernel panic() is in >> sys/kern/kern_shutdown.c, not sys/boot/common/panic.c. =A0It will >> optionally call kdb_enter_why() and then boot(). > > Bingo, that's got to help. =A0This makes a lot more sense. > >> Do you have the debug.debugger_on_panic sysctl set to 1? > > Yes -- and panic does so *except* in the version with those changes to > queue.h. If all you need to get started is a backtrace then debug.trace_on_panic=3D1 may be sufficient. I'm not sure of the timeline when 7.2-prerelease was issued, but there have been some reliability improvements to panic handling including marking that a CPU is in panic, etc., that may have come after 7.2-prerelease. You may want to look at the svn history for kern_shutdown.c and locally apply those changes to see if it changes your result. Cheers, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm8XSDB59=JnPB1B0BLWvoQ2AYxMobghh4h=bX2Y1POw3g>