Date: Tue, 02 Feb 2010 17:50:50 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Stephane LAPIE <stephane.lapie@darkbsd.org> Cc: freebsd-fs@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: [zfs][hardware] Reproducible kernel panic in 8.0-STABLE Message-ID: <4B6849DA.5080303@icyb.net.ua> In-Reply-To: <4B6830CF.9070102@darkbsd.org> References: <4B682972.6030604@darkbsd.org> <4B682F29.90505@icyb.net.ua> <4B6830CF.9070102@darkbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 02/02/2010 16:03 Stephane LAPIE said the following: > Andriy Gapon wrote: >> on 02/02/2010 15:32 Stephane LAPIE said the following: >>> I have a case of kernel panic that can be consistently reproduced, and >>> which I guess is related to the hardware I'm using (Marvell controllers, >>> check my pciconf -lv output below). >>> >>> The kernel panic message is always, consistently, the following : >>> >>> Sleeping thread (tid 100021, pid 0) owns a non-sleepable lock >> >> I probably won't be able to help you, but to kickstart debugging could >> you please >> run 'procstat -t 0' and determine what kernel thread has tid 100021 on >> your system? > > Thanks for the tip. I will keep that one in mind, as I was wondering how > you looked up individual threads. > > # procstat -t 0 | grep 100021 > 0 100021 kernel thread taskq 1 92 sleep - > > Is that the "kernel task queue" handler ? This taskqueue "taskqueue_thread" which is used to schedule tasks in many places. I would guess that one of those tasks leaked a lock. Probably it's best to configure system for crashdumps to a reliable storage and then try to examine a dump with kgdb to see what lock we have here. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B6849DA.5080303>