Subject: nfsd: locking botch in op %d
To: None <>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 03/08/2001 06:40:16
The NFS server on my house LAN's NFS subnet fell over with "nfsd:
locking botch in op 3".  Investigating, I find this comes from
nfs_syscalls.c, where there's a recommendation to audit the relevant
entry in nfsrv3_procs[], which in this case is nfsrv_lookup.

It turns out to be repeatable, fortunately.  It happens when the
client (a next68k box) gets to "building databases...", and tcpdump on
a third machine on that subnet shows that it's in dev_mkdb and ends with

05:41:21.339645 > 108 lookup fh 7,18/271120 "stdout"
05:41:21.342198 > reply ok 236 lookup fh 7,18/272067
05:41:21.345240 > 108 lookup fh 7,18/271120 "stderr"
05:41:21.347929 > reply ok 236 lookup fh 7,18/272068
05:41:21.350790 > 104 lookup fh 7,18/271120 "sd0a"
05:41:21.395087 > 104 lookup fh 7,18/271120 "sd0a"
05:41:21.485220 > 104 lookup fh 7,18/271120 "sd0a"

( is the client and is the server, of course).  I
compared the obviously-relevant files against -current and didn't see
anything obvious.  I'll be investigating further; this is partly a
heads-up and partly a query to see if anyone happens to recall anything
relevant that might cut down the amount of bug-hunting I have to do.

					der Mouse

		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B