:As for non-zero exclusive count panic, it's odd because although
:lockmgr() triggered the non-zero exclusive count panic, kgdb shows
:that lkp->lk_exclusivecount == 0 (shown below). Usually the panic is
:...
Hmm. The inconsistency is probalby due to the secondary panics.
Run 'dmesg -M vmcore.21 -N kern.21', two panics occured at the same
time and their kprintf output got mixed in together. Once a panic
occurs numerous subsystems will allow locks through whether they can
acquire them or not.
Now on the non-zero exclusive count issue. I don't see any mismatched
lock/unlock operations but I suspect it may be the TDF_DEADLKTREAT
code allowing an exclusive lock to worm its way inbetween an
EXCLUPGRADE request (because it doesn't block on LK_WANT_UPGRADE in
that TDF_DEADLKTREAT case).
The way to test this is to comment out the setting of TDF_DEADLKTREAT
in kern/kern_subr.c. There's just one place where it happens.
If that turns out to fix the problem then I think we may be forced
to get rid of the shared->exclusive upgrade code entirely or restrict
it to less sophisticated cases. The whole shared->exclusive priority
mechanism in lockmgr has had deadlock issues for a long time.
-Matt