debugging kernel options

[Robert Watson]

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