Re: Processes stuck in nfsreq

Hi,

If the box is still in that state, can you force a core ?

The trace below shows the process blocked on nfs_request()->msleep.
If the process shows up as waiting on "nfsreq", it would be msleep'ing
from nfs_reply(), not from nfs_request(). There's only one msleep()
call in nfs_request() (nfs_socket.c:1125), but that is for "nqnfstry".
The msleep("nfsreq") only happens from nfs_reply() (unless nfs_reply() 
has gotten inlined).

mohan

--- Kris Kennaway <kris_at_obsecurity.org> wrote:

> Since updating pointyhat to tonight's 6.0 sources (previously from
> about a month ago), I'm having processes locking up in state nfsreq.
> I confirmed that directio was disabled.
> 
> This is a cvs update from repoman (mounted via NFS with the following
> options:
> 
> repoman:/r              /repoman/r      nfs     ro,bg,intr,soft,nodev,nosuid 0 00
> 
> db> tr 22402
> Tracing pid 22402 tid 100161 td 0xc3a99170
> sched_switch(c3a99170,0,1,120,b08c87ee) at sched_switch+0x115
> mi_switch(1,0,c06e61e4,1ab,1) at mi_switch+0x1d3
> sleepq_switch(1,c06e2b19,18e,1,1) at sleepq_switch+0x10d
> sleepq_wait_sig(c7acb980,0,c06e3e0f,dc,0) at sleepq_wait_sig+0xf
> msleep(c7acb980,c076f520,153,c06f1e45,0) at msleep+0x21e
> nfs_request(c39c1cf0,c4355c00,3,c3a99170,c3c0b300) at nfs_request+0x762
> nfs_lookup(ee15fb84,c3a99170,c3a99170,c3a99170,ee15fc38) at nfs_lookup+0x2f8
> lookup(ee15fc24,c35bb400,0,a7,8) at lookup+0x274
> namei(ee15fc24,108,c06e3d30,8,c073b9c8) at namei+0x27d
> stat(c3a99170,ee15fd14,c06fecb7,3ad,2) at stat+0x4f
> syscall(2f,80c002f,bfbf002f,80ce0e0,283aaf60) at syscall+0x137
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (188, FreeBSD ELF32, stat), eip = 0x28316b1f, esp = 0xbfbfeb8c, ebp = 0xbfbfec08 ---
> 
> db> show lockedvnods
> Locked vnodes
> 0xc5ccd9b4: tag ufs, type VDIR
>     usecount 6, writecount 0, refcount 9 mountedhere 0
>     flags (VV_OBJBUF)
>      lock type ufs: EXCL (count 1) by thread 0xc3cdc170 (pid 5840)
>         ino 14110529, on dev twed0s1f (232, 7)
> 0xc5512114: tag ufs, type VREG
>     usecount 1, writecount 0, refcount 240 mountedhere 0
>     flags (VV_OBJBUF)
>      lock type ufs: EXCL (count 1) by thread 0xc9bc85c0 (pid 4717)
>         ino 35135903, on dev twed0s1f (232, 7)
> 0xc6ebb9b4: tag ufs, type VREG
>     usecount 1, writecount 0, refcount 1 mountedhere 0
>     flags (VV_OBJBUF)
>      lock type ufs: EXCL (count 1) by thread 0xc9bc8cf0 (pid 4700)
>         ino 16275165, on dev twed0s1f (232, 7)
> 0xc79f8564: tag ufs, type VREG
>     usecount 1, writecount 0, refcount 1 mountedhere 0
>     flags (VV_OBJBUF)
>      lock type ufs: EXCL (count 1) by thread 0xc3c78170 (pid 5835)
>         ino 17405819, on dev twed0s1f (232, 7)
> 0xc5d3a8a0: tag ufs, type VNON
>     usecount 1, writecount 0, refcount 0 mountedhere 0
> 
>      lock type ufs: EXCL (count 1) by thread 0xc3cdc170 (pid 5840)
>         ino 14146443, on dev twed0s1f (232, 7)
> 0xc39c1cf0: tag nfs, type VDIR
>     usecount 3, writecount 0, refcount 1 mountedhere 0
>     flags (VV_ROOT)
>      lock type nfs: EXCL (count 1) by thread 0xc3a99170 (pid 22402) with 1 pending
>         fileid 2 fsid 0x100ff01
> 
> After the first cvs update froze, I started a tcpdump to see if any
> traffic was being sent to repoman, but it did not show anything.
> 
> Kris
> 

> ATTACHMENT part 2 application/pgp-signature