Re: kern/46221: Kernel panic in NFS server code

[Matthias Scheler <tron%zhadum.org.uk@localhost>]

The following reply was made to PR kern/46221; it has been noted by GNATS.

From: Matthias Scheler <tron%zhadum.org.uk@localhost>
To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: NetBSD GNATS <gnats-bugs%NetBSD.org@localhost>
Subject: Re: kern/46221: Kernel panic in NFS server code
Date: Sun, 18 Mar 2012 22:32:25 +0000

 On Sun, Mar 18, 2012 at 07:16:28PM +0100, Manuel Bouyer wrote:
 > (gdb) l *(ffs_fhtovp+0x55)
 > 0xffffffff801af684 is in ffs_fhtovp (/usr/src/sys/ufs/ffs/ffs_vfsops.c:1907).
 > 1902    /usr/src/sys/ufs/ffs/ffs_vfsops.c: No such file or directory.
 >         in /usr/src/sys/ufs/ffs/ffs_vfsops.c
 > 
 > But this is at the very end of ffs_fhtovp(). I don't know if ddb is somewhat
 > confused when computing the stack trace, or something else.
 > 
 > (gdb) x/i ffs_fhtovp+0x55
 >    0xffffffff801af684 <ffs_fhtovp+85>:  leaveq 
 > (gdb) disas ffs_fhtovp
 > [...]
 >    0xffffffff801af67f <+80>:    callq  0xffffffff8042b0f3 <ufs_fhtovp>
 >    0xffffffff801af684 <+85>:    leaveq 
 >    0xffffffff801af685 <+86>:    retq   
 > 
 > Either ddb skipped the call to ufs_fhtovp (and so the place where it
 > crashed in ufs_fhtovp) or the stack is corrupted.
 > The exact trap message from ddb and the register dump would be usefull.
 
 I'll try to get that the next time.
 
        Kind regards
 
 -- 
 Matthias Scheler                                  http://zhadum.org.uk/