kern/99094: panic: sleeping thread (Sleeping thread ... owns a non-sleepable lock)

[John Baldwin]

The following reply was made to PR kern/99094; it has been noted by GNATS.

From: John Baldwin <jhb at freebsd.org>
To: Eirik =?iso-8859-1?q?=D8verby?= <ltning at anduin.net>
Cc: bug-followup at freebsd.org
Subject: Re: kern/99094: panic: sleeping thread (Sleeping thread ... owns a non-sleepable lock)
Date: Fri, 30 Jun 2006 11:06:47 -0400

 On Friday 30 June 2006 10:56, Eirik =D8verby wrote:
 > Hm, I thought I had that in my report?
 
 =46rom the messages:
 
 Sleeping thread (tid 100082, pid 84236) owns a non-sleepable lock
 panic: sleeping thread
 cpuid =3D 0
 KDB: enter: panic
 [thread pid 84235 tid 100474 ]
 
 This means pid 84236 misbehaved, and pid 84235 found that it had misbehaved=
 =2E =20
 The sole stack trace is of pid 84235:
 
 db> bt
 Tracing pid 84235 tid 100474 td 0xffffff006f759000
             ^^^^^
 :)
 
 > I have to find a way to automate this. I've just moved the =20
 > installation to a newly partitioned array, to make sure I have room =20
 > for crash dumps, and I have the following in rc.conf:
 >=20
 > dumpdev=3D"AUTO"
 > dumpdir=3D"/usr/crash"
 >=20
 > from my reading, that should be enough.
 >=20
 > In addition I added KDB_UNATTENDED to the kernel config, as I cannot =20
 > risk that the box is down for hours before I have a chance to get to =20
 > the debugger console every time. The question is: Will it actually do =20
 > an automatic dump before rebooting, or will a dump *always* require =20
 > manual intervention? And will a dump contain all necessary information?
 
 You can get a stack trace from the dump using kgdb.  You'll have to use 'in=
 fo=20
 threads' in gdb to find the thread with the corresponding pid, then use the=
 =20
 gdb 'thread' command to switch to that thread (using the gdb thread number,=
 =20
 not the tid or pid) and then do a 'bt' or 'where' to get the trace.
 
 =2D-=20
 John Baldwin