From: Hin-Tak Leung <htl10@users.sourceforge.net>
To: Michael Buesch <mb@bu3sch.de>,
Herton Ronaldo Krzesinski <herton@mandriva.com.br>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
John W Linville <linville@tuxdriver.com>,
linux-wireless@vger.kernel.org
Subject: Re: [RFC/RFT] rtl8187: Fix 'queuing ieee80211 work while going to suspend' warning
Date: Tue, 8 Dec 2009 22:18:32 +0000 (GMT) [thread overview]
Message-ID: <685962.23975.qm@web23105.mail.ird.yahoo.com> (raw)
In-Reply-To: <200912081341.20682.herton@mandriva.com.br>
--- On Tue, 8/12/09, Herton Ronaldo Krzesinski <herton@mandriva.com.br> 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?
next prev parent reply other threads:[~2009-12-08 22:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-08 2:08 [RFC/RFT] rtl8187: Fix 'queuing ieee80211 work while going to suspend' warning Larry Finger
2009-12-08 11:02 ` Michael Buesch
2009-12-08 15:41 ` Larry Finger
2009-12-08 15:41 ` Herton Ronaldo Krzesinski
2009-12-08 20:16 ` Larry Finger
2009-12-08 20:57 ` Herton Ronaldo Krzesinski
2009-12-08 21:00 ` Larry Finger
2009-12-08 21:07 ` Herton Ronaldo Krzesinski
2009-12-08 22:18 ` Hin-Tak Leung [this message]
2009-12-08 22:23 ` Larry Finger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=685962.23975.qm@web23105.mail.ird.yahoo.com \
--to=htl10@users.sourceforge.net \
--cc=Larry.Finger@lwfinger.net \
--cc=herton@mandriva.com.br \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).