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

Alternating "locking against myself" and "lock not held" means
that a process is attempting to recursively acquire a lock it already
holds.
	simple_lock(&foo);
	simple_lock(&foo);
	simple_unlock(&foo);
	simple_unlock(&foo);

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