> > #12 0xc028375e in panic ()
> > (gdb) 
> > #13 0xc03134ce in trap ()
> > (gdb) 
> > #14 0xc0100bf7 in calltrap ()
> > (gdb) 
> > #15 0xc02a7021 in genfs_putpages ()
> > (gdb) disass
> 
> > 0xc02a7017 <genfs_putpages+1087>:       push   $0x40
> > 0xc02a7019 <genfs_putpages+1089>:       push   $0x0
> > 0xc02a701b <genfs_putpages+1091>:       push   %esi
> > 0xc02a701c <genfs_putpages+1092>:       call   0xc0311248 <pmap_change_attrs>
> > 0xc02a7021 <genfs_putpages+1097>:       add    $0x10,%esp
> > 0xc02a7024 <genfs_putpages+1100>:       test   %eax,%eax
> 
> 
> Hmmm.... gbd strickes again - failing to give a traceback that includes
> anything to do with the routine that actually exploded.
> 

Not necessarily.  It could be the compiler optimizing away certain stack 
frames (or tail-calling from one routine to another).  The return address 
you have shows the instruction after the call to pmap_change_attrs, so you 
probably want to disassemble that -- of course, that might have 
tail-called as well.

Finally, it might just be that the trap insertion code fails to set up a 
frame chain properly in certain cases, in which case it would be NetBSD's 
fault ;-)

> The stack traceback also 'usefully' fails to give either the %esp
> or %ebp value for each frame.
> 
> All done just to make life more interesting :-)
> 

All part of life's obstacle course...

R.