Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662

On Tuesday, December 20, 2011 9:22:48 am mdf_at_freebsd.org wrote:
> On Tue, Dec 20, 2011 at 5:52 AM, John Baldwin <jhb_at_freebsd.org> wrote:
> > On Saturday, December 17, 2011 10:41:15 pm mdf_at_freebsd.org wrote:
> >> On Sat, Dec 17, 2011 at 5:45 PM, Alexander Kabaev <kabaev_at_gmail.com> wrote:
> >> > On Sun, 18 Dec 2011 01:09:00 +0100
> >> > "O. Hartmann" <ohartman_at_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