> Ross Harvey on the alpha mail list suggested I forward my problem to this
> list, regarding a filesystem stress test related panic.
> 
> I've got what seemed to be a stable system from at least a device driver
> perspective, but several times now, I've gotten the panic as follows:
> 
> panic: lockmgr: locking against myself

Ok, what this means is that the current process is holding a lock, and
somehow or other ends up reentering some code such that it wants to
reacquire the same lock.

There are a couple ways this could happen:

	a) there may be a path through some routine which fails to
release a lock it should have.

	b) there may be some overly complicated recursion which is
causing this.  (I recently fixed a unionfs-related deadlock like
this).

Without knowing what particular subsystem is causing this, it's hard
to say what it could be.

> How can I help debug this?

1) Get a full traceback, either from a crash dump or a kernel
debugger.  i'm not sure what the alpha has for this, but having
something which lets you look at source line numbres and source-level
variables is very helpful. gdb on a crash dump probably beats ddb for
this particular case; remote gdb on a live kernel is better than both.
(recompiling -g may help here..)

Further analysis would then involve:

2) examineing the inner part of the stack to see what lock you're
trying to get.

3) looking further up the stack to see whether case (a) or case
(b) applies.....

						- Bill