re: Current port status

with some help from rmind@ i've at least tracked down what is happening
if not why or what the fix is.  i got this lockdebug panic:

Mutex error: mutex_vector_enter: locking against myself

lock address : 0x00000000a01ea074 type     :               spin
initialized  : 0x00000000003c4bfc
shared holds :                  0 exclusive:                  0
shares wanted:                  0 exclusive:                  1
current cpu  :                  0 last held:                  0
current lwp  : 0x00000000a0007840 last held: 000000000000000000
last locked  : 0x00000000003c5128 unlocked*: 0x00000000003c52a4
owner field  : 000000000000000000 wait/spin:                0/1

panic: LOCKDEBUG
Stopped in pid 0.3 (system) at  netbsd:cpu_Debugger+0x10:       lwz     r0, 0x14(r1)
db> bt
0xa94a3940: at vpanic+0x21c
0xa94a3970: at panic+0x4c
0xa94a39b0: at lockdebug_abort1+0xdc
0xa94a39d0: at mutex_abort+0x50
0xa94a39e0: at mutex_enter+0x26c                          [5]
0xa94a3a20: at pool_get+0x7c                              [4]
0xa94a3a60: at pool_cache_get_slow+0x214
0xa94a3a90: at pool_cache_get_paddr+0x290
0xa94a3ae0: at m_get+0x3c
0xa94a3af0: at m_gethdr+0xc
0xa94a3b00: at vr_rxeof+0x3c8
0xa94a3b70: at vr_intr+0x314
0xa94a3bb0: at intr_deliver+0x7c
0xa94a3bf0: at pic_do_pending_int+0x12c
0xa94a3c30: at splx+0x38                                  [3]
0xa94a3c40: at lockdebug_unlocked+0x190                   [2]
0xa94a3c70: at mutex_exit+0x194                           [1]
0xa94a3c90: at pool_get+0x1f8
0xa94a3cd0: at pool_cache_get_slow+0x214
0xa94a3d00: at pool_cache_get_paddr+0x290
0xa94a3d50: at m_get+0x3c
0xa94a3d60: at m_copypacket+0x1fc
0xa94a3da0: at udp4_sendup+0x90
0xa94a3de0: at udp_input+0x3c8
0xa94a3e50: at ip_input+0x3bc
0xa94a3e90: at ipintr+0xdc
0xa94a3ed0: at softint_thread+0x144
0xa94a3f20: at cpu_lwp_bootstrap+0xc
0xa94a3fe4: at 0xfffffffc

and tracking it down we go this path for lockdebug kernels.  for from [1]
we call into [2] which is really kern_mutex.c:mutex_vector_exit() here
(that's true for all LOCKDEBUG kernels.)  inside [2], we run the entire
contents at splhigh(), and the end of [2] is we call [3], the splx() call
to return to the previous IPL.  at this point in [3] we check for other
interrupts at higher levels, and we end up having a PCI intr on the vr.
eventually this goes down to [4], which is operating on the same pool as
the mutex in [1] belongs to but hasn't actually been completely released
yet, and so in [5] we detect the already locked mutex and abort.


it isn't clear to me yet exactly what is wrong here but at least we've
begun to understand the steps..


.mrg.