debugging kernel options (was: Re: 6.2-PRE: Fatal Trap?)

[Robert Watson]

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, 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.

Robert N M Watson
Computer Laboratory
University of Cambridge