Subject: Re: lockdebug woes when doing big tcp bulk transfers
To: Sean Doran <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 01/15/2001 23:01:59
> this is repeatable. fortunately DDB allows one to type
> <RET>cont<RET>cont<RET> and keep going, every time.
> i guess since LOCKDEBUG isn't on by default, this is ignorable?
No. Everything found by LOCKDEBUG indicate real problems; a
MULTIPROCESSOR kernel without LOCKDEBUG will deadlock when it hits a
"locking againt myself" error.
Anyhow, there are a couple easily recognized patterns in LOCKDEBUG
Repeated "locking against myself" generally means someone forgot an
Alternating "locking against myself" and "lock not held" means
that a process is attempting to recursively acquire a lock it already
In all of these cases it would be very useful to get a traceback in
ddb before continuing from each of the lock sites; I'm not sure I see
how the particular sequence you cited can happen; seeing how it "got
there from here" would be very helpful..