--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.
If someone else wants to give it a try the core dump is available
at <http://outel.org/sleepingcore>
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
