> I thought of writing a PR on it, but basically have no clue what to
> write in it. 

Deadlocks generally involve "process X holds lock A, wants lock B;
process Y holds lock B, wants lock A, plus N other processes which
want A or B or something held by other processes which are closer to
the deadlock cycle.  

If you suspect a locking/deadlock problem, information worth
collecting:

	- ps alx or DDB ps output showing a list of the processes.
	- DDB tracebacks of the kernel stacks of processes
	  which may be involved in the deadlock
	- a crash dump

Probably the best way to collect the first two bits is by capturing
serial console output, but the ten-finger copy method also works..

tracebacks can give a kernel developer an idea of (a) which lock each
process is waiting for, and (b) which locks each process likely holds,
hopefully making the deadlock obvious.

tracebacks of alternate processes (i.e., other than curproc) can be
collected on at least some platforms using the /t option to ddb's
trace command.  Because DDB's default input radix is hex, and pids are
usually in decimal, you'll need to use the 0t modifier if you don't
want to convert the pid to hex yourself, leading to a command which
looks like:

	db> t/t 0t42

to traceback a process with pid 42 (decimal).

					- Bill