Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 06 Dec 2009 16:25:08 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        freebsd-current@FreeBSD.org
Cc:        Attilio Rao <attilio@FreeBSD.org>
Subject:   Re: process stuck in stat/../cache_lookup: ktorrent, zfs
Message-ID:  <4B1BBEC4.7040906@icyb.net.ua>
In-Reply-To: <4B1B9600.4080709@icyb.net.ua>
References:  <4B1B9600.4080709@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
on 06/12/2009 13:31 Andriy Gapon said the following:
> System is recent 9-current, amd64.
> I see that sometimes ktorrent gets stuck during heavy download (multiple files
> in parallel, high speed).  It is completely unresponsive and not killable even
> with SIGKILL.
[snip]
> #0  sched_switch (td=0xffffff012a6c5700, newtd=0xffffff0001533380,
> flags=Variable "flags" is not available.
> ) at /usr/src/sys/kern/sched_ule.c:1865
> #1  0xffffffff80374baf in mi_switch (flags=260, newtd=0x0) at
> /usr/src/sys/kern/kern_synch.c:449
> #2  0xffffffff803a795b in sleepq_switch (wchan=Variable "wchan" is not available.
> ) at /usr/src/sys/kern/subr_sleepqueue.c:509
> #3  0xffffffff803a8645 in sleepq_wait (wchan=0xffffff0105b457f8, pri=80) at
> /usr/src/sys/kern/subr_sleepqueue.c:588
> #4  0xffffffff80351184 in __lockmgr_args (lk=0xffffff0105b457f8, flags=2097408,
> ilk=0xffffff0105b45820, wmesg=Variable "wmesg" is not available.
> ) at /usr/src/sys/kern/kern_lock.c:216

So some more data:
(kgdb) fr 4

#4  0xffffffff80351184 in __lockmgr_args (lk=0xffffff0105b457f8, flags=2097408,
ilk=0xffffff0105b45820, wmesg=Variable "wmesg" is not available.
) at /usr/src/sys/kern/kern_lock.c:216
216                     sleepq_wait(&lk->lock_object, pri);
(kgdb) p *lk
$8 = {lock_object = {lo_name = 0xffffffff80ad55b6 "zfs", lo_flags = 91947008,
lo_data = 0, lo_witness = 0x0}, lk_lock = 3, lk_timo = 51, lk_pri = 80}
(kgdb) p/x flags
$9 = 0x200100
(kgdb) p/x lk->lock_object.lo_flags
$12 = 0x57b0000

Apparently sleeplk is inlined into __lockmgr_args.

So it looks like this is a LK_SHARED|LK_INTERLOCK lockmgr call which has not
taken any easy path and ended up in sleepq_wait, but wakeup never comes for it,
perhaps missed?

P.S. I have not enabled ADAPTIVE_LOCKMGRS in my kernel config and I believe that
it is not enabled by default, right?

-- 
Andriy Gapon



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B1BBEC4.7040906>