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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

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

From: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost, 
netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/46221: Kernel panic in NFS server code
Date: Sun, 18 Mar 2012 17:06:09 +0100

 On Sun, Mar 18, 2012 at 03:55:00PM +0000, tron%zhadum.org.uk@localhost wrote:
 > >Number:         46221
 > >Category:       kern
 > >Synopsis:       Kernel panic in NFS server code
 > >Confidential:   no
 > >Severity:       serious
 > >Priority:       high
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Sun Mar 18 15:55:00 +0000 2012
 > >Originator:     Matthias Scheler
 > >Release:        NetBSD 6.0_BETA 2012-03-16 sources with fix for PR 
 > >kern/45677
 > >Organization:
 > Matthias Scheler                                  http://zhadum.org.uk/
 > >Environment:
 > System: NetBSD colwyn.zhadum.org.uk 6.0_BETA NetBSD 6.0_BETA (COLWYN.64) #0: 
 > Fri Mar 16 13:40:20 GMT 2012 
 > tron%colwyn.zhadum.org.uk@localhost:/src/sys/compile/COLWYN.64 amd64
 > Architecture: x86_64
 > Machine: amd64
 > >Description:
 > My NetBSD/amd646 6.0_BETA server has crashed three times during access by
 > a Mac OS X NFS client. It rebooted twice. But in one case it got stuck
 > and I could copy this traceback from the console:
 > 
 > printf_nolog() at netbsd:printf_nolog
 > wddump() at netbsd:wddump+0x23d
 > raiiddump() at netbsd:raiddump+0x227
 > dumpsys_seg() at netbsd:dumpsys_seg+0xb9
 > dump_seg_iter() at netbsd:dump_seg_iter+0xfb
 > dodumpsys() at netbsd:dodumpsys+0x273
 > dumpsys() at netbsd:dumpsys+0x1d
 > vpanic() at netbsd:vpanic+0x1dd
 > printf_nolog() at netbsd:printf_nolog
 > startlwp() at netbsd:startlwp
 > alltraps() at netbsd:alltraps+0xa2
 > ffs_fhtovp() at netbsd:ffs_fhtovp+0x55
 > VFS_FHTOVP() at netbsd:UFS_FHTOUP+0x1c
 > nfsrv_fhtovp() at netbsd:nfsrv_fhtovp+0x9a
 
 Could you build a kernel with makeoptions    DEBUG="-g", reboot it
 and try to reproduce the problem ? It would be interesting to see where
 ffs_fhtovp+0x55 points to in sources.
 Also, if you don't get a crash dump, please set ddb.onpanic=1 so that
 we get the kernel panic message, the instruction that faulted, and you can
 dump registers content (it looks like it's a trap, so 'sh registers' will
 print something interesting).
 
 -- 
 Manuel Bouyer <bouyer%antioche.eu.org@localhost>
      NetBSD: 26 ans d'experience feront toujours la difference
 --