Date: Tue, 20 Dec 2011 09:32:21 -0500 From: John Baldwin <jhb@freebsd.org> To: mdf@freebsd.org Cc: Robert Watson <rwatson@freebsd.org>, freebsd-current@freebsd.org, "O. Hartmann" <ohartman@zedat.fu-berlin.de> Subject: Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662 Message-ID: <201112200932.21223.jhb@freebsd.org> In-Reply-To: <CAMBSHm_ZcMe2uC6HXL9vazYOxVSVVKJqmfHCHXRta8rgdda65w@mail.gmail.com> References: <4EED2F1C.2060409@zedat.fu-berlin.de> <201112200852.23300.jhb@freebsd.org> <CAMBSHm_ZcMe2uC6HXL9vazYOxVSVVKJqmfHCHXRta8rgdda65w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, December 20, 2011 9:22:48 am mdf@freebsd.org wrote:
> On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin <jhb@freebsd.org> wrote:
> > On Saturday, December 17, 2011 10:41:15 pm mdf@freebsd.org wrote:
> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev <kabaev@gmail.com> wrote:
> >> > On Sun, 18 Dec 2011 01:09:00 +0100
> >> > "O. Hartmann" <ohartman@zedat.fu-berlin.de> wrote:
> >> >
> >> >> Sleeping thread (tid 100033, pid 16) owns a non sleepable lock
> >> >> panic: sleeping thread
> >> >> cpuid = 0
> >> >>
> >> >> PID 16 is always USB on my box.
> >> >
> >> > You really need to give us a backtrace when you quote panics. It is
> >> > impossible to make any sense of the above panic message without more
> >> > context.
> >>
> >> In the case of this panic, the stack of the thread which panics is
> >> useless; it's someone trying to propagate priority that discovered it.
> >> A backtrace on tid 100033 would be useful.
> >>
> >> With WITNESS enabled, it's possible to have this panic display the
> >> stack of the incorrectly sleeping thread at the time it acquired the
> >> lock, as well, but this code isn't in CURRENT or any release. I have
> >> a patch at $WORK I can dig up on Monday.
> >
> > Huh? The stock kernel dumps a stack trace of the offending thread if you have
> > DDB enabled:
> >
> > /*
> > * If the thread is asleep, then we are probably about
> > * to deadlock. To make debugging this easier, just
> > * panic and tell the user which thread misbehaved so
> > * they can hopefully get a stack trace from the truly
> > * misbehaving thread.
> > */
> > if (TD_IS_SLEEPING(td)) {
> > printf(
> > "Sleeping thread (tid %d, pid %d) owns a non-sleepable lock\n",
> > td->td_tid, td->td_proc->p_pid);
> > #ifdef DDB
> > db_trace_thread(td, -1);
> > #endif
> > panic("sleeping thread");
> > }
>
> Hmm, maybe this wasn't in 7, or maybe I'm just remembering that we
> added code to print *which* lock it holds (using WITNESS data). I do
> recall that this panic alone was often not sufficient to debug the
> problem.
I think the db_trace_thread() has been around for a while (since 5 or 6),
but it is true that we don't tell you which lock is held even with this.
That might be a useful thing to output before the panic.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112200932.21223.jhb>