Subject: Re: panic: lockmgr: locking against myself
To: Paul H. Anderson <firstname.lastname@example.org>
From: Bill Sommerfeld <email@example.com>
Date: 03/18/1999 16:04:31
> 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
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