Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain"
From: Daniel Lang (dl_at_leo.org)
Date: 06/29/04
- Previous message: Don Bowman: "RE: kern/68442: panic - acquiring duplicate lock of same type: "s leepq chain""
- In reply to: Brian Fundakowski Feldman: "Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain""
- Next in thread: John Baldwin: "Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain""
- Reply: John Baldwin: "Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 29 Jun 2004 21:31:57 +0200 To: Brian Fundakowski Feldman <green@FreeBSD.org>
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. :-/
Don:
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.
John:
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
access.
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.
Thanks,
Daniel
-- IRCnet: Mr-Spock - Eddie would go! - Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/ _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
- Previous message: Don Bowman: "RE: kern/68442: panic - acquiring duplicate lock of same type: "s leepq chain""
- In reply to: Brian Fundakowski Feldman: "Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain""
- Next in thread: John Baldwin: "Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain""
- Reply: John Baldwin: "Re: kern/68442: panic - acquiring duplicate lock of same type: "sleepq chain""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]