--- On Tue, 8/12/09, Herton Ronaldo Krzesinski <herton@xxxxxxxxxxxxxxx> wrote:
> The problem here is not simple: we have leds code
> triggering work and mac80211
> scheduling led tx work even after radio led stop on device
> shutdown:
> - On unregistering led device, even after mac80211 did the
> work to turn off the
> led, the unregister code of led subsystem calls again
> led_brightness_set to
> turn off the led, which causes the original warning without
> suspend/resume
> hooks (also in leds_exit code we were scheduling work which
> triggered more
> warnings).
> - When I was testing, sometimes mac80211 on device shutdown
> (modprobe -r)
> wasn't calling led stop code in the right order, so
> sometimes after removing
> module the led was kept turned on (scheduling led tx code
> after led radio off).
> This happens because ieee80211_tx_status can call
> ieee80211_led_tx after
> mac80211 calls ieee80211_led_radio to turn the led off, and
> as we are
> "emulating" a radio led (we have only one real led to
> signal radio and tx/rx,
> no differentiation on hardware) we are affected by this.
>
> So besides registering the radio led, I had to add that
> radio_on variable
> check on last patch, to handle these two problems. The
> patch worked, but Larry
> reported a crash, I'll try to review it more and see what
> could cause a crash
> on removal, may be some delayed_work related thing missing,
> unfortunately I'm
> a bit busy here since then, but will try to get to it
> soon.
Sorry I haven't been paying too much attention due to other commitments... that sounds like race condition somewhere. Besides adding flag variables, would mutex help?
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
