>Number:         31979
>Category:       kern
>Synopsis:       panic: lockmgr: release of unlocked lock
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 02 11:27:00 +0000 2005
>Originator:     Manuel Bouyer
>Release:        NetBSD 2.1_RC6
>Organization:
LIP6/ASIM
>Environment:
System: NetBSD pop.lip6.fr 2.1_RC6 NetBSD 2.1_RC6 (GENERIC.MPDEBUG) #0: Tue Oct 18 18:13:47 CEST 2005 bouyer@pop.lip6.fr:/local/pop1/bouyer/tmp/i386/obj/local/pop1/bouyer/netbsd-2/src/sys/arch/i386/compile/GENERIC.MPDEBUG i386
Architecture: i386
Machine: i386
>Description:
	This dual-CPU box has a filesystem mounted from a NFS server (hard,
	intr). For some reason, the server became unreachable for more than
	a day (2 daily cron job should have run in this situation).
	After some time, the kernel vnode table was full (I guess because lots
	of processes were waiting for the NFS server), and the system paniced
	shortly after with the message in $SUBJECT. Here is the last bits on
	the serial console, unfortunably I couldn't get a core dump.

nfs_timer: ignoring error 55
nfs_timer: ignoring error 55
vnode: table is full - increase kern.maxvnodes or NVNODE
vnode: table is full - increase kern.maxvnodes or NVNODE
vnode: table is full - increase kern.maxvnodes or NVNODE
panic: lockmgr: release of unlocked lock!
db{1}> tr/l 
cpu_Debugger(c238ee00,1,c075e440,6,0) at netbsd:cpu_Debugger+0x4
panic(c075e740,c075e440,200,0,0) at netbsd:panic+0x121
_lockmgr(cdc071e8,6,cdc09164,c0764f20,29d) at netbsd:_lockmgr+0x108
layer_unlock(cef78dd4,cd71da80,84000,cef78ee4,c05f4fc0) at netbsd:layer_unlock+0x56
VOP_UNLOCK(cdc09164,0,511,c2048800,17) at netbsd:VOP_UNLOCK+0x28
vput(cdc09164,cef78ee4,cef78ef8,cef78ee4,cf032000) at netbsd:vput+0x5c
lookup(cef78ed4,cf032000,400,cef78eec,cdcc8088) at netbsd:lookup+0x29c
namei(cef78ed4,c0828b40,cef78f0c,c0375596,807c000) at netbsd:namei+0x138
sys_lchmod(cdceaa54,cef78f64,cef78f5c,112,0) at netbsd:sys_lchmod+0x40
syscall_plain() at netbsd:syscall_plain+0x17e
--- syscall (number 274) ---
0x48093baf:
db{1}> mach cpu 0
using CPU 0
db{1}> tr/l
acquire(c0828b40,cfb7d7cc,400000,0,600) at netbsd:acquire+0x53
_spinlock_acquire_count(c0828b40,1,c0760880,3d1,cdcead6c) at netbsd:_spinlock_acquire_count+0x99
mi_switch(cdcead6c,0,c0387638,cdcead6c,a) at netbsd:mi_switch+0x1e7
ltsleep(c235b2e0,18,c05f4476,1f4,0) at netbsd:ltsleep+0x4c7
sbwait(c235b2d0,43fe384,cfb7d8ec,c013fb7a,7f) at netbsd:sbwait+0x3a
soreceive(c235b258,cfb7d9c8,cfb7d954,cfb7d9cc,0) at netbsd:soreceive+0xd87
nfs_receive(c2507cc0,cfb7d9c8,cfb7d9cc,f800d8da,0) at netbsd:nfs_receive+0x4d1
nfs_reply(c2507cc0,0,3b9aca00,0,c0825f00) at netbsd:nfs_reply+0x47
nfs_request(cd686bc4,c2807600,4,cc272cd0,c24b9500) at netbsd:nfs_request+0xa51
nfs_access(cfb7db74,ce4168ac,30002,20002,c05f4980) at netbsd:nfs_access+0x234
VOP_ACCESS(ce4168ac,1,c24b9500,cc272cd0,0) at netbsd:VOP_ACCESS+0x34
nfs_lookup(cfb7dd94,0,0,c07b3558,c05f4f80) at netbsd:nfs_lookup+0x159
layer_lookup(cfb7dd94,cc272cd0,cfb7ddac,c03bcf04,c05f4840) at netbsd:layer_lookup+0x57
VOP_LOOKUP(ce01592c,cfb7de84,cfb7de98,cfb7de84,cd793000) at netbsd:VOP_LOOKUP+0x2e
lookup(cfb7de74,cd793000,400,cfb7de8c,0) at netbsd:lookup+0x201
namei(cfb7de74,bfbfe810,60,f800d8da,80b5744) at netbsd:namei+0x138
sys___lstat13(cdcead6c,cfb7df64,cfb7df5c,118,0) at netbsd:sys___lstat13+0x58
syscall_plain() at netbsd:syscall_plain+0x17e
--- syscall (number 280) ---
0x8085263:
db{1}> reboot(0x104)

dumping to dev 0,1 offset 55768
dump panic: wdcstart: channel waiting for irq
Stopped in pid 5782.1 (pax) at  netbsd:cpu_Debugger+0x4:        leave

>How-To-Repeat:
	Leave a SMP system with NFS-mounted filesystems running while the
	NFS server is down ?
>Fix:
	unknown