Phil Nelson <[email protected]> wrote: > I'm getting a mutex error here in that the lock is held. > Backtrace: > System panicked: LOCKDEBUG: Mutex error: mutex_vector_enter,528: spin > lock held Backtrace from time of crash is available. > crash> bt > _KERNEL_OPT_NARCNET() at 0 > _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI > vpanic() at vpanic+0x17d > snprintf() at snprintf > lockdebug_more() at lockdebug_more > mutex_enter() at mutex_enter+0x6b6 > urtwn_get_tx_data() at urtwn_get_tx_data+0x22 > urtwn_raw_xmit() at urtwn_raw_xmit+0x3e > ieee80211_raw_output() at ieee80211_raw_output+0x68 > ieee80211_send_probereq() at ieee80211_send_probereq+0x326 > scan_curchan() at scan_curchan+0x3c > scan_start() at scan_start+0x2b0 > workqueue_worker() at workqueue_worker+0xe9 >
This is an indication that you are trying to acquire an adaptive lock while holding a spin-lock. Adaptive mutex (using IPL_NONE) blocks and, by design, you cannot block while holding a spin-mutex (> IPL_NONE). If you will inspect the callers of urtwn_get_tx_data(), I guess you will find something holding a spin-mutex at a higher level. > I'm assuming that the softintr and the workqueue don't look like > the same owner. So I'm stuck wondering what is happening here. > > Even though I don't see the scan_start called twice, I do need > to protect against that. I'll see if that fixes the problem. I think you might be confused, given your original question. The workqueue mechanism runs your functions in separate threads. Your locks are acquired in different contexts, so you adaptive mutex(9) will synchronise between threads as normal. Note that _software_ interrupts also have a thread context, although it is limited and constrained. Without going to the details, in terms of mutex(9), you can think of softintr handlers as other threads. -- Mindaugas
