In article <pine.neb.4.64.1602111506580.1...@david.technoskunk.fur>, John D. Baker <jdba...@mylinuxisp.com> wrote: >On Wed, 10 Feb 2016, John D. Baker wrote: > >> On Wed, 10 Feb 2016 18:43:38 +0000 (UTC), chris...@astron.com (Christos >> Zoulas) wrote: >> >> > Unfortunately looks like you'll have to reboot and redo the test to >> > answer this. >> >> To make it unambiguous, I'll definitely arrange to do this again. > >OK, on the same system, still up and no pending shutdown. The specific >scenario was that during 'cvs update' on the file server, I switched >desktop pages (fvwm2) to where my login to the file server was. When >I switched back to the page where 'firefox' had its window, it did not >repaint its window after a substantial interval (and will never again do >so while the system is up). > >There are fewer LWPs in "tstile" as I didn't attempt any other operations >as soon as it was apparent that 'firefox' (and thus 'amd') had hung. >I simply 'ssh'ed in as another user whose home directory is not managed >by 'amd' and initiated 'crash'.
So amd tries to unmount, it is has taken the syncer_mutex and mp->mnt_unmounting mutex. now it walks the vnode list trying to vrecycle() all the vnodes, finds a busy one and blocks waiting to become available. The syncher (ioflush) task tries to take the syncer_mutex and blocks. Firefox tries to open a file on the nfs filesystem that is being unmounted and blocks waiting on mp->mnt_unmounting in vfs_busy(). So the problem is when nfs unmounts. You should be able to reproduce it mount foo:/foo /foo cd /foo umount /foo Or you might need to open a file for writing and keep it open.... And now umount is stuck and never returns EBUSY. Is that true? I don't think that firefox or the syncher and involved in the lossage but seem to be victims of it. I am not an FS locking expert though, Hannken!!! Help :-) christos