[ redirected to port-i386 ]

On Sat, Jan 28, 2006 at 12:48:30PM +0000, Darren Reed wrote:
> > [...]
> > The system is seriously messed up then. Maybe something has overwritten
> > the page tables, or something like that. But the most common problem leading
> > to a non-working ddb is when the stack pointer has jumped to nowhere, or
> > the kernel is out of stack space (too much data allocated on stack, or
> > recursive function call). I would recommend setting printing the register
> > contents in addition to the stack trace, to see the stack pointer value
> > (options DDB_COMMANDONENTER="trace;show registers")
> 
> So what does this tell you ?
> 
> >From a digital camera:
> -------------------------
> fatal protection fault in supervisor mode
> trap type 4 code 7fb eip c0100b7f cs 8 eflags 10246 cr2 804eeac ilevel 0
> panic: trap
> Begin traceback...
> trap() at netbsd:trap+0x149
> --- trap (number 4) ---
> cpu_switch(c0363ba0,0,ca342000,282,c0365a20) at netbsd:cpu_switch+0x9f
> fatal protection fault in supervisor mode
> trap type 4 code 7fb eip c0100b7f cs 8 eflags 10246 cr2 804eeac ilevel 0
> Faulted in mid-traceback:aborting...
> <system hang>

So DDB_COMMANDONENTER="trace" would probably have worked as well.
Can you see where 0xc0100b7f points in your kernel ?
I suspect cpu_switch() or trap().
If you use DDB_COMMANDONENTER="show registers; trace" (in this order as
trace doesn't completely work) we would also have the esp (stack pointer)
value.

Also, with gdb on your kernel binary could you do: disas cpu_switch+0x9f ?
You could also try disas 0xc0100b7f

On my kernel cpu_switch+0x9f points to the "nop" of idle_loop, but it
will be different if you have DEBUG, LOCKDEBUG or MULTIPROCESSOR.

My current theory is that cpu_switch(), while restoring a context, loaded
%esp with a bogus value.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--