On Sat, 30 Dec 2006, Karol Kwiatkowski wrote:
Robert Watson wrote:
On Sat, 30 Dec 2006, Karol Kwiatkowski wrote:
Robert Watson wrote:
P.S. out of curiosity - now that I have configured kernel with DDB and
KDB options, is there any performance penalty of running such kernel?
No, it shouldn't really have any effect on performance. The one thing to
watch out for is that your system will no longer reboot automatically on
a panic, as it will drop to the debugger, by default. You can change
this by setting debug.debugger_on_panic to 0, in which case you will
likely want to set debug.trace_on_panic to 1 so it prints a stack trace
before rebooting (which is often sufficient, combined with the trap frame
and panic message to debug the problem).
Right now these are sysctls, not tunables, but you can change the default
using options KDB_UNATTENDED (which flips the default to not entering the
debugger and rebooting) and options KDB_TRACE (which causes a trace to be
printed on panic by default). Probably they should also be tunables so
that loader.conf entries will work.
Great explanation, thank you. I turned on debugging on my desktop computer
which, apart from normal every day use, is 'testing' STABLE by running it
:) I'm perfectly fine with the defaults, at least for now.
BTW, I have added some new documentation to the Developer's Handbook on the
various copmile-time kernel debugging options, what their impact is, etc:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-options.html
The kernel debugging section of the Developer's Handbook seems to be getting a
bit long in the tooth, I may have a chance to do some further updating of it
this weekend. In particular, it seems to focus mostly on crash dumps, and
many problems are more easily debugged using information in DDB.
BTW, if you're running X on your desktop, be aware that it's X that does
all the video mode management. If your box enters the debugger while in X,
the debugger doesn't know how to switch back to text mode (and X isn't
running, obviously), so while you'll be talking to the debugger, the
chances you'll see anything comprehensible are actually quite low. For this
reason, I normally also use a serial console when debugging desktop boxes:
I can always plug my notebook in with a serial cable to see why it's
entered the debugger.
Right, I haven't thought about that. I guess without a serial console my
best option is to set debug.debugger_on_panic to 0, debug.trace_on_panic to
1 and keep crash dump with kernel.debug for later examination, isn't it? The
whole point of doing this, as I am not really experienced in debugging, is
to have the information saved somewhere in case of a panic.
Yes -- if you have no firewire/serial console option (i.e., no extra notebook
and null modem cable, or no serial port), then crash dumps are the best way to
go. Setting the sysctls as above is good.
Something I've been thinking of doing for a while is adding a scripting
facility to DDB, which would allow you to have a script of DDB commands run on
crash but before the dump, displaying useful debugging information which would
then appear in the dump itself...
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
