kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain"

Daniel Lang dl at
Tue Jun 29 12:31:59 PDT 2004

Hi again,

I installed gdb6 from ports, which works.
It just confirms the addr2line result:

(kgdb) l *0xc053932b
0xc053932b is in witness_checkorder (/usr/src/sys/kern/subr_witness.c:898).

Brian Fundakowski Feldman wrote on Tue, Jun 29, 2004 at 02:49:46PM -0400:
> > (What hurts most, is, that in one occasion I had a ddb prompt
> > and could call doadump() successfully. But after reboot, damn 
> > /var was full, so savecore could not write it to disk, argl!).
> You can make /var/crash a symlink to a directory with more space.

Yes, I usually have enough space there. It was an ill coincidence. :-/

Thanks for the hint to run savecore later on. I should have guessed
as long as there is not much going on and swap did not need to used
yet, I would have gotten a good core. Unfortunately it is to late
for now. I'll keep it in mind, though.

Ok, mutex/witness confusion is maybe going on. How would you suggest
to proceed. I am a little reluctant to boot the machine to multi-user
and wait for the next crash (which most of the time does not
produce a dump or ddb prompt), since I would have to hit the
reset button and right now, I'm at home now and have only remote

How about the first stack trace (from ddb) that was included in
the PR. Although the crashdump was wasted, the ddb trace could give
some additional hints maybe?

It also shows witness_checkorder(), but it also shows
the other stack frames and as it seems the passed values.

I can do some examination with these info on the system
with gdb, but I could use a hint for what to look out for.

IRCnet: Mr-Spock                                    - Eddie would go! -
 Daniel Lang * dl at * +49 89 289 18532 *

More information about the freebsd-current mailing list