>Number:         36572
>Category:       kern
>Synopsis:       panic on NFS unmount
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 28 08:40:00 +0000 2007
>Originator:     Martin Husemann
>Release:        NetBSD 4.99.21
>Organization:
>Environment:
System: NetBSD nelly.aprisoft.de 4.99.21 NetBSD 4.99.21 (NELLY) #5: Wed Jun 27 05:09:38 CEST 2007 martin@emmas.aprisoft.de:/nelly/usr/src/sys/arch/sparc64/compile/NELLY sparc64
Architecture: sparc64
Machine: sparc64
>Description:

When rebooting a diskless machine after quite some NFS usage I hit this panic:

panic: nfs_inactive: vp=0xd6dd9e0 error=0

nfs_inactive() + 0x13c
VOP_INACTIVE()
vclean()
vgonel()
vflush()
nfs_unmount()
dounmount()
vfs_unmountall()

It has a big XXX comment:

0x1047d5c is in nfs_inactive (../../../../nfs/nfs_node.c:272).
267                      */
268     
269                     error = vn_lock(sp->s_dvp, LK_EXCLUSIVE | LK_CANRECURSE);
270                     if (error || sp->s_dvp->v_data == NULL) {
271                             /* XXX should recover */
272                             panic("%s: vp=%p error=%d", __func__, sp->s_dvp, error);
273                     }
274                     nfs_removeit(sp);
275                     kauth_cred_free(sp->s_cred);
276                     vput(sp->s_dvp);

What is this test for? Is it to protect vput()? But nfs_unlock() already deals
with v_data == 0. Or has this vnode been reclaimed already (how could I tell
from ddb?)

Might this be related to PR kern/36424 (wishfull thinking).

>How-To-Repeat:

I used the / on NFS for a day (including a build.sh run) and then rebooted.

>Fix:
no idea, sorry.