Subject: Re: lockdebug woes when doing big tcp bulk transfers
To: Sean Doran <>
From: Bill Sommerfeld <>
List: tech-smp
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
error messages..

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..

					- Bill