How to debug a double fault? (Re: Could MSGBUF_SIZE be made a loader tunable?)

[Andriy Gapon]

on 16/12/2010 11:34 perryh at pluto.rain.com said the following:
> Andriy Gapon <avg at freebsd.org> wrote:
>> on 15/12/2010 12:37 perryh at pluto.rain.com said the following:
>>> Fatal double fault:
>>> eip = 0xc07feb98
>>> esp = 0xc101e000
>>> ebp = 0xc101e004
>>> cpuid = 0; apic id = 00
>>> panic: double fault
>>> cpuid = 0
>>>
>>> How do I go about tracking this down?
>>
>> Do you have the standard debugging options in your kernel?
> 
> No, it is 8.1-RELEASE GENERIC with only the name changed and the
> (first attempt) msgbufsize patches applied.  I was trying to
> minimize changes to GENERIC, so as to minimize the opportunity
> to screw something up, and I had this silly idea that something
> this simple might "just work."
> 
> It does occur to me to wonder whether any debugger would be
> functional this early, before even the first line of the signon
> message has been displayed.  Is it possible, given the loader
> messages, to come up with a base address which could be used to
> compare the eip value with the kernel symbol table?  Granted this
> won't provide a traceback, but even knowing in which function it
> crashed would be a start.

You can research this approach, but I would just add KDB+DDB and get a stack
trace without sweat.

>> BTW, are you sure that you correctly placed initialization of
>> msgbufsize ?
> 
> I am not at all sure of that, and am not sufficiently familiar with
> the sequence of events early in intiialization to know how to find
> out -- although I suppose the observed crash might not be altogether
> surprising if the kernel message buffer got allocated with a zero
> size :(
> 
> Apart from the name, msgbufsize is set up in exactly the same
> way and place -- in init_param1() -- as maxswzone and maxbcache.
> Perhaps that is not early enough; any idea what would be a better
> example?

I don't see any connection between msgbufsize and maxswzone, so I also don't
know if that place is early enough.
Just try to initialize the variable where it's defined and use TUNABLE_LONG.

-- 
Andriy Gapon