[ath9k-devel] extreme latency, regression in 3.13.7

[ath9k-devel] extreme latency, regression in 3.13.7

[Balogh Maria]

Hi,

I bisected a regression in ath9k and ended up at this commit:
179c5b22373511b9e8f73183f03d89e92278ab3e
(558ff225de80ac95b132d3a115ddadcd64498b4f upstream): "ath9k: fix ps-poll
responses under a-mpdu sessions"

My Sparklan WPEA-127N card (168c:0030), which works in 802.11n AP mode with
hostapd, works with extreme latencies after this commit and becomes
absolutely unusable.

Oddly enough, this commit is supposed to fix high latencies, but I haven't
seen problems before this.

I'd be happy to help in further investigation.

Thanks, Jozsef

[ath9k-devel] extreme latency, regression in 3.13.7

[Felix Fietkau]

On 2014-04-19 10:28, Balogh Maria wrote:
> Hi,
> 
> I bisected a regression in ath9k and ended up at this commit:
> 179c5b22373511b9e8f73183f03d89e92278ab3e
> (558ff225de80ac95b132d3a115ddadcd64498b4f upstream): "ath9k: fix ps-poll
> responses under a-mpdu sessions"
> 
> My Sparklan WPEA-127N card (168c:0030), which works in 802.11n AP mode with
> hostapd, works with extreme latencies after this commit and becomes
> absolutely unusable.
> 
> Oddly enough, this commit is supposed to fix high latencies, but I haven't
> seen problems before this.
> 
> I'd be happy to help in further investigation.
Please try applying this commit to your tree (if you don't have it already)


commit 5998be879719384af2014b79697eed6e38ee2706
Author: Helmut Schaa <helmut.schaa@googlemail.com>
Date:   Wed Mar 12 10:37:55 2014 +0100

    ath9k: Fix sequence number assignment for non-data frames
    
    Since commit 558ff225de80ac95b132d3a115ddadcd64498b4f (ath9k: fix
    ps-poll responses under a-mpdu sessions) non-data frames would have
    gotten a sequence number from a TIDs sequence counter instead of
    using the global sequence counter.
    
    This can lead to instable connections.
    
    To fix this only select the correct TID if we are processing a
    data frame. Furthermore, prevent non-data frames to get a sequence
    number from a TID sequence counter by adding a check to
    ath_tx_setup_buffer.
    
    Cc: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
    Acked-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index f042a18..55897d5 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -2063,7 +2063,7 @@ static struct ath_buf *ath_tx_setup_buffer(struct ath_softc *sc,
 
 	ATH_TXBUF_RESET(bf);
 
-	if (tid) {
+	if (tid && ieee80211_is_data_present(hdr->frame_control)) {
 		fragno = le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG;
 		seqno = tid->seq_next;
 		hdr->seq_ctrl = cpu_to_le16(tid->seq_next << IEEE80211_SEQ_SEQ_SHIFT);
@@ -2186,7 +2186,7 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
 		txq->stopped = true;
 	}
 
-	if (txctl->an)
+	if (txctl->an && ieee80211_is_data_present(hdr->frame_control))
 		tid = ath_get_skb_tid(sc, txctl->an, skb);
 
 	if (info->flags & IEEE80211_TX_CTL_PS_RESPONSE) {

[ath9k-devel] extreme latency, regression in 3.13.7

[Fejes József]

>> I bisected a regression in ath9k and ended up at this commit:
>> 179c5b22373511b9e8f73183f03d89e92278ab3e
>> (558ff225de80ac95b132d3a115ddadcd64498b4f upstream): "ath9k: fix ps-poll
>> responses under a-mpdu sessions"
>>
>> My Sparklan WPEA-127N card (168c:0030), which works in 802.11n AP mode with
>> hostapd, works with extreme latencies after this commit and becomes
>> absolutely unusable.
>>
>> Oddly enough, this commit is supposed to fix high latencies, but I haven't
>> seen problems before this.
>>
>> I'd be happy to help in further investigation.
> Please try applying this commit to your tree (if you don't have it already)
>
>
> commit 5998be879719384af2014b79697eed6e38ee2706

Hi,

(My sender name got mixed up in the previous mail)

Thanks, it fixed the issue. I booted a clean 3.13.10, and the problem
was there. Then I cherry-picked this one commit, and it's working
again. Can you please push it to 3.13.11?

Thanks, Jozsef