Date: Sat, 25 Dec 2004 09:35:24 -0800 (PST) From: Mohan Srinivasan <mohan_srinivasan@yahoo.com> To: Kris Kennaway <kris@obsecurity.org>, mohans <mohans@yahoo-inc.com>, ps@FreeBSD.org, current@FreeBSD.org Subject: Re: Processes stuck in nfsreq Message-ID: <20041225173524.33634.qmail@web80606.mail.yahoo.com> In-Reply-To: <20041225070022.GA93123@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041225173524.33634.qmail>