I finally got my i386-current systems set up to investigate this further. One thing I hadn't thought about before is that normally, there is only one 'amd' process managing all the automount points.
In the case of the system with processes stuck in "tstile", something spawns a second 'amd' process and it is this second process that gets stuck. I suspect is is trying to service the same mount points that are already active and so gets stuck. Again, this seems only to happen when 'firefox' is running on the client and a 'cvs update' is being performed on the NFS server. It is most likely to happen while 'cvs' is processing files that differ between the repository and the local tree. I had 'top' running and in a prior situation managed to glimpse the second 'amd' in the process list, but it quickly disappeared again. The next time, the second 'amd' process appeared, it got stuck in "tstile" right away, along with a couple of 'firefox' LWPs similar to previous postings. I'll see about turning on DEBUG and LOCKDEBUG and running on a machine with swap on local disk to force a crash dump. -- |/"\ 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
