: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