[PATCH v3 00/11] ath9k / mac80211: power save fixes

[PATCH v3 00/11] ath9k / mac80211: power save fixes

[Luis R. Rodriguez]

I reordered the patches, enhanced the commit log entries and
and added a new patch to address ANI / the TX monitor, figured I'd just
send a new series just to be clear.

My next peet peeve is this:

Sep 14 16:36:02 tux kernel: [ 1369.000106] ath: Set channel: 5220 MHz
Sep 14 16:36:02 tux kernel: [ 1369.000116] ath: tx chmask: 3, rx chmask: 3
Sep 14 16:36:02 tux kernel: [ 1369.000240] ath: (2412 MHz) -> (5220 MHz), conf_is_ht40: 0
Sep 14 16:36:02 tux kernel: [ 1369.063449] ath: Set channel: 2412 MHz
Sep 14 16:36:03 tux kernel: [ 1369.063459] ath: tx chmask: 3, rx chmask: 3
Sep 14 16:36:03 tux kernel: [ 1369.063584] ath: (5220 MHz) -> (2412 MHz), conf_is_ht40: 0
Sep 14 16:36:03 tux kernel: [ 1369.360111] ath: Set channel: 5240 MHz
Sep 14 16:36:03 tux kernel: [ 1369.360120] ath: tx chmask: 3, rx chmask: 3
Sep 14 16:36:03 tux kernel: [ 1369.360245] ath: (2412 MHz) -> (5240 MHz), conf_is_ht40: 0
Sep 14 16:36:03 tux kernel: [ 1369.422736] ath: Set channel: 2412 MHz
Sep 14 16:36:03 tux kernel: [ 1369.422745] ath: tx chmask: 3, rx chmask: 3
Sep 14 16:36:03 tux kernel: [ 1369.422867] ath: (5240 MHz) -> (2412 MHz), conf_is_ht40: 0
Sep 14 16:36:03 tux kernel: [ 1369.564685] __ratelimit: 81 callbacks suppressed
Sep 14 16:36:03 tux kernel: [ 1369.564692] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564698] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564703] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564708] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564713] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564718] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564723] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564728] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564733] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.564738] phy0: release an RX reorder frame due to timeout on earlier frames
Sep 14 16:36:03 tux kernel: [ 1369.720129] ath: Set channel: 5260 MHz
Sep 14 16:36:03 tux kernel: [ 1369.720139] ath: tx chmask: 3, rx chmask: 3
Sep 14 16:36:03 tux kernel: [ 1369.720263] ath: (2412 MHz) -> (5260 MHz), conf_is_ht40: 0

My guess is we are not suspending / stopping the aggregations sessions /
or simply extending the timer when going off channel. 

Luis R. Rodriguez (10):
  ath9k: fix power save race conditions
  ath9k: fix regression on beacon loss after bgscan
  ath9k: fix enabling ANI / tx monitor after bg scan
  mac80211: add helper for reseting the connection monitor
  mac80211: reset probe send counter upon connection timer reset
  mac80211: reset connection idle when going offchannel
  mac80211: make the beacon monitor available externally
  mac80211: disable beacon monitor while going offchannel
  mac80211: send last 3/5 probe requests as unicast
  ath9k: fix regression which disabled ps on ath9k

Senthil Balasubramanian (1):
  ath9k: fix regression which prevents chip sleep after CAB data

 drivers/net/wireless/ath/ath9k/ath9k.h |    1 -
 drivers/net/wireless/ath/ath9k/init.c  |    3 +-
 drivers/net/wireless/ath/ath9k/main.c  |   15 ++++++-----
 drivers/net/wireless/ath/ath9k/recv.c  |    9 ++++--
 net/mac80211/ieee80211_i.h             |    2 +
 net/mac80211/mlme.c                    |   40 +++++++++++++++++++++++--------
 net/mac80211/offchannel.c              |    7 +++++
 7 files changed, 54 insertions(+), 23 deletions(-)

[PATCH v3 01/11] ath9k: fix power save race conditions

[Luis R. Rodriguez]

ath9k has a race on putting the chip into network sleep and
having registers read from hardware. The race occurs because
although ath9k_ps_restore() locks its own callers it makes use
of some variables which get altered in the driver at different
code paths. The variables are the ps_enabled and ps_flags.

This is easily reprodicible in large network environments when
roaming with the wpa_supplicant simple bgscan. You'd get some
0xdeadbeef read out on certain registers such as:

ath: timeout (100000 us) on reg 0x806c: 0xdeadbeef & 0x01f00000 != 0x00000000
ath: RX failed to go idle in 10 ms RXSM=0xdeadbeef

ath: timeout (100000 us) on reg 0x7000: 0xdeadbeef & 0x00000003 != 0x00000000
ath: Chip reset failed

The fix is to protect the ath9k_config(hw, IEEE80211_CONF_CHANGE_PS)
calls with a spin_lock_irqsave() which will disable contendors for
these variables from interrupt context, timers, re-entry from mac80211
on the same callback, and most importantly from ath9k_ps_restore()
which is the only call which will put the device into network sleep.

There are quite a few threads and bug reports on these a few of them are:

https://bugs.launchpad.net/ubuntu/karmic/+source/linux/+bug/407040
http://code.google.com/p/chromium-os/issues/detail?id=5709
http://code.google.com/p/chromium-os/issues/detail?id=5943

Stable fixes apply to [2.6.32+]

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/main.c |    5 ++++-
 drivers/net/wireless/ath/ath9k/recv.c |    3 +++
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index a2f7eb2..826315d 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1554,6 +1554,8 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
 	 * IEEE80211_CONF_CHANGE_PS is only passed by mac80211 for STA mode.
 	 */
 	if (changed & IEEE80211_CONF_CHANGE_PS) {
+		unsigned long flags;
+		spin_lock_irqsave(&sc->sc_pm_lock, flags);
 		if (conf->flags & IEEE80211_CONF_PS) {
 			sc->ps_flags |= PS_ENABLED;
 			/*
@@ -1568,7 +1570,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
 			sc->ps_enabled = false;
 			sc->ps_flags &= ~(PS_ENABLED |
 					  PS_NULLFUNC_COMPLETED);
-			ath9k_setpower(sc, ATH9K_PM_AWAKE);
+			ath9k_hw_setpower(sc->sc_ah, ATH9K_PM_AWAKE);
 			if (!(ah->caps.hw_caps &
 			      ATH9K_HW_CAP_AUTOSLEEP)) {
 				ath9k_hw_setrxabort(sc->sc_ah, 0);
@@ -1583,6 +1585,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
 				}
 			}
 		}
+		spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
 	}
 
 	if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 6fb3b45..7523f7d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -1640,6 +1640,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
 	u8 rx_status_len = ah->caps.rx_status_len;
 	u64 tsf = 0;
 	u32 tsf_lower = 0;
+	unsigned long flags;
 
 	if (edma)
 		dma_type = DMA_BIDIRECTIONAL;
@@ -1748,11 +1749,13 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
 			sc->rx.rxotherant = 0;
 		}
 
+		spin_lock_irqsave(&sc->sc_pm_lock, flags);
 		if (unlikely(ath9k_check_auto_sleep(sc) ||
 			     (sc->ps_flags & (PS_WAIT_FOR_BEACON |
 					      PS_WAIT_FOR_CAB |
 					      PS_WAIT_FOR_PSPOLL_DATA))))
 			ath_rx_ps(sc, skb);
+		spin_unlock_irqrestore(&sc->sc_pm_lock, flags);
 
 		if (ah->caps.hw_caps & ATH9K_HW_CAP_ANT_DIV_COMB)
 			ath_ant_comb_scan(sc, &rs);
-- 
1.7.0.4

[PATCH v3 02/11] ath9k: fix regression on beacon loss after bgscan

[Luis R. Rodriguez]

When we return to the home channel we were never reseting our beacon
timers, this was casued by the fact that the scanning flag was still
on even after we returned to our home channel. There are also other
reasons why we would get a reset and if we are not off channel
we always need to resynch our beacon timers, because a reset will
clear them.

This bug is a regression introduced on 2.6.36. The order of the
changes are as follows:

5ee08656 - Sat Jul 31 - ath9k: prevent calibration during off-channel activity
a0daa0e7 - Tue Jul 27 - Revert "mac80211: fix sw scan bracketing"
543708be - Fri Jun 18 - mac80211: fix sw scan bracketing

mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
        --contains 5ee0865615f65f84e6ee9174771a6716c29e08e1
v2.6.36-rc1~43^2~34^2~22

mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
        --contains a0daa0e7592ada797d6835f11529097aabc27ad2
v2.6.36-rc1~571^2~64^2~13

mcgrof@tux ~/linux-2.6-allstable (git::master)$ git describe \
        --contains 543708be320d7df692d24b349ca01a947b340764
v2.6.36-rc1~571^2~107^2~187

So 5ee08656 would have worked if a0daa0e7 was not committed but
it was so this means 5ee08656 was broken since it assumed that
when we were in the channel change routine the scan flag would
be lifted. As it turns out the scan flag will be set when we
are already on the home channel.

For more details refer to:

http://code.google.com/p/chromium-os/issues/detail?id=5715

These issues will need to be considered for our solution on
reshifting the scan complete callback location on mac80211 on
current development kernel work.

This patch has stable fixes which apply down to [2.6.36+]

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/main.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 826315d..186afec 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -258,9 +258,11 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 	if (!(sc->sc_flags & (SC_OP_OFFCHANNEL | SC_OP_SCANNING))) {
 		ath_start_ani(common);
 		ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work, 0);
-		ath_beacon_config(sc, NULL);
 	}
 
+	if (!(sc->sc_flags & (SC_OP_OFFCHANNEL)))
+		ath_beacon_config(sc, NULL);
+
  ps_restore:
 	ath9k_ps_restore(sc);
 	return r;
@@ -957,7 +959,7 @@ int ath_reset(struct ath_softc *sc, bool retry_tx)
 
 	ath_update_txpow(sc);
 
-	if (sc->sc_flags & SC_OP_BEACONS)
+	if ((sc->sc_flags & SC_OP_BEACONS) || !(sc->sc_flags & (SC_OP_OFFCHANNEL)))
 		ath_beacon_config(sc, NULL);	/* restart beacons */
 
 	ath9k_hw_set_interrupts(ah, ah->imask);
-- 
1.7.0.4

[PATCH v3 03/11] ath9k: fix enabling ANI / tx monitor after bg scan

[Luis R. Rodriguez]

ath9k's entire logic with SC_OP_SCANNING is incorrect due to the
way mac80211 currently implements the scan complete callback and
we handle it in ath9k. This patch removes the flag completely in
preference for the SC_OP_OFFCHANNEL which is really what we wanted.

The scanning flag was used to ensure we reset ANI to the old values
when we go back to the home channel, but if we are offchannel we
use some defaults. The flag was also used to re-enable the TX monitor.

Without this patch we simply never re-enabled ANI and the TX monitor
after going offchannel. This means that after one background
scan we are prone to noise issues and if we had a TX hang we would
not recover. To get this to work properly we must enable ANI after
we have configured the beacon timers, otherwise hardware acts really
oddly.

This patch has stable fixes which apply down to [2.6.36+], there
*may* be a to fix this on older kernels but requires a bit of
work since this patch relies on the new mac80211 flag
IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36.

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/ath9k.h |    1 -
 drivers/net/wireless/ath/ath9k/main.c  |   10 +++-------
 drivers/net/wireless/ath/ath9k/recv.c  |    4 ++--
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index c8ff417..98b57e6 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -563,7 +563,6 @@ struct ath_ant_comb {
 #define SC_OP_RXFLUSH                BIT(7)
 #define SC_OP_LED_ASSOCIATED         BIT(8)
 #define SC_OP_LED_ON                 BIT(9)
-#define SC_OP_SCANNING               BIT(10)
 #define SC_OP_TSF_RESET              BIT(11)
 #define SC_OP_BT_PRIORITY_DETECTED   BIT(12)
 #define SC_OP_BT_SCAN		     BIT(13)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 186afec..3d72c27 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -255,14 +255,12 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
 	ath_update_txpow(sc);
 	ath9k_hw_set_interrupts(ah, ah->imask);
 
-	if (!(sc->sc_flags & (SC_OP_OFFCHANNEL | SC_OP_SCANNING))) {
-		ath_start_ani(common);
+	if (!(sc->sc_flags & (SC_OP_OFFCHANNEL))) {
+		ath_beacon_config(sc, NULL);
 		ieee80211_queue_delayed_work(sc->hw, &sc->tx_complete_work, 0);
+		ath_start_ani(common);
 	}
 
-	if (!(sc->sc_flags & (SC_OP_OFFCHANNEL)))
-		ath_beacon_config(sc, NULL);
-
  ps_restore:
 	ath9k_ps_restore(sc);
 	return r;
@@ -2036,7 +2034,6 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
 
 	aphy->state = ATH_WIPHY_SCAN;
 	ath9k_wiphy_pause_all_forced(sc, aphy);
-	sc->sc_flags |= SC_OP_SCANNING;
 	mutex_unlock(&sc->mutex);
 }
 
@@ -2051,7 +2048,6 @@ static void ath9k_sw_scan_complete(struct ieee80211_hw *hw)
 
 	mutex_lock(&sc->mutex);
 	aphy->state = ATH_WIPHY_ACTIVE;
-	sc->sc_flags &= ~SC_OP_SCANNING;
 	mutex_unlock(&sc->mutex);
 }
 
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 7523f7d..efd0651 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -300,7 +300,7 @@ static void ath_edma_start_recv(struct ath_softc *sc)
 
 	ath_opmode_init(sc);
 
-	ath9k_hw_startpcureceive(sc->sc_ah, (sc->sc_flags & SC_OP_SCANNING));
+	ath9k_hw_startpcureceive(sc->sc_ah, (sc->sc_flags & SC_OP_OFFCHANNEL));
 }
 
 static void ath_edma_stop_recv(struct ath_softc *sc)
@@ -506,7 +506,7 @@ int ath_startrecv(struct ath_softc *sc)
 start_recv:
 	spin_unlock_bh(&sc->rx.rxbuflock);
 	ath_opmode_init(sc);
-	ath9k_hw_startpcureceive(ah, (sc->sc_flags & SC_OP_SCANNING));
+	ath9k_hw_startpcureceive(ah, (sc->sc_flags & SC_OP_OFFCHANNEL));
 
 	return 0;
 }
-- 
1.7.0.4

[PATCH v3 04/11] mac80211: add helper for reseting the connection monitor

[Luis R. Rodriguez]

This will be used in another place later. The connection
monitor was added as of 2.6.35 so these fixes will be
applicable to >= 2.6.35.

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/ieee80211_i.h |    1 +
 net/mac80211/mlme.c        |   15 ++++++++++-----
 2 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4e635e2..737fd0f 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1041,6 +1041,7 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
 void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata);
 void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
 				  struct sk_buff *skb);
+void ieee80211_sta_reset_conn_monitor(struct ieee80211_sub_if_data *sdata);
 
 /* IBSS code */
 void ieee80211_ibss_notify_scan_completed(struct ieee80211_local *local);
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 0cb822c..cfdafb7 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -124,6 +124,15 @@ static void mod_beacon_timer(struct ieee80211_sub_if_data *sdata)
 		  round_jiffies_up(jiffies + IEEE80211_BEACON_LOSS_TIME));
 }
 
+void ieee80211_sta_reset_conn_monitor(struct ieee80211_sub_if_data *sdata)
+{
+	if (sdata->local->hw.flags & IEEE80211_HW_CONNECTION_MONITOR)
+		return;
+
+	mod_timer(&sdata->u.mgd.conn_mon_timer,
+		  round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
+}
+
 static int ecw2cw(int ecw)
 {
 	return (1 << ecw) - 1;
@@ -1018,11 +1027,7 @@ void ieee80211_sta_rx_notify(struct ieee80211_sub_if_data *sdata,
 	if (is_multicast_ether_addr(hdr->addr1))
 		return;
 
-	if (sdata->local->hw.flags & IEEE80211_HW_CONNECTION_MONITOR)
-		return;
-
-	mod_timer(&sdata->u.mgd.conn_mon_timer,
-		  round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
+	ieee80211_sta_reset_conn_monitor(sdata);
 }
 
 static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
-- 
1.7.0.4

[PATCH v3 05/11] mac80211: reset probe send counter upon connection timer reset

[Luis R. Rodriguez]

Upon beacon loss we send probe requests after 30 seconds of idle
time and we wait for each probe response 1/2 second. We send a
total of 3 probe requests before giving up on the AP. In the case
that we reset the connection idle monitor we should reset the probe
requests count to 0. Right now this won't help in any way but
the next patch will.

This patch has fixes for stable kernel [2.6.35+].

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/mlme.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index cfdafb7..172a397 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -126,11 +126,15 @@ static void mod_beacon_timer(struct ieee80211_sub_if_data *sdata)
 
 void ieee80211_sta_reset_conn_monitor(struct ieee80211_sub_if_data *sdata)
 {
+	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+
 	if (sdata->local->hw.flags & IEEE80211_HW_CONNECTION_MONITOR)
 		return;
 
 	mod_timer(&sdata->u.mgd.conn_mon_timer,
 		  round_jiffies_up(jiffies + IEEE80211_CONNECTION_IDLE_TIME));
+
+	ifmgd->probe_send_count = 0;
 }
 
 static int ecw2cw(int ecw)
-- 
1.7.0.4

[PATCH v3 06/11] mac80211: reset connection idle when going offchannel

[Luis R. Rodriguez]

When we go offchannel mac80211 currently leaves alive the
connection idle monitor. This should be instead postponed
until we come back to our home channel, otherwise by the
time we get back to the home channel we could be triggering
unecesary probe requests. For APs that do not respond to
unicast probe requests (Nexus One is a simple example) this
means we essentially get disconnected after the probes
fails.

This patch has stable fixes for kernels [2.6.35+]

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/offchannel.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index eeacaa5..627a33e 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -22,12 +22,15 @@
 static void ieee80211_offchannel_ps_enable(struct ieee80211_sub_if_data *sdata)
 {
 	struct ieee80211_local *local = sdata->local;
+	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 
 	local->offchannel_ps_enabled = false;
 
 	/* FIXME: what to do when local->pspolling is true? */
 
 	del_timer_sync(&local->dynamic_ps_timer);
+	del_timer_sync(&ifmgd->conn_mon_timer);
+
 	cancel_work_sync(&local->dynamic_ps_enable_work);
 
 	if (local->hw.conf.flags & IEEE80211_CONF_PS) {
@@ -85,6 +88,8 @@ static void ieee80211_offchannel_ps_disable(struct ieee80211_sub_if_data *sdata)
 		mod_timer(&local->dynamic_ps_timer, jiffies +
 			  msecs_to_jiffies(local->hw.conf.dynamic_ps_timeout));
 	}
+
+	ieee80211_sta_reset_conn_monitor(sdata);
 }
 
 void ieee80211_offchannel_stop_beaconing(struct ieee80211_local *local)
-- 
1.7.0.4

[PATCH v3 07/11] mac80211: make the beacon monitor available externally

[Luis R. Rodriguez]

This will be used by other components next. The beacon
monitor was added as of 2.6.34 so these fixes are applicable
only to kernels >= 2.6.34.

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/ieee80211_i.h |    1 +
 net/mac80211/mlme.c        |    8 ++++----
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 737fd0f..9346a6b 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1041,6 +1041,7 @@ void ieee80211_sta_restart(struct ieee80211_sub_if_data *sdata);
 void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata);
 void ieee80211_sta_rx_queued_mgmt(struct ieee80211_sub_if_data *sdata,
 				  struct sk_buff *skb);
+void ieee80211_sta_reset_beacon_monitor(struct ieee80211_sub_if_data *sdata);
 void ieee80211_sta_reset_conn_monitor(struct ieee80211_sub_if_data *sdata);
 
 /* IBSS code */
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 172a397..c2e1838 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -115,7 +115,7 @@ static void run_again(struct ieee80211_if_managed *ifmgd,
 		mod_timer(&ifmgd->timer, timeout);
 }
 
-static void mod_beacon_timer(struct ieee80211_sub_if_data *sdata)
+void ieee80211_sta_reset_beacon_monitor(struct ieee80211_sub_if_data *sdata)
 {
 	if (sdata->local->hw.flags & IEEE80211_HW_BEACON_FILTER)
 		return;
@@ -1390,7 +1390,7 @@ static bool ieee80211_assoc_success(struct ieee80211_work *wk,
 	 * Also start the timer that will detect beacon loss.
 	 */
 	ieee80211_sta_rx_notify(sdata, (struct ieee80211_hdr *)mgmt);
-	mod_beacon_timer(sdata);
+	ieee80211_sta_reset_beacon_monitor(sdata);
 
 	return true;
 }
@@ -1493,7 +1493,7 @@ static void ieee80211_rx_mgmt_probe_resp(struct ieee80211_sub_if_data *sdata,
 		 * we have or will be receiving any beacons or data, so let's
 		 * schedule the timers again, just in case.
 		 */
-		mod_beacon_timer(sdata);
+		ieee80211_sta_reset_beacon_monitor(sdata);
 
 		mod_timer(&ifmgd->conn_mon_timer,
 			  round_jiffies_up(jiffies +
@@ -1619,7 +1619,7 @@ static void ieee80211_rx_mgmt_beacon(struct ieee80211_sub_if_data *sdata,
 	 * Push the beacon loss detection into the future since
 	 * we are processing a beacon from the AP just now.
 	 */
-	mod_beacon_timer(sdata);
+	ieee80211_sta_reset_beacon_monitor(sdata);
 
 	ncrc = crc32_be(0, (void *)&mgmt->u.beacon.beacon_int, 4);
 	ncrc = ieee802_11_parse_elems_crc(mgmt->u.beacon.variable,
-- 
1.7.0.4

[PATCH v3 08/11] mac80211: disable beacon monitor while going offchannel

[Luis R. Rodriguez]

The beacon monitor should be disabled when going off channel
to prevent spurious warnings and triggering connection
deterioration work such as sending probe requests. Re-enable
the beacon monitor once we come back to the home channel.

This patch has fixes for stable kernels [2.6.34+].

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/offchannel.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/net/mac80211/offchannel.c b/net/mac80211/offchannel.c
index 627a33e..4b56409 100644
--- a/net/mac80211/offchannel.c
+++ b/net/mac80211/offchannel.c
@@ -29,6 +29,7 @@ static void ieee80211_offchannel_ps_enable(struct ieee80211_sub_if_data *sdata)
 	/* FIXME: what to do when local->pspolling is true? */
 
 	del_timer_sync(&local->dynamic_ps_timer);
+	del_timer_sync(&ifmgd->bcn_mon_timer);
 	del_timer_sync(&ifmgd->conn_mon_timer);
 
 	cancel_work_sync(&local->dynamic_ps_enable_work);
@@ -89,6 +90,7 @@ static void ieee80211_offchannel_ps_disable(struct ieee80211_sub_if_data *sdata)
 			  msecs_to_jiffies(local->hw.conf.dynamic_ps_timeout));
 	}
 
+	ieee80211_sta_reset_beacon_monitor(sdata);
 	ieee80211_sta_reset_conn_monitor(sdata);
 }
 
-- 
1.7.0.4

[PATCH v3 09/11] mac80211: send last 3/5 probe requests as unicast

[Luis R. Rodriguez]

Some buggy APs do not respond to unicast probe requests
or send unicast probe requests very delayed so in the
worst case we should try to send broadcast probe requests,
otherwise we can get disconnected from these APs.

Even if drivers do not have filters to disregard probe
responses from foreign APs mac80211 will only process
probe responses from our associated AP for re-arming
connection monitoring.

We need to do this since the beacon monitor does not
push back the connection monitor by design so even if we
are getting beacons from these type of APs our connection
monitor currently relies heavily on the way the probe
requests are received on the AP. An example of an AP
affected by this is the Nexus One, but this has also been
observed with random APs.

We can probably optimize this later by using null funcs
instead of probe requests.

For more details refer to:

http://code.google.com/p/chromium-os/issues/detail?id=5715

This patch has fixes for stable kernels [2.6.35+].

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 net/mac80211/mlme.c |   13 +++++++++++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index c2e1838..816566b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -1038,10 +1038,19 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
 {
 	struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
 	const u8 *ssid;
+	u8 *dst = ifmgd->associated->bssid;
+	u8 unicast_limit = max(1, IEEE80211_MAX_PROBE_TRIES - 3);
+
+	/*
+	 * Try sending broadcast probe requests for the last three
+	 * probe requests after the first ones failed since some
+	 * buggy APs only support broadcast probe requests.
+	 */
+	if (ifmgd->probe_send_count >= unicast_limit)
+		dst = NULL;
 
 	ssid = ieee80211_bss_get_ie(ifmgd->associated, WLAN_EID_SSID);
-	ieee80211_send_probe_req(sdata, ifmgd->associated->bssid,
-				 ssid + 2, ssid[1], NULL, 0);
+	ieee80211_send_probe_req(sdata, dst, ssid + 2, ssid[1], NULL, 0);
 
 	ifmgd->probe_send_count++;
 	ifmgd->probe_timeout = jiffies + IEEE80211_PROBE_WAIT;
-- 
1.7.0.4

[PATCH v3 10/11] ath9k: fix regression which prevents chip sleep after CAB data

[Luis R. Rodriguez]

From: Senthil Balasubramanian <senthilkumar@atheros.com>

The patch:

commit 293dc5dfdbcc16cde06e40a688394cc8ab083e48
Author: Gabor Juhos <juhosg@openwrt.org>
Date:   Fri Jun 19 12:17:48 2009 +0200

    ath9k: remove ath_rx_ps_back_to_sleep helper

    This helper only clears the SC_OP_WAIT_FOR_{BEACON,CAB} flags.
    Remove it and clear these flags directly in the approptiate
    places instead.

    Changes-licensed-under: ISC
    Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

introduced a regression which forgot to lift the beacon flag
after we received all broadcast and multicast data. This meant
we never went to sleep consuming about ~650mW on idle. This pretty
much broke power save completely.

This patch has fixes for stable kernels [2.6.32+].

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Sameer Nanda <snanda@google.com>
Cc: Gabor Juhos <juhosg@openwrt.org>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/recv.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index efd0651..dbd4b0c 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -639,7 +639,7 @@ static void ath_rx_ps(struct ath_softc *sc, struct sk_buff *skb)
 		 * No more broadcast/multicast frames to be received at this
 		 * point.
 		 */
-		sc->ps_flags &= ~PS_WAIT_FOR_CAB;
+		sc->ps_flags &= ~(PS_WAIT_FOR_CAB | PS_WAIT_FOR_BEACON);
 		ath_print(common, ATH_DBG_PS,
 			  "All PS CAB frames received, back to sleep\n");
 	} else if ((sc->ps_flags & PS_WAIT_FOR_PSPOLL_DATA) &&
-- 
1.7.0.4

[PATCH v3 11/11] ath9k: fix regression which disabled ps on ath9k

[Luis R. Rodriguez]

The patch titled "ath9k: Add new file init.c" shuffled some code
around but in dong so for some reason also removed the revision
check for disablign power save. Add this revision check again
so we can get power save re-enabled again by default on cards
newer than AR5416 and AR5418.

$ git describe --contains 556242049cc3992d0ee625e9f15c4b00ea4baac8
v2.6.34-rc1~233^2~49^2~343

This patch has fixes for stable kernels [2.6.34+].

Cc: stable@kernel.org
Cc: Paul Stewart <pstew@google.com>
Cc: Amod Bodas <amod.bodas@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
 drivers/net/wireless/ath/ath9k/init.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 5c77a99..6e11147 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -643,7 +643,8 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
 		BIT(NL80211_IFTYPE_ADHOC) |
 		BIT(NL80211_IFTYPE_MESH_POINT);
 
-	hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
+	if (AR_SREV_5416(sc->sc_ah))
+		hw->wiphy->flags &= ~WIPHY_FLAG_PS_ON_BY_DEFAULT;
 
 	hw->queues = 4;
 	hw->max_rates = 4;
-- 
1.7.0.4

Re: [PATCH v3 00/11] ath9k / mac80211: power save fixes

[Luis R. Rodriguez]

On Tue, Sep 14, 2010 at 4:40 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> I reordered the patches, enhanced the commit log entries and
> and added a new patch to address ANI / the TX monitor, figured I'd just
> send a new series just to be clear.
>
> My next peet peeve is this:
>
> Sep 14 16:36:02 tux kernel: [ 1369.000106] ath: Set channel: 5220 MHz
> Sep 14 16:36:02 tux kernel: [ 1369.000116] ath: tx chmask: 3, rx chmask: 3
> Sep 14 16:36:02 tux kernel: [ 1369.000240] ath: (2412 MHz) -> (5220 MHz), conf_is_ht40: 0
> Sep 14 16:36:02 tux kernel: [ 1369.063449] ath: Set channel: 2412 MHz
> Sep 14 16:36:03 tux kernel: [ 1369.063459] ath: tx chmask: 3, rx chmask: 3
> Sep 14 16:36:03 tux kernel: [ 1369.063584] ath: (5220 MHz) -> (2412 MHz), conf_is_ht40: 0
> Sep 14 16:36:03 tux kernel: [ 1369.360111] ath: Set channel: 5240 MHz
> Sep 14 16:36:03 tux kernel: [ 1369.360120] ath: tx chmask: 3, rx chmask: 3
> Sep 14 16:36:03 tux kernel: [ 1369.360245] ath: (2412 MHz) -> (5240 MHz), conf_is_ht40: 0
> Sep 14 16:36:03 tux kernel: [ 1369.422736] ath: Set channel: 2412 MHz
> Sep 14 16:36:03 tux kernel: [ 1369.422745] ath: tx chmask: 3, rx chmask: 3
> Sep 14 16:36:03 tux kernel: [ 1369.422867] ath: (5240 MHz) -> (2412 MHz), conf_is_ht40: 0
> Sep 14 16:36:03 tux kernel: [ 1369.564685] __ratelimit: 81 callbacks suppressed
> Sep 14 16:36:03 tux kernel: [ 1369.564692] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564698] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564703] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564708] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564713] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564718] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564723] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564728] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564733] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.564738] phy0: release an RX reorder frame due to timeout on earlier frames
> Sep 14 16:36:03 tux kernel: [ 1369.720129] ath: Set channel: 5260 MHz
> Sep 14 16:36:03 tux kernel: [ 1369.720139] ath: tx chmask: 3, rx chmask: 3
> Sep 14 16:36:03 tux kernel: [ 1369.720263] ath: (2412 MHz) -> (5260 MHz), conf_is_ht40: 0
>
> My guess is we are not suspending / stopping the aggregations sessions /
> or simply extending the timer when going off channel.
>
> Luis R. Rodriguez (10):
>  ath9k: fix power save race conditions
>  ath9k: fix regression on beacon loss after bgscan
>  ath9k: fix enabling ANI / tx monitor after bg scan
>  mac80211: add helper for reseting the connection monitor
>  mac80211: reset probe send counter upon connection timer reset
>  mac80211: reset connection idle when going offchannel
>  mac80211: make the beacon monitor available externally
>  mac80211: disable beacon monitor while going offchannel
>  mac80211: send last 3/5 probe requests as unicast
>  ath9k: fix regression which disabled ps on ath9k
>
> Senthil Balasubramanian (1):
>  ath9k: fix regression which prevents chip sleep after CAB data
>
>  drivers/net/wireless/ath/ath9k/ath9k.h |    1 -
>  drivers/net/wireless/ath/ath9k/init.c  |    3 +-
>  drivers/net/wireless/ath/ath9k/main.c  |   15 ++++++-----
>  drivers/net/wireless/ath/ath9k/recv.c  |    9 ++++--
>  net/mac80211/ieee80211_i.h             |    2 +
>  net/mac80211/mlme.c                    |   40 +++++++++++++++++++++++--------
>  net/mac80211/offchannel.c              |    7 +++++
>  7 files changed, 54 insertions(+), 23 deletions(-)

The respective stable patches are now backported to each kernel to
which they apply to. To make life easier for stable maintenance you
can just download the backported patches. I have put an all-in-one
git-am-able file and also split up. I should note that we also had
some CTL fixes pending merge. I've updated the wiki to help keep track
of what is pending merge:

http://wireless.kernel.org/en/developers/stable-pending

If you are a distribution waiting consumption you can either start
testing these patches or wait until Linus applies to his tree as that
is what is required for the patches to trickle down to the other older
stable series. The commit ID from Linus' tree is required so that the
patches can be applied to older kernels.

Although I provide the links above, you can download the pending stuff from:

http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2010/08/
http://www.kernel.org/pub/linux/kernel/people/mcgrof/patches/ath9k/2010/09/14/

  Luis

Re: [PATCH v3 00/11] ath9k / mac80211: power save fixes

[Luis R. Rodriguez]

Taking this thread public for further review and comments.

On Wed, Sep 15, 2010 at 06:33:19AM -0700, Matt Smith wrote:
> Luis,
> 
> Not sure what is meant by "block them".... Are you saying should we
> pause the reordering buffer timeout? 

Yes, that or we simply cancel our existing BAs and reject future
ones until we get back to the home channel. I wonder what is easier
and less bug prone.

> I think we should, as there could be some holes in the
> reordering buffer and it's not fair to time them out and drop
> the packet if we go off-channel.

This was what I was thinking, just was not sure what approach
would be more suitable, either to pause the timers for reorderign
or simply stopping BAs completely until we come back to the
home channel.

> That said, most scans will wait until the medium is idle (~ 200ms),
> so we shouldn't have any holes in the reordering buffer at that time.

In mac80211 right now we do not wait until the medium is idle.
We were reviewing what we should do at the wireless summit in San Francisco
last week. Sam Leffler noted he thought it would be good we simply
defer going offchannel until the medium is idle but my concern is
if we have a constant stream of data, how long would we defer scanning,
and what decision do we use to start scan despite a data stream being
transmitted. There was also some suggestion of using a force scan request
which would not wait for the medium to be idle, this would be more
instrusive.

I do not believe we had any consenus on the approach we should take,
unless others were able to pick something up that I did not. So I'd like
to take the opprortunity now that you mentioned it to talk about it with
you as well. Any recommendations for best strategy for this?

I should note what we end up deciding for both aggregation and scan logic
would also affect how we deal with WiFi direct offchannel operation (ah,
we can talk about WiFi Direct publicly now :))

  Luis

> Matt
> 
> On Sep 14, 2010, at 5:09 PM, Luis R. Rodriguez wrote:
> 
> > Matt,
> > 
> > mac80211 uses a queue to stuff MPDUs from an AMPDUs since we can
> > receive them out of order. We have a timer on these and nuke 'em after
> > it expires. When we're associated and we hit a scan trigger due to
> > RSSI or a desire to go offchannel (WiFi Direct), what do you recommend
> > we do when we go off channel? Should we stop all aggregation sessions
> > and block them until back on our home channel?
> > 
> >  Luis
> > 
> > ---------- Forwarded message ----------
> > From: Luis R. Rodriguez <lrodriguez@atheros.com>
> > Date: Tue, Sep 14, 2010 at 4:40 PM
> > Subject: [PATCH v3 00/11] ath9k / mac80211: power save fixes
> > To: linville@tuxdriver.com
> > Cc: linux-wireless@vger.kernel.org, "Luis R. Rodriguez" <lrodriguez@atheros.com>
> > 
> > 
> > I reordered the patches, enhanced the commit log entries and
> > and added a new patch to address ANI / the TX monitor, figured I'd just
> > send a new series just to be clear.
> > 
> > My next peet peeve is this:
> > 
> > Sep 14 16:36:02 tux kernel: [ 1369.000106] ath: Set channel: 5220 MHz
> > Sep 14 16:36:02 tux kernel: [ 1369.000116] ath: tx chmask: 3, rx chmask: 3
> > Sep 14 16:36:02 tux kernel: [ 1369.000240] ath: (2412 MHz) -> (5220
> > MHz), conf_is_ht40: 0
> > Sep 14 16:36:02 tux kernel: [ 1369.063449] ath: Set channel: 2412 MHz
> > Sep 14 16:36:03 tux kernel: [ 1369.063459] ath: tx chmask: 3, rx chmask: 3
> > Sep 14 16:36:03 tux kernel: [ 1369.063584] ath: (5220 MHz) -> (2412
> > MHz), conf_is_ht40: 0
> > Sep 14 16:36:03 tux kernel: [ 1369.360111] ath: Set channel: 5240 MHz
> > Sep 14 16:36:03 tux kernel: [ 1369.360120] ath: tx chmask: 3, rx chmask: 3
> > Sep 14 16:36:03 tux kernel: [ 1369.360245] ath: (2412 MHz) -> (5240
> > MHz), conf_is_ht40: 0
> > Sep 14 16:36:03 tux kernel: [ 1369.422736] ath: Set channel: 2412 MHz
> > Sep 14 16:36:03 tux kernel: [ 1369.422745] ath: tx chmask: 3, rx chmask: 3
> > Sep 14 16:36:03 tux kernel: [ 1369.422867] ath: (5240 MHz) -> (2412
> > MHz), conf_is_ht40: 0
> > Sep 14 16:36:03 tux kernel: [ 1369.564685] __ratelimit: 81 callbacks suppressed
> > Sep 14 16:36:03 tux kernel: [ 1369.564692] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564698] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564703] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564708] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564713] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564718] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564723] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564728] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564733] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.564738] phy0: release an RX reorder
> > frame due to timeout on earlier frames
> > Sep 14 16:36:03 tux kernel: [ 1369.720129] ath: Set channel: 5260 MHz
> > Sep 14 16:36:03 tux kernel: [ 1369.720139] ath: tx chmask: 3, rx chmask: 3
> > Sep 14 16:36:03 tux kernel: [ 1369.720263] ath: (2412 MHz) -> (5260
> > MHz), conf_is_ht40: 0
> > 
> > My guess is we are not suspending / stopping the aggregations sessions /
> > or simply extending the timer when going off channel.
> > 
> > Luis R. Rodriguez (10):
> >  ath9k: fix power save race conditions
> >  ath9k: fix regression on beacon loss after bgscan
> >  ath9k: fix enabling ANI / tx monitor after bg scan
> >  mac80211: add helper for reseting the connection monitor
> >  mac80211: reset probe send counter upon connection timer reset
> >  mac80211: reset connection idle when going offchannel
> >  mac80211: make the beacon monitor available externally
> >  mac80211: disable beacon monitor while going offchannel
> >  mac80211: send last 3/5 probe requests as unicast
> >  ath9k: fix regression which disabled ps on ath9k
> > 
> > Senthil Balasubramanian (1):
> >  ath9k: fix regression which prevents chip sleep after CAB data
> > 
> >  drivers/net/wireless/ath/ath9k/ath9k.h |    1 -
> >  drivers/net/wireless/ath/ath9k/init.c  |    3 +-
> >  drivers/net/wireless/ath/ath9k/main.c  |   15 ++++++-----
> >  drivers/net/wireless/ath/ath9k/recv.c  |    9 ++++--
> >  net/mac80211/ieee80211_i.h             |    2 +
> >  net/mac80211/mlme.c                    |   40 +++++++++++++++++++++++--------
> >  net/mac80211/offchannel.c              |    7 +++++
> >  7 files changed, 54 insertions(+), 23 deletions(-)
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
>