In article <20160212103705.7ba5d115...@xen1.duzan.org>, Gary Duzan <g...@duzan.org> wrote: >In Message <pine.neb.4.64.1602112120290.1...@david.technoskunk.fur>, > "John D. Baker" <jdba...@mylinuxisp.com>wrote: > >=>On Fri, 12 Feb 2016 03:08:04 +0000 (UTC), chris...@astron.com (Christos >=>Zoulas) wrote: >=> >=>> Ok, do a cvs update (which is what triggers it), wait a bit and then >=>> do the unmount. >=> >=>I'm not quite sure about to what you refer. On a non-stuck client, >=>during 'cvs update' on the NFS server or even arbitrarily long afterward, >=>one can umount/mount an NFS filesystem at will. If the mount point is >=>the PWD or otherwise in use, the umount attempt returns "Device busy". >=> >=>Even on a quiescent 'amd'-managed NFS mount, access to files on that >=>mount during or slightly after a 'cvs update' on the file server will >=>succeed, albeit with some disconcerting delay--as long as 'firefox' >=>isn't running. >=> >=>Pondering other scenarios that could trigger the behavior. Something >=>with a file open on the 'amd'-managed mount during 'cvs update' on the >=>server? The directory is already open as PWD in the shell. Something >=>that writes to a file? I have another client on which I was editing an >=>email during 'cvs update' and it survived (albeit with the aforementioned >=>delay). > > Just a random thought: maybe mmap a file on the mount? If just >the mmap doesn't do it, dirty at least one page and see if that >does.
Is your kernel DEBUG/DIAGNOSTIC/LOCKDEBUG? Do you have a netbsd.gdb for it? Can you get a crash dump when it is stuck? christos
