Re: workqueues ....

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Phil Nelson <phil%NetBSD.org@localhost> 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