Jake, please test this set and check if it not cause association
problems you reported earlier this month.
Please apply it together with this mac80211 patch:
http://marc.info/?l=linux-wireless&m=136879090123023&w=2
which I already posted and is queued to upstream. Not having
it may cause troubles and influence negatively this set test.
Johannes, is need to check beacon bssid or even if rx frame
is a beacon to unblock queues? I think if we receive any frame
(not necessary beacon or our bssid beacon) on passive channel,
that mean we can use that channel. But that depend how firmware
is implemented, if firmware require our bssid beacon to unblock
channel, driver of course need that too.
Stanislaw Gruszka (4):
iwlegacy: small refactoring of il_{stop,wake}_queue
iwlegacy: add il_{stop,wake}_queues_by_reason functions
iwlegacy: workaround for firmware frame tx rejection
Revert "iwl4965: workaround connection regression on passive channel"
drivers/net/wireless/iwlegacy/4965-mac.c | 22 ++++++++++++++++-
drivers/net/wireless/iwlegacy/common.c | 10 ++++++++
drivers/net/wireless/iwlegacy/common.h | 41 ++++++++++++++++++++++++++++----
3 files changed, 68 insertions(+), 5 deletions(-)
--
1.7.11.7
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/iwlegacy/common.h | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index f8246f2..c6956ea 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -2257,6 +2257,19 @@ il_set_swq_id(struct il_tx_queue *txq, u8 ac, u8 hwq)
}
static inline void
+_il_wake_queue(struct il_priv *il, u8 ac)
+{
+ if (atomic_dec_return(&il->queue_stop_count[ac]) <= 0)
+ ieee80211_wake_queue(il->hw, ac);
+}
+
+static inline void
+_il_stop_queue(struct il_priv *il, u8 ac)
+{
+ if (atomic_inc_return(&il->queue_stop_count[ac]) > 0)
+ ieee80211_stop_queue(il->hw, ac);
+}
+static inline void
il_wake_queue(struct il_priv *il, struct il_tx_queue *txq)
{
u8 queue = txq->swq_id;
@@ -2264,8 +2277,7 @@ il_wake_queue(struct il_priv *il, struct il_tx_queue *txq)
u8 hwq = (queue >> 2) & 0x1f;
if (test_and_clear_bit(hwq, il->queue_stopped))
- if (atomic_dec_return(&il->queue_stop_count[ac]) <= 0)
- ieee80211_wake_queue(il->hw, ac);
+ _il_wake_queue(il, ac);
}
static inline void
@@ -2276,8 +2288,7 @@ il_stop_queue(struct il_priv *il, struct il_tx_queue *txq)
u8 hwq = (queue >> 2) & 0x1f;
if (!test_and_set_bit(hwq, il->queue_stopped))
- if (atomic_inc_return(&il->queue_stop_count[ac]) > 0)
- ieee80211_stop_queue(il->hw, ac);
+ _il_stop_queue(il, ac);
}
#ifdef ieee80211_stop_queue
--
1.7.11.7
On Thu, 23 May 2013 14:20:56 +0200 Stanislaw Gruszka wrote:
> Jake, please test this set and check if it not cause association
> problems you reported earlier this month.
I won't be able to get to this for 10 days or so ... I just got to
Japan, so the AP in question is thousands of miles east :)
maybe they will use passive channel(s) at LinuxCon Japan on the
wireless? Not sure, but if I can figure that out, I'll try out the
code ...
jake
--
Jake Edge - LWN - [email protected] - http://lwn.net
This reverts commit dd9c46408fdc07098333655ff27edf8cac8d9fcf.
---
drivers/net/wireless/iwlegacy/4965-mac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index 72b8c4e..b083502 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -5760,7 +5760,8 @@ il4965_mac_setup_register(struct il_priv *il, u32 max_probe_length)
hw->flags =
IEEE80211_HW_SIGNAL_DBM | IEEE80211_HW_AMPDU_AGGREGATION |
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC | IEEE80211_HW_SPECTRUM_MGMT |
- IEEE80211_HW_SUPPORTS_PS | IEEE80211_HW_SUPPORTS_DYNAMIC_PS;
+ IEEE80211_HW_REPORTS_TX_ACK_STATUS | IEEE80211_HW_SUPPORTS_PS |
+ IEEE80211_HW_SUPPORTS_DYNAMIC_PS;
if (il->cfg->sku & IL_SKU_N)
hw->flags |=
IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS |
--
1.7.11.7
On Thu, 2013-05-23 at 14:20 +0200, Stanislaw Gruszka wrote:
> Jake, please test this set and check if it not cause association
> problems you reported earlier this month.
>
> Please apply it together with this mac80211 patch:
> http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> which I already posted and is queued to upstream. Not having
> it may cause troubles and influence negatively this set test.
>
> Johannes, is need to check beacon bssid or even if rx frame
> is a beacon to unblock queues? I think if we receive any frame
> (not necessary beacon or our bssid beacon) on passive channel,
> that mean we can use that channel. But that depend how firmware
> is implemented, if firmware require our bssid beacon to unblock
> channel, driver of course need that too.
I _think_ any frame with good CRC will do, but I'm not entirely sure for
3945/4965.
johannes
Add functions that will stop/wake all queues. Make them safe
regarding multiple calls and when some ac are stopped/woke
independently.
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/iwlegacy/common.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index c6956ea..3c9143e 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1299,6 +1299,8 @@ struct il_priv {
/* queue refcounts */
#define IL_MAX_HW_QUEUES 32
unsigned long queue_stopped[BITS_TO_LONGS(IL_MAX_HW_QUEUES)];
+#define IL_STOP_REASON_PASSIVE 0
+ unsigned long stop_reason;
/* for each AC */
atomic_t queue_stop_count[4];
@@ -2291,6 +2293,26 @@ il_stop_queue(struct il_priv *il, struct il_tx_queue *txq)
_il_stop_queue(il, ac);
}
+static inline void
+il_wake_queues_by_reason(struct il_priv *il, int reason)
+{
+ u8 ac;
+
+ if (test_and_clear_bit(reason, &il->stop_reason))
+ for (ac = 0; ac < 4; ac++)
+ _il_wake_queue(il, ac);
+}
+
+static inline void
+il_stop_queues_by_reason(struct il_priv *il, int reason)
+{
+ u8 ac;
+
+ if (!test_and_set_bit(reason, &il->stop_reason))
+ for (ac = 0; ac < 4; ac++)
+ _il_stop_queue(il, ac);
+}
+
#ifdef ieee80211_stop_queue
#undef ieee80211_stop_queue
#endif
--
1.7.11.7
Firmware can reject to transmit frame on passive channel, when it
did not yet received any beacon on that channel. Workaround this
problem in the driver.
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/iwlegacy/4965-mac.c | 19 +++++++++++++++++++
drivers/net/wireless/iwlegacy/common.c | 10 ++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index 9a95045..72b8c4e 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -588,6 +588,13 @@ il4965_pass_packet_to_mac80211(struct il_priv *il, struct ieee80211_hdr *hdr,
return;
}
+ if (unlikely(test_bit(IL_STOP_REASON_PASSIVE, &il->stop_reason)) &&
+ ieee80211_is_beacon(fc) &&
+ ether_addr_equal(hdr->addr3, il->active.bssid_addr)) {
+ il_wake_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
+ D_INFO("Woke queues - beacon received on passive channel\n");
+ }
+
/* In case of HW accelerated crypto and bad decryption, drop */
if (!il->cfg->mod_params->sw_crypto &&
il_set_decrypted_flag(il, hdr, ampdu_status, stats))
@@ -2806,6 +2813,18 @@ il4965_hdl_tx(struct il_priv *il, struct il_rx_buf *rxb)
return;
}
+ /*
+ * Firmware will not transmit frame on passive channel, if it not yet
+ * received beacon frame on that channel. When this error happen, we
+ * have to wait until firmware will unblock itself i.e. when we note
+ * received beacon (see il4965_pass_packet_to_mac80211).
+ */
+ if (unlikely(status == TX_STATUS_FAIL_PASSIVE_NO_RX) &&
+ il->iw_mode == NL80211_IFTYPE_STATION) {
+ il_stop_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
+ D_INFO("Stopped queues - RX waiting on passive channel\n");
+ }
+
spin_lock_irqsave(&il->sta_lock, flags);
if (txq->sched_retry) {
const u32 scd_ssn = il4965_get_scd_ssn(tx_resp);
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index e9a3cbc..9360d1f 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -5307,6 +5307,16 @@ il_mac_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
D_MAC80211("BSSID %pM\n", bss_conf->bssid);
/*
+ * On passive channel we wait with blocked queues for a beacon.
+ * If beacon will not be received (what is very unlikely, but
+ * theoretically possible), mac80211 associate procedure will
+ * time out and mac80211 will call us with NULL bssid. We have
+ * to unblock queues on such condition.
+ */
+ if (is_zero_ether_addr(bss_conf->bssid))
+ il_wake_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
+
+ /*
* If there is currently a HW scan going on in the background,
* then we need to cancel it, otherwise sometimes we are not
* able to authenticate (FIXME: why ?)
--
1.7.11.7
On Fri, May 24, 2013 at 05:18:46PM -0600, Jake Edge wrote:
> On Thu, 23 May 2013 14:20:56 +0200 Stanislaw Gruszka wrote:
> > Jake, please test this set and check if it not cause association
> > problems you reported earlier this month.
>
> I won't be able to get to this for 10 days or so ... I just got to
> Japan, so the AP in question is thousands of miles east :)
No problem, it doesn't have to be fast. I plan to post patches to
-next (i.e. 3.11), since we have simpler workaround already applied.
Thanks
Stanislaw
Currently we unblock queues (when blocked on passive channel) only if
beacon with our bssid will be received. Change that to any frame, since
firmware should allow to transmit frames on passive channel when it
receives any frame with valid CRC sum.
Signed-off-by: Stanislaw Gruszka <[email protected]>
---
drivers/net/wireless/iwlegacy/4965-mac.c | 13 ++++++-------
drivers/net/wireless/iwlegacy/common.c | 11 ++++++-----
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index b083502..2c77431 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -588,11 +588,9 @@ il4965_pass_packet_to_mac80211(struct il_priv *il, struct ieee80211_hdr *hdr,
return;
}
- if (unlikely(test_bit(IL_STOP_REASON_PASSIVE, &il->stop_reason)) &&
- ieee80211_is_beacon(fc) &&
- ether_addr_equal(hdr->addr3, il->active.bssid_addr)) {
+ if (unlikely(test_bit(IL_STOP_REASON_PASSIVE, &il->stop_reason))) {
il_wake_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
- D_INFO("Woke queues - beacon received on passive channel\n");
+ D_INFO("Woke queues - frame received on passive channel\n");
}
/* In case of HW accelerated crypto and bad decryption, drop */
@@ -2815,9 +2813,10 @@ il4965_hdl_tx(struct il_priv *il, struct il_rx_buf *rxb)
/*
* Firmware will not transmit frame on passive channel, if it not yet
- * received beacon frame on that channel. When this error happen, we
- * have to wait until firmware will unblock itself i.e. when we note
- * received beacon (see il4965_pass_packet_to_mac80211).
+ * received some valid frame on that channel. When this error happen
+ * we have to wait until firmware will unblock itself i.e. when we
+ * note received beacon or other frame. We unblock queues in
+ * il4965_pass_packet_to_mac80211 or in il_mac_bss_info_changed.
*/
if (unlikely(status == TX_STATUS_FAIL_PASSIVE_NO_RX) &&
il->iw_mode == NL80211_IFTYPE_STATION) {
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index 9360d1f..3195aad 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -5307,11 +5307,12 @@ il_mac_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
D_MAC80211("BSSID %pM\n", bss_conf->bssid);
/*
- * On passive channel we wait with blocked queues for a beacon.
- * If beacon will not be received (what is very unlikely, but
- * theoretically possible), mac80211 associate procedure will
- * time out and mac80211 will call us with NULL bssid. We have
- * to unblock queues on such condition.
+ * On passive channel we wait with blocked queues to see if
+ * there is traffic on that channel. If no frame will be
+ * received (what is very unlikely since scan detects AP on
+ * that channel, but theoretically possible), mac80211 associate
+ * procedure will time out and mac80211 will call us with NULL
+ * bssid. We have to unblock queues on such condition.
*/
if (is_zero_ether_addr(bss_conf->bssid))
il_wake_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
--
1.7.11.7
On Fri, May 24, 2013 at 10:26:48PM +0200, Johannes Berg wrote:
> On Thu, 2013-05-23 at 14:20 +0200, Stanislaw Gruszka wrote:
> > Jake, please test this set and check if it not cause association
> > problems you reported earlier this month.
> >
> > Please apply it together with this mac80211 patch:
> > http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> > which I already posted and is queued to upstream. Not having
> > it may cause troubles and influence negatively this set test.
> >
> > Johannes, is need to check beacon bssid or even if rx frame
> > is a beacon to unblock queues? I think if we receive any frame
> > (not necessary beacon or our bssid beacon) on passive channel,
> > that mean we can use that channel. But that depend how firmware
> > is implemented, if firmware require our bssid beacon to unblock
> > channel, driver of course need that too.
>
> I _think_ any frame with good CRC will do, but I'm not entirely sure for
> 3945/4965.
I prefer to unblock queues on any frame, as this allow to start
operating quickly. Let's see if this will also work on Jake environment,
I'll add patch 5/4 which implement that.
Stanislaw
On Tue, Jun 11, 2013 at 01:17:04PM -0600, Jake Edge wrote:
> looks like a good a set of patches for 3.11, though I imagine stable
> will stick with the other workaround ...
I plan to post them to -next. Thanks for testing!
Stanislaw
On Mon, 10 Jun 2013 14:38:48 -0600 Jake Edge wrote:
> > Please apply it together with this mac80211 patch:
> > http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> > which I already posted and is queued to upstream. Not having
> > it may cause troubles and influence negatively this set test.
>
> I tried it on both 3.9 (without 4/4 since it doesn't have that
> workaround in it) and on 3.10-rc4 and in both cases, i get the same
> behavior: it tries to connect many times and fails, then eventually
> connects (after like 20 tries from KDE network manager) ...
actually, i spoke too soon, the 3.10-rc4 has not been able to connect
at all, after many hours of trying. I manually went in and selected
the other 2.4GHz SSID (rather than the 5GHz it had been trying) and it
connected right away, fwiw ...
jake
--
Jake Edge - LWN - [email protected] - http://lwn.net
On Thu, 23 May 2013 14:20:56 +0200 Stanislaw Gruszka wrote:
> Jake, please test this set and check if it not cause association
> problems you reported earlier this month.
sorry it took me so long to get back to this, but i just tested and it
doesn't fix the problem here ...
> Please apply it together with this mac80211 patch:
> http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> which I already posted and is queued to upstream. Not having
> it may cause troubles and influence negatively this set test.
I tried it on both 3.9 (without 4/4 since it doesn't have that
workaround in it) and on 3.10-rc4 and in both cases, i get the same
behavior: it tries to connect many times and fails, then eventually
connects (after like 20 tries from KDE network manager) ...
jake
--
Jake Edge - LWN - [email protected] - http://lwn.net
On Mon, Jun 10, 2013 at 09:41:34PM -0600, Jake Edge wrote:
> On Mon, 10 Jun 2013 14:38:48 -0600 Jake Edge wrote:
>
> > > Please apply it together with this mac80211 patch:
> > > http://marc.info/?l=linux-wireless&m=136879090123023&w=2
> > > which I already posted and is queued to upstream. Not having
> > > it may cause troubles and influence negatively this set test.
> >
> > I tried it on both 3.9 (without 4/4 since it doesn't have that
> > workaround in it) and on 3.10-rc4 and in both cases, i get the same
> > behavior: it tries to connect many times and fails, then eventually
> > connects (after like 20 tries from KDE network manager) ...
>
> actually, i spoke too soon, the 3.10-rc4 has not been able to connect
> at all, after many hours of trying. I manually went in and selected
> the other 2.4GHz SSID (rather than the 5GHz it had been trying) and it
> connected right away, fwiw ...
I found a bug in one patch, perhaps it is a reason of failure.
Please apply patch 5/4 from here:
http://marc.info/?l=linux-wireless&m=136947199729148&q=raw
and patch from the end of this email, which fix the bug.
Could you also recheck that "mac80211: fix direct probe auth" patch
is applied, note that it is included in 3.10-rc5 as commit
6211dd12da609bc6893b9c3182630b494737ec4b
If it still will not help, please provide dmesg with debug messages
gathered by following instructions:
dmesg -c
modprobe -r iwl4965
modprobe iwl4965 debug=0x00800001
# wait about 30 seconds until first connection try fail
modprobe -r iwl4965
dmesg > dmesg.txt
Kernel has to be compiled with CONFIG_IWLEGACY_DEBUG=y to print debug
messages.
Thanks
Stanislaw
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index 2c77431..d287fd2 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -2818,7 +2818,7 @@ il4965_hdl_tx(struct il_priv *il, struct il_rx_buf *rxb)
* note received beacon or other frame. We unblock queues in
* il4965_pass_packet_to_mac80211 or in il_mac_bss_info_changed.
*/
- if (unlikely(status == TX_STATUS_FAIL_PASSIVE_NO_RX) &&
+ if (unlikely((status & TX_STATUS_MSK) == TX_STATUS_FAIL_PASSIVE_NO_RX) &&
il->iw_mode == NL80211_IFTYPE_STATION) {
il_stop_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
D_INFO("Stopped queues - RX waiting on passive channel\n");
On Tue, 11 Jun 2013 18:09:50 +0200 Stanislaw Gruszka wrote:
> I found a bug in one patch, perhaps it is a reason of failure.
> Please apply patch 5/4 from here:
> http://marc.info/?l=linux-wireless&m=136947199729148&q=raw
> and patch from the end of this email, which fix the bug.
>
> Could you also recheck that "mac80211: fix direct probe auth" patch
> is applied, note that it is included in 3.10-rc5 as commit
> 6211dd12da609bc6893b9c3182630b494737ec4b
yes, that mac80211 patch was applied to both 3.9 and 3.10-rc4 ... but I
just built 3.10-rc5 (and confirmed that it does have that patch) with
the 4 previous patches plus the new one above and my system connected
just fine ... i switched back and forth a few times and all seems
well ...
looks like a good a set of patches for 3.11, though I imagine stable
will stick with the other workaround ...
thanks!
jake
--
Jake Edge - LWN - [email protected] - http://lwn.net