* [PATCH] mac80211: fix MLME issuing of probe requests while scanning
From: Luis R. Rodriguez @ 2009-07-23 23:37 UTC (permalink / raw)
To: johannes, linville
Cc: linux-wireless, rossi.f, Luis R. Rodriguez, Christian Lamparter,
Larry Finger
We were issuing probe requests to the associated AP on the wrong
band by having our beacon timer loss trigger while we are scanning.
When we would scan the timer could hit and force us to send a
probe request to the AP but with a chance we'd be on the wrong band.
This leads to finding no usable bitrate but we should not get so
far on the xmit path. We should not be trying to send these probe
request frames so prevent ieee80211_mgd_probe_ap() from sending
these.
As it turns out all callers of ieee80211_mgd_probe_ap() need this
check so we just move the scan check there. This means we can remove
the recenlty added check during ieee80211_sta_monitor_work().
Additionally we now fix a race condition added by the patch
"mac80211: do not monitor the connection while scanning" which
had the same check in ieee80211_sta_conn_mon_timer(). The race
happens because the timer routine *does* a valid check for
scanning but after it queues work into the mac80211 workqueue
the work callback can kick off with scanning enabled and cause
the same issue we were trying to avoid.
The more appropriate solution would be to disable the respective
timers during scan and re-enable them after scan but requires more
complex code and testing.
Cc: Christian Lamparter <chunkeey@web.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Fabio Rossi <rossi.f@inwind.it>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/mac80211/mlme.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 523c0d9..db0b4b2 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1166,6 +1166,9 @@ static void ieee80211_mgd_probe_ap(struct ieee80211_sub_if_data *sdata,
if (!netif_running(sdata->dev))
return;
+ if (sdata->local->sw_scanning || sdata->local->hw_scanning)
+ return;
+
mutex_lock(&ifmgd->mtx);
if (!ifmgd->associated)
@@ -2213,9 +2216,6 @@ static void ieee80211_sta_monitor_work(struct work_struct *work)
container_of(work, struct ieee80211_sub_if_data,
u.mgd.monitor_work);
- if (sdata->local->sw_scanning || sdata->local->hw_scanning)
- return;
-
ieee80211_mgd_probe_ap(sdata, false);
}
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] mac80211: do not trigger beacon loss work if scanning
From: Luis R. Rodriguez @ 2009-07-23 23:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linville, linux-wireless, rossi.f
In-Reply-To: <1248389978.10342.1.camel@johannes.local>
On Thu, Jul 23, 2009 at 3:59 PM, Johannes Berg<johannes@sipsolutions.net> wrote:
> On Fri, 2009-07-24 at 00:58 +0200, Johannes Berg wrote:
>
>> > @@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
>> > (struct ieee80211_sub_if_data *) data;
>> > struct ieee80211_local *local = sdata->local;
>> >
>> > - if (local->quiescing)
>> > + if (local->quiescing || local->sw_scanning || local->hw_scanning)
>>
>> I'd rather have that check in ieee80211_mgd_probe_ap itself, so it's
>> much closer to the source of the problem.
>
> And, incidentally, not racy then.
And wouldn't it be even better to just disable the timers before
scanning and re-enabling after scanning?
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: do not trigger beacon loss work if scanning
From: Johannes Berg @ 2009-07-23 22:59 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, rossi.f
In-Reply-To: <1248389904.10342.0.camel@johannes.local>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Fri, 2009-07-24 at 00:58 +0200, Johannes Berg wrote:
> > @@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
> > (struct ieee80211_sub_if_data *) data;
> > struct ieee80211_local *local = sdata->local;
> >
> > - if (local->quiescing)
> > + if (local->quiescing || local->sw_scanning || local->hw_scanning)
>
> I'd rather have that check in ieee80211_mgd_probe_ap itself, so it's
> much closer to the source of the problem.
And, incidentally, not racy then.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: do not trigger beacon loss work if scanning
From: Johannes Berg @ 2009-07-23 22:58 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linville, linux-wireless, rossi.f
In-Reply-To: <1248389377-30379-1-git-send-email-lrodriguez@atheros.com>
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]
On Thu, 2009-07-23 at 15:49 -0700, Luis R. Rodriguez wrote:
> We were issues probe requests to the associated AP on the wrong
> band by having our beacon timer loss trigger while we are scanning.
> When we would scan the timer could hit and force us to send a
> probe request to the AP but with a chance we'd be on the wrong band.
>
> This leads to finding no usable bitrate but we should not get so
> far on the xmit path. We should not be trying to send these probe
> request frames so prevent the timer from stuffing beacon loss work
> on the mac80211 workqueue when scanning.
>
> Tested-by: Fabio Rossi <rossi.f@inwind.it>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> net/mac80211/mlme.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 523c0d9..e90992e 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
> (struct ieee80211_sub_if_data *) data;
> struct ieee80211_local *local = sdata->local;
>
> - if (local->quiescing)
> + if (local->quiescing || local->sw_scanning || local->hw_scanning)
I'd rather have that check in ieee80211_mgd_probe_ap itself, so it's
much closer to the source of the problem.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* [PATCH] mac80211: do not trigger beacon loss work if scanning
From: Luis R. Rodriguez @ 2009-07-23 22:49 UTC (permalink / raw)
To: johannes, linville; +Cc: linux-wireless, rossi.f, Luis R. Rodriguez
We were issues probe requests to the associated AP on the wrong
band by having our beacon timer loss trigger while we are scanning.
When we would scan the timer could hit and force us to send a
probe request to the AP but with a chance we'd be on the wrong band.
This leads to finding no usable bitrate but we should not get so
far on the xmit path. We should not be trying to send these probe
request frames so prevent the timer from stuffing beacon loss work
on the mac80211 workqueue when scanning.
Tested-by: Fabio Rossi <rossi.f@inwind.it>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/mac80211/mlme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 523c0d9..e90992e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
(struct ieee80211_sub_if_data *) data;
struct ieee80211_local *local = sdata->local;
- if (local->quiescing)
+ if (local->quiescing || local->sw_scanning || local->hw_scanning)
return;
queue_work(sdata->local->hw.workqueue,
--
1.6.3.3
^ permalink raw reply related
* Re: Using compat-wireless w/ 2.6.27.26
From: Philip A. Prindeville @ 2009-07-23 22:45 UTC (permalink / raw)
To: Bob Copeland; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <b6c5339f0907231521v37b44d45t1852d0c5f97bc4fb@mail.gmail.com>
Bob Copeland wrote:
> On Thu, Jul 23, 2009 at 5:53 PM, Philip A.
> Prindeville<philipp_subx@redfish-solutions.com> wrote:
>>> Getting closer :-)
>>>
>>> ath5k_tx_processq(sc, &sc->txqs[i]);
>>>
>> Didn't work with rc4:
>
> What did you apply against? It's supposed to be against
> wireless-testing (or, at worst, latest compat-wireless).
>
>> BUG: unable to handle kernel NULL pointer dereference at 00000000
>> IP: [<d0935658>] :ath5k:ath5k_tasklet_tx+0x5e/0x27b
>
> Can you run scripts/markup_oops.pl on that?
>
This was against compat-wireless-2.6.31-rc4.
Alas, I already blew away the build directory...
^ permalink raw reply
* Re: any controller working in AP mode ?
From: Pavel Roskin @ 2009-07-23 22:39 UTC (permalink / raw)
To: Holger Schurig; +Cc: Ram kumar, Javier Cardona, andrey, linux-wireless
In-Reply-To: <1248366724.2661.9.camel@mj>
On Thu, 2009-07-23 at 12:32 -0400, Pavel Roskin wrote:
> In case it matters, its FCC ID is T58331GU2006M1. Some sites say its
> chipset is "Marvell 88W8338 + 88W8010", see e.g.
> http://www.xpcgear.com/zew2502.html
I've cracked it open. The big chips are Marvell 88W8338-BDK1 and
Marvell 88W8010-NNB. Thus, the above site is correct.
libertas and libertastf support 88W8388, which must be newer than
88W8338.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Bob Copeland @ 2009-07-23 22:21 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A68DBDE.7060504@redfish-solutions.com>
On Thu, Jul 23, 2009 at 5:53 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
>> Getting closer :-)
>>
>> ath5k_tx_processq(sc, &sc->txqs[i]);
>>
>
> Didn't work with rc4:
What did you apply against? It's supposed to be against
wireless-testing (or, at worst, latest compat-wireless).
> BUG: unable to handle kernel NULL pointer dereference at 00000000
> IP: [<d0935658>] :ath5k:ath5k_tasklet_tx+0x5e/0x27b
Can you run scripts/markup_oops.pl on that?
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Philip A. Prindeville @ 2009-07-23 21:53 UTC (permalink / raw)
To: Bob Copeland; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A68C821.7060208@redfish-solutions.com>
Philip A. Prindeville wrote:
> Bob Copeland wrote:
>
>> On Thu, Jul 23, 2009 at 7:24 AM, Bob Copeland<me@bobcopeland.com> wrote:
>>
>>> - ath5k_tx_processq(sc, sc->txq);
>>> + for (i=0; i < AR5K_NUM_TX_QUEUES; i++) {
>>> + if (!sc->txqs[i].setup)
>>> + continue;
>>> + ath5k_tx_processq(sc, sc->txq);
>>>
>> oops, should be:
>>
>> ath5k_tx_processq(sc, sc->txqs[i]);
>>
>>
>>> + }
>>> }
>>>
>>>
>
> Getting closer :-)
>
> ath5k_tx_processq(sc, &sc->txqs[i]);
>
Didn't work with rc4:
BUG: unable to handle kernel NULL pointer dereference at 00000000
IP: [<d0935658>] :ath5k:ath5k_tasklet_tx+0x5e/0x27b
*pde = 00000000
Oops: 0000 [#1] PREEMPT
Modules linked in: lm90 hwmon scx200_acb i2c_core bridge stp llc dummy ath5k mac80211 ath cfg80211 rfkill_backport dahdi_dummy dahdi sha512_generic sha256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher via_rhine rtc
Pid: 1585, comm: hostapd Tainted: P (2.6.27.26-astlinux #1)
EIP: 0060:[<d0935658>] EFLAGS: 00010202 CPU: 0
EIP is at ath5k_tasklet_tx+0x5e/0x27b [ath5k]
EAX: c5712000 EBX: cf994000 ECX: 00000000 EDX: 00000000
ESI: ffffff8d EDI: c5713d00 EBP: c5488920 ESP: c5713ccc
DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process hostapd (pid: 1585, ti=c5712000 task=cf86a0a0 task.ti=c5712000)
Stack: c5713cec c548bf9c c548bfb0 c548bfd0 c011a1d7 00000000 00000028 c548bfb0
00000000 00000000 00000000 00000000 00000000 00000000 c039d214 0000000a
00000009 c011a3f9 00000001 c011a111 00000046 c03473f4 00000000 c011a161
Call Trace:
[<c011a1d7>] _local_bh_enable_ip+0x72/0x7c
[<c011a3f9>] tasklet_action+0x3c/0x62
[<c011a111>] __do_softirq+0x30/0x5e
[<c011a161>] do_softirq+0x22/0x26
[<c011a4fa>] irq_exit+0x25/0x33
[<c0104a14>] do_IRQ+0x4d/0x5d
[<c0103a1b>] common_interrupt+0x23/0x28
[<c02445ec>] __sock_sendmsg+0x20/0x24
[<c0245331>] sock_sendmsg+0x95/0xad
[<c0125714>] autoremove_wake_function+0x0/0x2b
[<c0125714>] autoremove_wake_function+0x0/0x2b
[<c013aca6>] get_pageblock_flags_group+0xf/0x50
[<c024b551>] verify_iovec+0x3e/0x6d
[<c02454d6>] sys_sendmsg+0x18d/0x1ed
[<c0245d72>] sys_recvmsg+0x144/0x1c6
[<c0245de0>] sys_recvmsg+0x1b2/0x1c6
[<c0113a7b>] __wake_up+0x1d/0x45
[<c0113a93>] __wake_up+0x35/0x45
[<c024dc8e>] dev_name_hash+0x13/0x42
[<c024dc8e>] dev_name_hash+0x13/0x42
[<c024dcec>] __dev_get_by_name+0x2f/0x39
[<c011a1d7>] _local_bh_enable_ip+0x72/0x7c
[<c0246dd0>] lock_sock_nested+0xb1/0xb8
[<c011a1d7>] _local_bh_enable_ip+0x72/0x7c
[<c0246377>] sys_socketcall+0x15b/0x193
[<c0152703>] sys_close+0x75/0xc5
[<c01038b6>] syscall_call+0x7/0xb
=======================
Code: 00 03 85 b0 36 00 00 8b 3c 24 fc 89 44 24 0c 31 c0 ab ab ab ab ab 89 e0 25 00 e0 ff ff ff 40 14 8b 54 24 0c 8b 52 08 89 54 24 14 <8b> 02 8b 54 24 0c 83 c2 08 89 44 24 1c 89 54 24 08 e9 96 01 00
EIP: [<d0935658>] ath5k_tasklet_tx+0x5e/0x27b [ath5k] SS:ESP 0068:c5713ccc
Kernel panic - not syncing: Fatal exception in interrupt
^ permalink raw reply
* Re: Broadcom b4318 PCI card
From: Larry Finger @ 2009-07-23 16:52 UTC (permalink / raw)
To: Brian J. Mc Hugh; +Cc: wireless
In-Reply-To: <a23fe9cc0907231105r1fac505cle28df455b3fb7c55@mail.gmail.com>
Brian J. Mc Hugh wrote:
> Hi Larry,
>
> I have a Gateway Solo 9300 laptop with a Linksys WiFi card.
>
> WiFi used to work until I installed the latest stable Debian release (I
> following the directions at
> http://www.linuxwireless.org/en/users/Drivers/b43#fw-b43-new) .
>
> The card always receives signal from my router (iwlist wlan0 scan) but
> it often fails to transmit signal to the router and I'm unable to
> establish Internet connectivity (ifup wlan0).
>
> Any clues of how to fix this?
Please post the output of 'dmesg | grep b43'.
^ permalink raw reply
* Re: WARNING: at net/mac80211/tx.c:561
From: Fabio Rossi @ 2009-07-23 21:47 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <43e72e890907231123w7267c022yc33f4aad63e3a3fd@mail.gmail.com>
On Thursday 23 July 2009, Luis R. Rodriguez wrote:
> >> Please try this patch:
> >>
> >> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> >> Subject: [PATCH] mac80211: do not trigger beacon work if scanning
> >>
> >> We were issues probe requests to the associated AP on the wrong
> >> band. This leads to finding not bitrate. We should not be doing
> >> this, so prevent the timer from stuffing beacon loss work on
> >> the mac80211 workqueue.
> >>
> >> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> >> ---
> >> net/mac80211/mlme.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> >> index 523c0d9..e90992e 100644
> >> --- a/net/mac80211/mlme.c
> >> +++ b/net/mac80211/mlme.c
> >> @@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned
> >> long data) (struct ieee80211_sub_if_data *) data;
> >> struct ieee80211_local *local = sdata->local;
> >>
> >> - if (local->quiescing)
> >> + if (local->quiescing || local->sw_scanning ||
> >> local->hw_scanning) return;
> >
> > Heh no wait, this is very wrong.
>
> Never mind, please do try it. If we are scanning we should not be
> sending probe requests through a timer. That clarifies what I mean and
> I should add that to the commit log. But please do try it.
Patch applied, now the warning is disappeared!
Fabio
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Rafael J. Wysocki @ 2009-07-23 21:27 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Pavel Machek, Luis R. Rodriguez, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen,
ACPI Devel Maling List, pm list
In-Reply-To: <20090723201050.GD19369@khazad-dum.debian.net>
On Thursday 23 July 2009, Henrique de Moraes Holschuh wrote:
> On Thu, 23 Jul 2009, Pavel Machek wrote:
> > On Thu 2009-07-23 16:45:22, Henrique de Moraes Holschuh wrote:
> > > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > > > > Note that the "why" is unreliable by design. Network driver will
> > > > > > ignore WoL during run-time, right?
> > > > >
> > > > > "Why" is unrealible? I don't follow your reasoning. It should be as
> > > > > reliable as "who"...
> > > >
> > > > See above. The wakeup events race with each other.
> > >
> > > We deliver them all. It is that simple. The rest is up to userspace.
> >
> > Ok, but then we should not be talking about wake up events,
> > but... events.
> >
> > Like "lid opened", "wake packet came", ... . And deliver them even
> > when they happen during run-time. That's okay with me.
>
> Well, we *already* deliver "lid opened" when the lid is opened, regardless
> of it waking up the computer or not. But we are missing a way to deliver
> other classes of wakeup events.
>
> I know of at least these (incomplete list):
>
> 1. network-initiated wakeup
> a. wired
> b. wireless
> c. long-range wireless
>
> 2. platform health/condition alarms
> a. battery alarm (two levels, warning and emergency)
> b. thermal alarm (two levels, warning and emergency)
> (we need these as generic alarms, not just reason-for-wakeup)
>
> 3. device (or device tree) hotplug/hotunplug
> a. hotunplug request or notification
> (we deliver the request/notification, but we don't know we should
> go back to sleep, so all we are missing is the reason-for-wakeup
> event)
>
> 4. management
> a. wake-up/power on clock
> b. remote management command (IMPI, etc)
> c. intrusion alarm
> d. theft alarm
>
> None of those have a standard interface to notify userspace of the reason of
> the wake up AFAIK. Many of these want a generic event interface to be
> delivered not just as reason-for-wakeup, but also as runtime events.
>
> And I guess we should also tell userspace what state we are waking up from
> (S5 clean state, S5/S4 hibernation, S3), sometimes it matters.
Agreed, and same for the above.
So, what in your opinion would be the best way to expose this information?
Rafael
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Valdis.Kletnieks @ 2009-07-23 20:31 UTC (permalink / raw)
To: Pavel Machek
Cc: Henrique de Moraes Holschuh, Luis R. Rodriguez, Rafael J. Wysocki,
linux-kernel, Johannes Berg, John W. Linville, Jouni Malinen,
linux-wireless, Stephen Chen
In-Reply-To: <20090723195114.GR28158@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
On Thu, 23 Jul 2009 21:51:14 +0200, Pavel Machek said:
> Ok, but then we should not be talking about wake up events,
> but... events.
>
> Like "lid opened", "wake packet came", ... . And deliver them even
> when they happen during run-time. That's okay with me.
That's actually a sane thing to do - for instance, one of the main uses
of "wake on LAN" in many environments is to wake up a box to do software
upgrades. And if we're already up-and-running, and we "know" (from site
policy) that a W-o-L packet is only sent because IT is pushing updates,
it may make a lot of sense to catch a "wake packet" event, and go ahead
and start the software updater *anyhow* (with suitable notification/confirm
dialog to the poor guy still working on that presentation at 2AM, of course :)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Bob Copeland @ 2009-07-23 20:33 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <4A68C821.7060208@redfish-solutions.com>
On Thu, Jul 23, 2009 at 4:29 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
> Getting closer :-)
>
> ath5k_tx_processq(sc, &sc->txqs[i]);
Yeah I spotted it on my next compile but then didn't want to send
yet-another-email... Oh well :) Thanks!
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: Using compat-wireless w/ 2.6.27.26
From: Philip A. Prindeville @ 2009-07-23 20:29 UTC (permalink / raw)
To: Bob Copeland; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <b6c5339f0907230459g75cef6eag1ad0caa7b1a631b8@mail.gmail.com>
Bob Copeland wrote:
> On Thu, Jul 23, 2009 at 7:24 AM, Bob Copeland<me@bobcopeland.com> wrote:
>> - ath5k_tx_processq(sc, sc->txq);
>> + for (i=0; i < AR5K_NUM_TX_QUEUES; i++) {
>> + if (!sc->txqs[i].setup)
>> + continue;
>> + ath5k_tx_processq(sc, sc->txq);
>
> oops, should be:
>
> ath5k_tx_processq(sc, sc->txqs[i]);
>
>> + }
>> }
>>
Getting closer :-)
ath5k_tx_processq(sc, &sc->txqs[i]);
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Henrique de Moraes Holschuh @ 2009-07-23 20:10 UTC (permalink / raw)
To: Pavel Machek
Cc: Luis R. Rodriguez, Rafael J. Wysocki, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090723195114.GR28158@elf.ucw.cz>
On Thu, 23 Jul 2009, Pavel Machek wrote:
> On Thu 2009-07-23 16:45:22, Henrique de Moraes Holschuh wrote:
> > On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > > > Note that the "why" is unreliable by design. Network driver will
> > > > > ignore WoL during run-time, right?
> > > >
> > > > "Why" is unrealible? I don't follow your reasoning. It should be as
> > > > reliable as "who"...
> > >
> > > See above. The wakeup events race with each other.
> >
> > We deliver them all. It is that simple. The rest is up to userspace.
>
> Ok, but then we should not be talking about wake up events,
> but... events.
>
> Like "lid opened", "wake packet came", ... . And deliver them even
> when they happen during run-time. That's okay with me.
Well, we *already* deliver "lid opened" when the lid is opened, regardless
of it waking up the computer or not. But we are missing a way to deliver
other classes of wakeup events.
I know of at least these (incomplete list):
1. network-initiated wakeup
a. wired
b. wireless
c. long-range wireless
2. platform health/condition alarms
a. battery alarm (two levels, warning and emergency)
b. thermal alarm (two levels, warning and emergency)
(we need these as generic alarms, not just reason-for-wakeup)
3. device (or device tree) hotplug/hotunplug
a. hotunplug request or notification
(we deliver the request/notification, but we don't know we should
go back to sleep, so all we are missing is the reason-for-wakeup
event)
4. management
a. wake-up/power on clock
b. remote management command (IMPI, etc)
c. intrusion alarm
d. theft alarm
None of those have a standard interface to notify userspace of the reason of
the wake up AFAIK. Many of these want a generic event interface to be
delivered not just as reason-for-wakeup, but also as runtime events.
And I guess we should also tell userspace what state we are waking up from
(S5 clean state, S5/S4 hibernation, S3), sometimes it matters.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Pavel Machek @ 2009-07-23 19:51 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Luis R. Rodriguez, Rafael J. Wysocki, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090723194522.GC19369@khazad-dum.debian.net>
On Thu 2009-07-23 16:45:22, Henrique de Moraes Holschuh wrote:
> On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > > Note that the "why" is unreliable by design. Network driver will
> > > > ignore WoL during run-time, right?
> > >
> > > "Why" is unrealible? I don't follow your reasoning. It should be as
> > > reliable as "who"...
> >
> > See above. The wakeup events race with each other.
>
> We deliver them all. It is that simple. The rest is up to userspace.
Ok, but then we should not be talking about wake up events,
but... events.
Like "lid opened", "wake packet came", ... . And deliver them even
when they happen during run-time. That's okay with me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Henrique de Moraes Holschuh @ 2009-07-23 19:45 UTC (permalink / raw)
To: Pavel Machek
Cc: Luis R. Rodriguez, Rafael J. Wysocki, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090723191330.GQ28158@elf.ucw.cz>
On Thu, 23 Jul 2009, Pavel Machek wrote:
> > > Note that the "why" is unreliable by design. Network driver will
> > > ignore WoL during run-time, right?
> >
> > "Why" is unrealible? I don't follow your reasoning. It should be as
> > reliable as "who"...
>
> See above. The wakeup events race with each other.
We deliver them all. It is that simple. The rest is up to userspace.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Pavel Machek @ 2009-07-23 19:13 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Luis R. Rodriguez, Rafael J. Wysocki, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090723185720.GB19369@khazad-dum.debian.net>
On Thu 2009-07-23 15:57:20, Henrique de Moraes Holschuh wrote:
> On Thu, 23 Jul 2009, Pavel Machek wrote:
> > On Sat 2009-07-18 20:56:10, Henrique de Moraes Holschuh wrote:
> > > On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> > > > Hm yeah, but I doubt someone will do that, generally we'd get one wake
> > > > up event. Can't we just report the first one and ignore the rest?
> > >
> > > Well, I'd say keeping it simple is best, here. What if you ignore the more
> > > interesting wakeup events by chance (and it is really up to userspace to
> > > know what it considers interesting...)? IMHO, just issue as many
> > > notifications as needed, let userspace filter it if it wants.
> > >
> > > But if you guys are talking about something really generic, shouldn't it
> > > also provide the important "why" along with the "who"?
> > >
> > > Even for the most common cases, the "why" is useful: userspace may well want
> > > to run special routines when it wakes up because of WoL and WoW (instead of
> > > a key press, lid open or mouse movement...).
> >
> > What special routines?
>
> Starting a remote maintenance shell is a common usage scenario on corporate
> environments.
But... You want to start maintenance shell not on wakeup from WoL, but
on receiving the magic packet. If you hit the keyboard before to wake
up the machine, and the magic packet still comes, you still want the
remote maintenance shell.
> Besides, it is a generic wakeup notification we're talking about, isn't it?
> I have some that have nothing to do with WoW or WoL:
>
> 1. Thermal alarm
> 2. Battery alarm
> 3. Hotunplug request (bay/dock): umount stuff, cleanly undock, then go back
> to sleep (optional)
Well, battery&thermal alarms would certainly be useful. (And yes, I
believe it is a bug in ACPI that we don't printk on battery critical).
> > Note that the "why" is unreliable by design. Network driver will
> > ignore WoL during run-time, right?
>
> "Why" is unrealible? I don't follow your reasoning. It should be as
> reliable as "who"...
See above. The wakeup events race with each other.
> If the WoW/WoL device doesn't know why it woke up the system, it uses the
> generic reason for network devices (I don't even know if a network device
> has more than one reason for wakeup). If a different device wakes the
> system, it might know why and provide that reason. And if it doesn't know
> it woke up the system, it sends no notification at all.
See above.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] compat-wireless-old: Fix problem with TX on amd64
From: Luis R. Rodriguez @ 2009-07-23 19:03 UTC (permalink / raw)
To: Gao Lei; +Cc: linux-wireless, Tony Espy
In-Reply-To: <1248375280.22109.33.camel@mountain.triplerocks.net>
On Thu, Jul 23, 2009 at 11:54 AM, Gao Lei<lei.alvin.gao@gmail.com> wrote:
> On Wed, 2009-07-22 at 12:30 -0700, Luis R. Rodriguez wrote:
>> On Wed, Jul 22, 2009 at 12:23 PM, Gao Lei wrote:
>> > On amd64, the `ieee80211_tx_info' struct takes 56 bytes, thus cannot fit
>> > into skb's control buffer.
>>
>> Thanks, what kernel is this against BTW? Just so you know we should be
>> able to bring down compat-wireless down to 2.6.21 and maybe even
>> further now that we no longer are using the master netdev, which used
>> the multiqueue support added as of 2.6.27. Last I checked
>> compat-wireless now compiles on 2.6.25, but I never actually tried
>> loading it as I'm on ext4. So if you are on 2.6.25 or 2.6.26 you may
>> want to try out compat-wireless directly and see if to works. If you
>> are on 2.6.21..2.6.24 you can try adding backport support. I've added
>> a few files already for older kernel support based on our old
>> compat-wireless-old effort, so only the new stuff that mac80211 makes
>> use of should require backporting.
>>
>> Luis
>
> Hi,
>
> I am using kernel 2.6.26. Just tested compat-wireless and yes it works!
> Here the TX info struct takes exactly 48 bytes so it can fit well into
> the control buffer.
>
> Btw, I came up with the 'iwlagn: Unknown symbol iwl4965_agn_cfg' issue
> though (actually also in compat-wireless-old). Strange as it seems
> there're already some treatments there. Will look at it later.
May be a real issue. You can try wireless-testing directly and see if
it happens there.
> While it's great to see compat-wireless working for more old kernels, I
> wonder if compat-wireless-old is still actively maintained?
Well sure its maintained, its just deprecated now as we can backport
compat-wireless. The issue we had with compat-wireless-old is lack of
interest from developers to support it as no one cared for old drivers
and that old kernels.
> Asking this
> because currently most of the documentations still describe it as
> 'compat-wireless-old for <= 2.6.26 and compat-wireless for >= 2.6.27',
> and I was probably not the only amd64 user reading that. :)
Well so a few things:
1) We hadn't announced compat-wireless was available for older kernels
now. This was really because we had no testers.
2) you are the first to report success with 2.6.26 so that's a plus,
so now you can go ahead and update the documentation (its a wiki after
all) to mention this
3) If someone reports success with 2.6.25 then we bring the
documentation down to 2.6.25 and so on
Luis
^ permalink raw reply
* Re: Generic events for wake up from S1-S4
From: Henrique de Moraes Holschuh @ 2009-07-23 18:57 UTC (permalink / raw)
To: Pavel Machek
Cc: Luis R. Rodriguez, Rafael J. Wysocki, linux-kernel, Johannes Berg,
John W. Linville, Jouni Malinen, linux-wireless, Stephen Chen
In-Reply-To: <20090723145757.GB28158@elf.ucw.cz>
On Thu, 23 Jul 2009, Pavel Machek wrote:
> On Sat 2009-07-18 20:56:10, Henrique de Moraes Holschuh wrote:
> > On Sat, 18 Jul 2009, Luis R. Rodriguez wrote:
> > > Hm yeah, but I doubt someone will do that, generally we'd get one wake
> > > up event. Can't we just report the first one and ignore the rest?
> >
> > Well, I'd say keeping it simple is best, here. What if you ignore the more
> > interesting wakeup events by chance (and it is really up to userspace to
> > know what it considers interesting...)? IMHO, just issue as many
> > notifications as needed, let userspace filter it if it wants.
> >
> > But if you guys are talking about something really generic, shouldn't it
> > also provide the important "why" along with the "who"?
> >
> > Even for the most common cases, the "why" is useful: userspace may well want
> > to run special routines when it wakes up because of WoL and WoW (instead of
> > a key press, lid open or mouse movement...).
>
> What special routines?
Starting a remote maintenance shell is a common usage scenario on corporate
environments.
Besides, it is a generic wakeup notification we're talking about, isn't it?
I have some that have nothing to do with WoW or WoL:
1. Thermal alarm
2. Battery alarm
3. Hotunplug request (bay/dock): umount stuff, cleanly undock, then go back
to sleep (optional)
I already support them in thinkpad-acpi, but all I can do is issue a printk
and set some crap values in sysfs for userspace to query right now (I didn't
want to create yet another non-generic event interface).
> Note that the "why" is unreliable by design. Network driver will
> ignore WoL during run-time, right?
"Why" is unrealible? I don't follow your reasoning. It should be as
reliable as "who"...
If the WoW/WoL device doesn't know why it woke up the system, it uses the
generic reason for network devices (I don't even know if a network device
has more than one reason for wakeup). If a different device wakes the
system, it might know why and provide that reason. And if it doesn't know
it woke up the system, it sends no notification at all.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] compat-wireless-old: Fix problem with TX on amd64
From: Gao Lei @ 2009-07-23 18:54 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890907221230m53109c3eqf388a2d987d8cdda@mail.gmail.com>
On Wed, 2009-07-22 at 12:30 -0700, Luis R. Rodriguez wrote:
> On Wed, Jul 22, 2009 at 12:23 PM, Gao Lei wrote:
> > On amd64, the `ieee80211_tx_info' struct takes 56 bytes, thus cannot fit
> > into skb's control buffer.
>
> Thanks, what kernel is this against BTW? Just so you know we should be
> able to bring down compat-wireless down to 2.6.21 and maybe even
> further now that we no longer are using the master netdev, which used
> the multiqueue support added as of 2.6.27. Last I checked
> compat-wireless now compiles on 2.6.25, but I never actually tried
> loading it as I'm on ext4. So if you are on 2.6.25 or 2.6.26 you may
> want to try out compat-wireless directly and see if to works. If you
> are on 2.6.21..2.6.24 you can try adding backport support. I've added
> a few files already for older kernel support based on our old
> compat-wireless-old effort, so only the new stuff that mac80211 makes
> use of should require backporting.
>
> Luis
Hi,
I am using kernel 2.6.26. Just tested compat-wireless and yes it works!
Here the TX info struct takes exactly 48 bytes so it can fit well into
the control buffer.
Btw, I came up with the 'iwlagn: Unknown symbol iwl4965_agn_cfg' issue
though (actually also in compat-wireless-old). Strange as it seems
there're already some treatments there. Will look at it later.
While it's great to see compat-wireless working for more old kernels, I
wonder if compat-wireless-old is still actively maintained? Asking this
because currently most of the documentations still describe it as
'compat-wireless-old for <= 2.6.26 and compat-wireless for >= 2.6.27',
and I was probably not the only amd64 user reading that. :)
Best regards,
Gao Lei
^ permalink raw reply
* Re: WARNING: at net/mac80211/tx.c:561
From: Luis R. Rodriguez @ 2009-07-23 18:23 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Fabio Rossi, linux-wireless
In-Reply-To: <43e72e890907231119s5e992c91r2225f6ea77543dc8@mail.gmail.com>
On Thu, Jul 23, 2009 at 11:19 AM, Luis R. Rodriguez<mcgrof@gmail.com> wrote:
> On Thu, Jul 23, 2009 at 11:17 AM, Luis R.
> Rodriguez<mcgrof@bombadil.infradead.org> wrote:
>> On Thu, Jul 23, 2009 at 07:28:44PM +0200, Fabio Rossi wrote:
>>> On Thursday 23 July 2009, Luis R. Rodriguez wrote:
>>>
>>> > On Thu, Jul 23, 2009 at 10:07 AM, Fabio Rossi<rossi.f@inwind.it> wrote:
>>> > > On Thursday 23 July 2009, Luis R. Rodriguez wrote:
>>> > >> On Wed, Jul 22, 2009 at 3:51 PM, Fabio Rossi<rossi.f@inwind.it> wrote:
>>> > >> > I'm using the last wireless-testing.git and I have experienced the
>>> > >> > following WARNING:
>>> > >> >
>>> > >> > WARNING: at net/mac80211/tx.c:561
>>> > >> > ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]()
>>> > >>
>>> > >> Please try a git pull
>>> > >
>>> > > I was already working with the latest release:
>>> > > v2.6.31-rc3-28452-g5bfcdb0
>>> > > so I confirm that I get the warning quite often (every 15 seconds).
>>> >
>>> > What channel is your AP on?
>>> > Is your AP 00:0c:f6:xx:xx:xx ?
>>>
>>> Yes, that is my AP configured on channel 8 (Frequency 2.447 GHz):
>>>
>>> Cell 05 - Address: 00:0C:F6:xx:xx:xx
>>> Channel:8
>>> Frequency:2.447 GHz (Channel 8)
>>> Quality=48/70 Signal level=-62 dBm
>>> Encryption key:on
>>> ESSID:""
>>> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
>>> Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
>>> 36 Mb/s; 48 Mb/s; 54 Mb/s
>>> Mode:Master
>>> Extra:tsf=000000007803aa0c
>>> Extra: Last beacon: 4352ms ago
>>> IE: Unknown: 0000
>>> IE: Unknown: 010482848B96
>>> IE: Unknown: 030108
>>> IE: Unknown: 050400010000
>>> IE: Unknown: 2A0104
>>> IE: Unknown: 32080C1218243048606C
>>> IE: Unknown: DD07000C4301000000
>>
>> It is as I suspected, a real WARNING for a bug in mac80211, we should
>> not be sending frames on 5 GHz onyour 2.4 GHz AP.
>>
>> Please try this patch:
>>
>> From: Luis R. Rodriguez <lrodriguez@atheros.com>
>> Subject: [PATCH] mac80211: do not trigger beacon work if scanning
>>
>> We were issues probe requests to the associated AP on the wrong
>> band. This leads to finding not bitrate. We should not be doing
>> this, so prevent the timer from stuffing beacon loss work on
>> the mac80211 workqueue.
>>
>> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
>> ---
>> net/mac80211/mlme.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
>> index 523c0d9..e90992e 100644
>> --- a/net/mac80211/mlme.c
>> +++ b/net/mac80211/mlme.c
>> @@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
>> (struct ieee80211_sub_if_data *) data;
>> struct ieee80211_local *local = sdata->local;
>>
>> - if (local->quiescing)
>> + if (local->quiescing || local->sw_scanning || local->hw_scanning)
>> return;
>
> Heh no wait, this is very wrong.
Never mind, please do try it. If we are scanning we should not be
sending probe requests through a timer. That clarifies what I mean and
I should add that to the commit log. But please do try it.
Luis
^ permalink raw reply
* Re: WARNING: at net/mac80211/tx.c:561
From: Luis R. Rodriguez @ 2009-07-23 18:19 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Fabio Rossi, linux-wireless
In-Reply-To: <20090723181716.GA26729@bombadil.infradead.org>
On Thu, Jul 23, 2009 at 11:17 AM, Luis R.
Rodriguez<mcgrof@bombadil.infradead.org> wrote:
> On Thu, Jul 23, 2009 at 07:28:44PM +0200, Fabio Rossi wrote:
>> On Thursday 23 July 2009, Luis R. Rodriguez wrote:
>>
>> > On Thu, Jul 23, 2009 at 10:07 AM, Fabio Rossi<rossi.f@inwind.it> wrote:
>> > > On Thursday 23 July 2009, Luis R. Rodriguez wrote:
>> > >> On Wed, Jul 22, 2009 at 3:51 PM, Fabio Rossi<rossi.f@inwind.it> wrote:
>> > >> > I'm using the last wireless-testing.git and I have experienced the
>> > >> > following WARNING:
>> > >> >
>> > >> > WARNING: at net/mac80211/tx.c:561
>> > >> > ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]()
>> > >>
>> > >> Please try a git pull
>> > >
>> > > I was already working with the latest release:
>> > > v2.6.31-rc3-28452-g5bfcdb0
>> > > so I confirm that I get the warning quite often (every 15 seconds).
>> >
>> > What channel is your AP on?
>> > Is your AP 00:0c:f6:xx:xx:xx ?
>>
>> Yes, that is my AP configured on channel 8 (Frequency 2.447 GHz):
>>
>> Cell 05 - Address: 00:0C:F6:xx:xx:xx
>> Channel:8
>> Frequency:2.447 GHz (Channel 8)
>> Quality=48/70 Signal level=-62 dBm
>> Encryption key:on
>> ESSID:""
>> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
>> Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
>> 36 Mb/s; 48 Mb/s; 54 Mb/s
>> Mode:Master
>> Extra:tsf=000000007803aa0c
>> Extra: Last beacon: 4352ms ago
>> IE: Unknown: 0000
>> IE: Unknown: 010482848B96
>> IE: Unknown: 030108
>> IE: Unknown: 050400010000
>> IE: Unknown: 2A0104
>> IE: Unknown: 32080C1218243048606C
>> IE: Unknown: DD07000C4301000000
>
> It is as I suspected, a real WARNING for a bug in mac80211, we should
> not be sending frames on 5 GHz onyour 2.4 GHz AP.
>
> Please try this patch:
>
> From: Luis R. Rodriguez <lrodriguez@atheros.com>
> Subject: [PATCH] mac80211: do not trigger beacon work if scanning
>
> We were issues probe requests to the associated AP on the wrong
> band. This leads to finding not bitrate. We should not be doing
> this, so prevent the timer from stuffing beacon loss work on
> the mac80211 workqueue.
>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
> net/mac80211/mlme.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> index 523c0d9..e90992e 100644
> --- a/net/mac80211/mlme.c
> +++ b/net/mac80211/mlme.c
> @@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
> (struct ieee80211_sub_if_data *) data;
> struct ieee80211_local *local = sdata->local;
>
> - if (local->quiescing)
> + if (local->quiescing || local->sw_scanning || local->hw_scanning)
> return;
Heh no wait, this is very wrong.
Luis
^ permalink raw reply
* Re: WARNING: at net/mac80211/tx.c:561
From: Luis R. Rodriguez @ 2009-07-23 18:17 UTC (permalink / raw)
To: Fabio Rossi; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <200907231928.44337.rossi.f@inwind.it>
On Thu, Jul 23, 2009 at 07:28:44PM +0200, Fabio Rossi wrote:
> On Thursday 23 July 2009, Luis R. Rodriguez wrote:
>
> > On Thu, Jul 23, 2009 at 10:07 AM, Fabio Rossi<rossi.f@inwind.it> wrote:
> > > On Thursday 23 July 2009, Luis R. Rodriguez wrote:
> > >> On Wed, Jul 22, 2009 at 3:51 PM, Fabio Rossi<rossi.f@inwind.it> wrote:
> > >> > I'm using the last wireless-testing.git and I have experienced the
> > >> > following WARNING:
> > >> >
> > >> > WARNING: at net/mac80211/tx.c:561
> > >> > ieee80211_tx_h_rate_ctrl+0x3d1/0x470 [mac80211]()
> > >>
> > >> Please try a git pull
> > >
> > > I was already working with the latest release:
> > > v2.6.31-rc3-28452-g5bfcdb0
> > > so I confirm that I get the warning quite often (every 15 seconds).
> >
> > What channel is your AP on?
> > Is your AP 00:0c:f6:xx:xx:xx ?
>
> Yes, that is my AP configured on channel 8 (Frequency 2.447 GHz):
>
> Cell 05 - Address: 00:0C:F6:xx:xx:xx
> Channel:8
> Frequency:2.447 GHz (Channel 8)
> Quality=48/70 Signal level=-62 dBm
> Encryption key:on
> ESSID:""
> Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
> Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
> 36 Mb/s; 48 Mb/s; 54 Mb/s
> Mode:Master
> Extra:tsf=000000007803aa0c
> Extra: Last beacon: 4352ms ago
> IE: Unknown: 0000
> IE: Unknown: 010482848B96
> IE: Unknown: 030108
> IE: Unknown: 050400010000
> IE: Unknown: 2A0104
> IE: Unknown: 32080C1218243048606C
> IE: Unknown: DD07000C4301000000
It is as I suspected, a real WARNING for a bug in mac80211, we should
not be sending frames on 5 GHz onyour 2.4 GHz AP.
Please try this patch:
From: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] mac80211: do not trigger beacon work if scanning
We were issues probe requests to the associated AP on the wrong
band. This leads to finding not bitrate. We should not be doing
this, so prevent the timer from stuffing beacon loss work on
the mac80211 workqueue.
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
net/mac80211/mlme.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 523c0d9..e90992e 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2187,7 +2187,7 @@ static void ieee80211_sta_bcn_mon_timer(unsigned long data)
(struct ieee80211_sub_if_data *) data;
struct ieee80211_local *local = sdata->local;
- if (local->quiescing)
+ if (local->quiescing || local->sw_scanning || local->hw_scanning)
return;
queue_work(sdata->local->hw.workqueue,
--
1.6.3.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox