linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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?


      

  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).