Subject: kern/35542: NFS rename(?) panics (panic: lockmgr: release of unlocked lock!)
To: None <email@example.com, firstname.lastname@example.org,>
From: None <email@example.com>
Date: 02/02/2007 08:05:00
>Synopsis: NFS rename(?) panics (panic: lockmgr: release of unlocked lock!)
>Arrival-Date: Fri Feb 02 08:05:00 +0000 2007
>Originator: Arto Selonen
>Release: NetBSD-current 4.99.9 ~20070201
NetBSD blah 4.99.9 NetBSD 4.99.9 (BLAH) #4: Thu Feb 1 16:13:51 EET 2007 blah@blah:/obj/sys/arch/i386/compile/BLAH i386
The system is a NFS server serving 2 1TB partitions from a twelve disk RAID array (3ware Escalade).
The system was upgraded on January 25th (previous upgrade was on November 28th), and ran without problems for roughly a week. Then on February 1st, it paniced ("panic: lockmgr: release of unlocked lock!"). Repeated reboots resulted in similar panics pretty much as soon as network interface went up. Booting to single user and turning NFS services off made system stable (and NFS disks inaccessible).
The system was then upgraded on February 1st with whatever sources anoncvs gave, and then NFS services were turned back on. After a reboot, once network interface came up, it paniced again.
At the moment, I don't have any network traces for possible client traffic, but I have a "db> reboot 0x104" crash dump of the latest panic, and the following function call trace (just to give an idea of what is going on):
panic: lockmgr: release of unlocked lock!
Stopped in pid 542.1 (nfsd) at netbsd:cpu_Debugger
Purely guessing from the trace and recent source changes, with simple string matching, I'm guessing this might have something to do with eg. these (of course I could be way off here, as I have no idea of the functional relevance, this is purely from browsing commit messages from December-January for "relevant" strings):
I have the following crash dump available:
-rw------- 1 root wheel 10021802 Feb 2 09:13 netbsd.2.core.gz
-rw------- 1 root wheel 1732192 Feb 2 09:13 netbsd.2.gz
Due to privacy issues, I can not provide those files, but I'm willing to follow instructions on how to access them, if needed.
Kernel config has not been touched in over a year:
options PCKBD_LAYOUT="(KB_SV | KB_NODEAD)"
pseudo-device md 1
pseudo-device vnd 4
pseudo-device bpfilter 8
pseudo-device ppp 8
pseudo-device tun 2
pseudo-device gif 4
I can provide dmesg output if needed.
Anything else I could provide or test to help get this problem fixed?
At the moment, this is very repeatable, as the system goes down as soon as I get it up. No idea of the cause, so don't know if this remains (assuming there is a NFS client sending bad data, that decides to stop sending bad data).
Turn off NFS services to keep the system up. No known fix for keeping NFS services going, though.