Re: cvs update hangs 'amd' in tstile when 'firefox' is running

[christos%astron.com@localhost (Christos Zoulas)]

In article <20160212103705.7BA5D11536F%xen1.duzan.org@localhost>,
Gary Duzan <gary%duzan.org@localhost> wrote:
>In Message <Pine.NEB.4.64.1602112120290.1432%david.technoskunk.fur@localhost>,
>   "John D. Baker" <jdbaker%mylinuxisp.com@localhost>wrote:
>
>=>On Fri, 12 Feb 2016 03:08:04 +0000 (UTC), christos%astron.com@localhost (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