On Dec 05 14:23:08, Michael Durket wrote: > > Hm. Can you make a ktrace(1) of that 'umount -f'? > > 6267 ktrace RET ktrace 0 > 6267 ktrace CALL execve(0x7f7ffffd5d0f,0x7f7ffffd5858,0x7f7ffffd5878) > 6267 ktrace NAMI "/sbin/umount" > 6267 umount EMUL "native" > 6267 umount RET execve 0 > 6267 umount CALL __sysctl(1.37,0x625180,0x7f7ffffd22c0,0,0) > 6267 umount RET __sysctl 0 > 6267 umount CALL __sysctl(6.7,0x82d318,0x7f7ffffd22c0,0,0) > 6267 umount RET __sysctl 0 > 6267 umount CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0) > 6267 umount RET mmap 1117556736/0x429c9000 > 6267 umount CALL mprotect(0x429c9000,0x1000,0x1) > 6267 umount RET mprotect 0 > 6267 umount CALL sync() > 6267 umount RET sync 0 > 6267 umount CALL lstat(0x7f7ffffd1e90,0x7f7ffffd10d0) > 6267 umount NAMI "/jacksprat-03" > 6267 umount PSIG SIGINT SIG_DFL code 0 > > > At this point, after several minutes I just cancelled the command with a ^C > because it wasn't doing anything. According to top, the process was in > 'nfsrcv' (under the WAIT column).
Am I right at thinking that "/jacksprat-03" is the mount point? If so, it looks like the umount process got stuck at the pathname lookup. > >> I think the problem sounds more like what an earlier responder suggested - > >> that this was a problem at some point with TCP NFS in OpenBSD that has > >> since > >> been fixed, The above makes me nelieve that it is indeed a problem in the NFS TCP code of OpenBSD; that is, 4.1 :-)
