OK, this is the svn process (directly running on the file server, not operating via NFS) tstile-ing:
crash> ps | grep "\(vnode\|tstile\)" 25051 1 3 0 0 fffffe82ec17d200 svn tstile crash> t/a fffffe82ec17d200 trace: pid 25051 lid 1 at 0xfffffe811e901700 sleepq_block() at sleepq_block+0xad turnstile_block() at turnstile_block+0x2bb rw_vector_enter() at rw_vector_enter+0x1eb wapbl_begin() at wapbl_begin+0x54 ffs_valloc() at ffs_valloc+0x5e ufs_makeinode() at ufs_makeinode+0x62 ufs_create() at ufs_create+0x5c VOP_CREATE() at VOP_CREATE+0x38 vn_open() at vn_open+0x2ed do_open() at do_open+0xcd sys_open() at sys_open+0x59 syscall() at syscall+0xc4 crash> ps | grep "\(vnode\|tstile\)" 25051 1 3 0 0 fffffe82ec17d200 svn tstile And this is both the local svn and one nfsd slave tstile-ing: crash> ps | grep "\(vnode\|tstile\)" 10532 1 3 0 0 fffffe82eca5d5c0 svn tstile 442 4 3 5 0 fffffe841628c060 slave tstile crash> t/a fffffe841628c060 trace: pid 442 lid 4 at 0xfffffe811dbfe4e0 sleepq_block() at sleepq_block+0xad turnstile_block() at turnstile_block+0x2bb rw_vector_enter() at rw_vector_enter+0x1eb genfs_lock() at genfs_lock+0x7b VOP_LOCK() at VOP_LOCK+0x32 vn_lock() at vn_lock+0x7d vget() at vget+0xa2 ufs_ihashget() at ufs_ihashget+0x84 ffs_vget() at ffs_vget+0xc1 ufs_fhtovp() at ufs_fhtovp+0x1f ffs_fhtovp() at ffs_fhtovp+0x55 VFS_FHTOVP() at VFS_FHTOVP+0x1c nfsrv_fhtovp() at nfsrv_fhtovp+0x9a nfsrv_getattr() at nfsrv_getattr+0x13a nfssvc_nfsd() at nfssvc_nfsd+0x1d7 sys_nfssvc() at sys_nfssvc+0x22c syscall() at syscall+0xc4 crash> ps | grep "\(vnode\|tstile\)" 442 4 3 5 0 fffffe841628c060 slave tstile These are somewhat difficult to catch in the act since you have to copy-paste the address from the ps output into the t command. Now, does that help to diagnose the problem?
