understanding LOCKDEBUG

[David Young <dyoung%pobox.com@localhost>]

I am revamping alldevs synchronization.  Somehow I have introduced a bug
that makes the kernel panic like this:

panic: cpu_switchto: switching above IPL_SCHED (8)

The problem seems to be my choice of IPL when I initialize alldevs_mtx.
IPL_VM is not appropriate for my purposes, but if I use it, anyway,

        mutex_init(&alldevs_mtx, MUTEX_DEFAULT, IPL_VM);

the panic does NOT occur.

If I choose IPL_HIGH, I see the panic.  I understand that the system
will freeze or panic if I sleep while holding alldevs_mtx, however, I
cannot find code in my heavily-patched kernel sources that sleeps while
holding alldevs_mtx.

Furthermore, I am confused by the lock data shown by the ddb command
'show lock alldevs_mtx':

db{1}> show lock alldevs_mtx     
lock address : 0x00000000c0a9972c type     :               spin
initialized  : 0x00000000c05c6fa5
shared holds :                  0 exclusive:                  0
shares wanted:                  0 exclusive:                  0
current cpu  :                  1 last held:                  1
current lwp  : 0x00000000d0b8cd40 last held: 000000000000000000
last locked  : 0x00000000c05c5878 unlocked : 0x00000000c05c5893
owner field  : 0x0000000000000800 wait/spin:                0/1

Does some LWP hold the lock or not?  How do I know?

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933