Re: NFS server panic on OpenBSD diskless client shutdown

["John D. Baker" <jdbaker%mylinuxisp.com@localhost>]

On Thu, 2 Aug 2012, John D. Baker wrote:

> I have tried no other ports for the server.  I have not tried "simple"
> OpenBSD clients (boot/run from own disk, but simply mount remote
> filesystems either explicitly or via amd).  I have tried no other
> OpenBSD client platforms neither simple nor diskless.

More data:

NFS server:
  NetBSD-6.0BETA2/i386

NFS diskless client:
  OpenBSD-5.2/loongson (snapshot from 30 July 2012)


Server console info:

$ uname -a
NetBSD fred.technoskunk.fur 6.0_BETA2 NetBSD 6.0_BETA2 (FRED) #4: Tue Jul 31 
20:48:10 CDT 2012  
sysop%fred.technoskunk.fur@localhost:/d0/build/netbsd-6/obj/i386/sys/arch/i386/compile/FRED
 i386


"Normal" NFS mounts or 'amd'-initiated automounts from the client posed
no problem for the server, even if the client rebooted with the remote
filesystems still mounted.

When operated with netboot/NFS-root, shutting down the client panics
the server.  This server had ddb.onpanic=0 so it saved a core dump and
rebooted.  Running 'crash' over the core file reveals the following:

Crash version 6.0_BETA2, image version 6.0_BETA2.
System panicked: trap
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NAGR(c06aecb0,104,c0374d68,8,5,0,0,da64e584,0,0) at 0
saved_usb_vendor.4822(104,0,fff9,c066526a,c04bdfb0,0,1000000,0,da64e694,6) at da
64e5e4
vpanic(c06aecb0,da64e5e4,da64e5d8,0,da64e694,6,da64e688,c051c347,c06aecb0,da64e6
94) at vpanic+0x1c6
printf_nolog(c06aecb0,da64e694,da64e694,c05c1f0c,8,10286,4c,0,c030c53c,c1a7591a)
 at printf_nolog
trap() at trap+0xc92
--- trap (number 6) ---
VOP_ABORTOP(0,da64ea08,c1e99b00,d,0,da64ea24,da64eb68,da64ea34,da64ea3c,0) at VO
P_ABORTOP+0x1a
nfsrv_rename(c5357cf8,c1e99b00,c2246800,da64eb68,0,0,0,da64ec30,0,1) at nfsrv_re
name+0x749
nfssvc_nfsd(da64ebf0,bb3ffb28,c2246800,0,0,0,da64ebbc,c05d6afc,0,c1a1eb40) at nf
ssvc_nfsd+0x196
sys_nfssvc(c2246800,da64ecf4,da64ed1c,0,c2651200,bbbeb340,bbb2b5c2,ffffffff,3cf6
0000,ffffffff) at sys_nfssvc+0x23b
syscall(da64ed48,80400b3,bb2000ab,bfbf001f,bbbb001f,bb3ffba8,bb200000,bb3ffbb4,b
b3ffb28,bb200010) at syscall+0xb0


In my previous trials, I'd always powered off the stuck client first
before dealing with the crashed server.  This time, the client was
still in the throes of trying to shut down when the server came back up.
The server promptly crashed again, saving a new core dump.  Running this
one through 'crash' produced the same results as above.

As a sanity check, forcibly powering-off the client while it is otherwise
operating normally appears not to induce a panic on the server.

So far, I have only seen this problem with OpenBSD clients that operate
disklessly from a NetBSD NFS server.  The vast majority of other diskless
clients I experiment with are running NetBSD as well and they don't cause
the server any harm (just that the majority of them fail to reboot or
shutdown on their own).

I may have tested the converse case (OpenBSD server, NetBSD client),
but it was a while ago and I wasn't in a position to make notes about
it.  Perhaps I can arrange that soon.

--
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645