On Sat, Jan 28, 2006 at 02:48:38PM +0100, Manuel Bouyer wrote:
> > >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().

cpu_switch()

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

This doesn't exist in 3.0

> You could also try disas 0xc0100b7f

(gdb) disas cpu_switch+0x9f
Dump of assembler code for function idle_loop:
0xc0100b73 <idle_loop>: mov    0xc0367668,%ecx
0xc0100b79 <idle_loop+6>:       test   %ecx,%ecx
0xc0100b7b <idle_loop+8>:       jne    0xc0100b63 <idle_zero>
0xc0100b7d <idle_loop+10>:      sti
0xc0100b7e <idle_loop+11>:      hlt
0xc0100b7f <idle_loop+12>:      nop
End of assembler dump.

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

Nasty.

Darren