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 10.0.1.4.1981506118 > 10.0.1.2.2049: 108 lookup fh 7,18/271120 "stdout"
05:41:21.342198 10.0.1.2.2049 > 10.0.1.4.1981506118: reply ok 236 lookup fh 7,18/272067
05:41:21.345240 10.0.1.4.1981506119 > 10.0.1.2.2049: 108 lookup fh 7,18/271120 "stderr"
05:41:21.347929 10.0.1.2.2049 > 10.0.1.4.1981506119: reply ok 236 lookup fh 7,18/272068
05:41:21.350790 10.0.1.4.1981506120 > 10.0.1.2.2049: 104 lookup fh 7,18/271120 "sd0a"
05:41:21.395087 10.0.1.4.1981506120 > 10.0.1.2.2049: 104 lookup fh 7,18/271120 "sd0a"
05:41:21.485220 10.0.1.4.1981506120 > 10.0.1.2.2049: 104 lookup fh 7,18/271120 "sd0a"

(10.0.1.4 is the client and 10.0.1.2 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

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B