On Wed, Sep 7, 2011 at 12:24 PM, Charlie Martin <crmar...@sgi.com> wrote: > > > On 2011-09-07 12:53, m...@freebsd.org wrote: >>> >>> For my immediate purposes, I'd be happy with any way in which I could >>> > brutally kill the kernel and force it to the debugger, say by >>> > replacing the >>> > panic call with a printf followed by "1/0;". But I'm a little >>> > confused by >>> > the panic.c code -- it prints the arguments using a var_args, and then >>> > calls >>> > "exit(1);' >> >> What file are you looking in? The kernel panic() is in >> sys/kern/kern_shutdown.c, not sys/boot/common/panic.c. It will >> optionally call kdb_enter_why() and then boot(). > > Bingo, that's got to help. This 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=1 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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
