Re: NFS oddities with MacOX X clients

["Arnaud Lacombe" <lacombar%gmail.com@localhost>]

On Wed, Nov 19, 2008 at 6:04 PM, Arnaud Lacombe <lacombar%gmail.com@localhost> 
wrote:
>  - rm on the server a file being transfered
I confirm I'm still able to 100% reproduce this one on 5.99.3:

% gdb ../netbsd.gdb
(gdb) target kvm netbsd.core
#7  0xc010cd56 in calltrap ()
#8  0xc07174b9 in ufs_fhtovp (mp=0xcb6f1660, ufhp=0xcbd75958, vpp=0xcbd75b40)
#9  0xc02ab905 in ffs_fhtovp (mp=0xcb6f1660, fhp=0xcbd75ae0, vpp=0xcbd75b40)
#10 0xc078e7fc in VFS_FHTOVP (mp=0xcb6f1660, a=0xcbd75ae0, b=0xcbd75b40)
#11 0xc056b828 in nfsrv_fhtovp (nsfh=0xcbd75ad4, lockflag=1,
vpp=0xcbd75b40, cred=0xcb9b2180, slp=0xcaedf208, nam=0xc1485100,
rdonlyp=0xcbd75b4c, kerbflag=0, pubflag=0)
#12 0xc056594d in nfsrv_read (nfsd=0xcbda3e10, slp=0xcaedf208,
lwp=0xcbcfaa20, mrq=0xcbd75bd0)
#13 0xc0570516 in nfssvc_nfsd (nsd=0xcbd75c38, argp=0xbadff828, l=0xcbcfaa20)
#14 0xc05711f2 in sys_nfssvc (l=0xcbcfaa20, uap=0xcbd75d00, retval=0xcbd75d28)
#15 0xc06b0178 in syscall (frame=0xcbd75d48) at
/data/netbsd/syssrc/sys/sys/syscallvar.h:61
#16 0xc010057d in syscall1 ()
(gdb) frame 8
#8  0xc07174b9 in ufs_fhtovp (mp=0xcb6f1660, ufhp=0xcbd75958, vpp=0xcbd75b40)
191             ip = VTOI(nvp);
(gdb) print ((struct vnode *)0xcbcf7680)->v_data
$3 = (void *) 0x0

ttaaaddaaaaaa !!

As I already encountered this crash in 4.99.72, 5_0BETA is likely to
be affected too.

>  - write from the client to the server
>
this one is more tricky, it does not seem to crash the server, but a simple:
$ dd if=/dev/zero of=/remote/fs/test
is enough to stuck dd(1) in the D+ state, other NFS mount from the
same server works fine.

I guess the only solution will be to reboot the client ...

 - Arnaud