--On Wednesday, November 20, 2002 2:27 PM -0500 John Baldwin <[EMAIL PROTECTED]> wrote:
On 20-Nov-2002 Joel M. Baldwin wrote:--On Wednesday, November 20, 2002 12:01 PM -0500 Robert Watson <[EMAIL PROTECTED]> wrote:On Wed, 20 Nov 2002, Robert Watson wrote:Hmm. Another thread has decided to sleep while holding an inpcb mutex. Any chance this can be reproduced while running WITNESS? If so, you should get a panic earlier when the other thread sleeps in the first place. The easiest way to do that is if you can reproduce the panic with WITNESS. If you can't reproduce the panic, you may be able to extract this from your system core using gdb -- you want to figure out what the thread owner of the mutex is doing -- in the context of the kassert() below, td is the pointer to the thread that owns the mutex. I'm not sure how to extract a stack trace from that information, unfortunately, perhaps someone can give us pointers. (note: td from the priority_propagate() argument is shadowed, which is annoying).Ack. I mis-read. You want the stack from thread td1 (the mutex owner), not thread td.The kernel that produced the core dump ALREADY HAS WITNESS and WITNESS_SKIPSPIN! :( I'll try to get more info from kgdb, but I doubt that I'll have much luck since I've never tried using gdb before.Erm. Did you manage to look at dmesg then? If so, you would have seen warnings from WITNESS earlier about the locks messing up. If
I see NOTHING in the dmesg about locks.
you can reproduce this and are letting it sit unattended, a better plan might be to turn on witness_ddb (it's a kernel option, loader tunable, and sysctl (debug.witness_ddb)) and then when the original error occurs it will drop into the debugger with a very useful error message. You can also get a useful trace at that point from ddb.
I have debug.witness_ddb=1 and will try to panic the system. I'll let you know what happens.
-- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
