ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Michael Leun]

Hi,

ne-wlan1@elektra:/home/ml4> ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2010 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1011 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=11.5 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.12 ms
64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1002 ms
64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.83 ms
64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1003 ms
64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=4.10 ms
64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1003 ms
64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.95 ms
64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1003 ms
64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=3.78 ms


Please note the additional delay of ~1000ms every 2nd packet. This is
Kernel 3.4.3, have seen it in 3.4.2 also. Does NOT happen in 3.3.1.

Is this Issue already known? If so, I can save the work bisecting...

Happens with two different ath9k_htc cards:

Bus 002 Device 012: ID 0846:9018 NetGear, Inc. WNDA3200 802.11abgn Wireless Adapter [Atheros AR7010+AR9280]
Bus 002 Device 004: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]

Does NOT happen with an atk9k (mini pci express) card.

-- 
MfG,

Michael Leun

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Mohammed Shafi]

Hi,

On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
<lkml20120218@newton.leun.net> wrote:
> Hi,
>
> ne-wlan1@elektra:/home/ml4> ping 192.168.2.1
> PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2010 ms
> 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1011 ms
> 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=11.5 ms
> 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.12 ms
> 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1002 ms
> 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.83 ms
> 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1003 ms
> 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=4.10 ms
> 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1003 ms
> 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.95 ms
> 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1003 ms
> 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=3.78 ms
>
>
> Please note the additional delay of ~1000ms every 2nd packet. This is
> Kernel 3.4.3, have seen it in 3.4.2 also. Does NOT happen in 3.3.1.
>
> Is this Issue already known? If so, I can save the work bisecting...

looks like some one reported this bug in kernel bugzilla. would be
saving us lot of time
if you can bisect it!

>
> Happens with two different ath9k_htc cards:
>
> Bus 002 Device 012: ID 0846:9018 NetGear, Inc. WNDA3200 802.11abgn Wireless Adapter [Atheros AR7010+AR9280]
> Bus 002 Device 004: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
>
> Does NOT happen with an atk9k (mini pci express) card.

thanks for the info!

>
> --
> MfG,
>
> Michael Leun
>
> --
> 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



-- 
thanks,
shafi

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Michael Leun]

On Tue, 19 Jun 2012 15:11:38 +0530
Mohammed Shafi <shafi.wireless@gmail.com> wrote:

> Hi,
> 
> On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> <lkml20120218@newton.leun.net> wrote:
> > Hi,
> >
> > ne-wlan1@elektra:/home/ml4> ping 192.168.2.1
> > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2010 ms
> > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1011 ms
> > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=11.5 ms
> > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.12 ms
> > 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1002 ms
> > 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.83 ms
> > 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1003 ms
> > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=4.10 ms
> > 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1003 ms
> > 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.95 ms
> > 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1003 ms
> > 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=3.78 ms
> >
> >
> > Please note the additional delay of ~1000ms every 2nd packet. This
> > is Kernel 3.4.3, have seen it in 3.4.2 also. Does NOT happen in
> > 3.3.1.
> >
> > Is this Issue already known? If so, I can save the work bisecting...
> 
> looks like some one reported this bug in kernel bugzilla. would be
> saving us lot of time
> if you can bisect it!
> 

0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 is the first bad commit
commit 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Thu Mar 8 15:02:06 2012 +0100

    mac80211: remove spurious BSSID change flag

    The BSSID has been set a lot earlier already and
    didn't change again in ieee80211_set_associated().

    Signed-off-by: Johannes Berg <johannes.berg@intel.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

:040000 040000 67a19a39e4b04c16921a3758ddd2362e02e81dd3 4a7cbd327b59345b83fa613f893770fbf44220bb M      net

Reverting 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 from 3.4.3 fixes the issue.


-- 
MfG,

Michael Leun

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Rajkumar Manoharan]

On Wed, Jun 20, 2012 at 12:33:15AM +0200, Michael Leun wrote:
> On Tue, 19 Jun 2012 15:11:38 +0530
> Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> 
> > Hi,
> > 
> > On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> > <lkml20120218@newton.leun.net> wrote:
> > > Hi,
> > >
> > > ne-wlan1@elektra:/home/ml4> ping 192.168.2.1
> > > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> > > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2010 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1011 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=11.5 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.12 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1002 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.83 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1003 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=4.10 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1003 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.95 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1003 ms
> > > 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=3.78 ms
> > >
> > >
> > > Please note the additional delay of ~1000ms every 2nd packet. This
> > > is Kernel 3.4.3, have seen it in 3.4.2 also. Does NOT happen in
> > > 3.3.1.
> > >
> > > Is this Issue already known? If so, I can save the work bisecting...
> > 
> > looks like some one reported this bug in kernel bugzilla. would be
> > saving us lot of time
> > if you can bisect it!
> > 
> 
> 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 is the first bad commit
> commit 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Thu Mar 8 15:02:06 2012 +0100
> 
>     mac80211: remove spurious BSSID change flag
> 
>     The BSSID has been set a lot earlier already and
>     didn't change again in ieee80211_set_associated().
> 
>     Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 
> :040000 040000 67a19a39e4b04c16921a3758ddd2362e02e81dd3 4a7cbd327b59345b83fa613f893770fbf44220bb M      net
> 
> Reverting 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 from 3.4.3 fixes the issue.
> 
Michael,

Thanks for the analysis. Can you please try with the attached patch without
reverting mac80211 change?

-Rajkumar

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Michael Leun]

On Wed, 20 Jun 2012 11:43:05 +0530
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote:


> Thanks for the analysis. Can you please try with the attached patch
> without reverting mac80211 change?

Radio Eriwan answers: In principle yes, but you forgot the
attachment ;-)

-- 
MfG,

Michael Leun

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Rajkumar Manoharan]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Wed, Jun 20, 2012 at 08:15:53AM +0200, Michael Leun wrote:
> On Wed, 20 Jun 2012 11:43:05 +0530
> Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote:
> 
> 
> > Thanks for the analysis. Can you please try with the attached patch
> > without reverting mac80211 change?
> 
> Radio Eriwan answers: In principle yes, but you forgot the
> attachment ;-)
> 
Oops. Sorry.  

[-- Attachment #2: 0001-ath9k_htc-configure-bssid-on-ASSOC-IBSS-change.patch --]
[-- Type: text/plain, Size: 1810 bytes --]

>From 025f26a70c1f8bab443a49f0fe3e7c6627e6550c Mon Sep 17 00:00:00 2001
From: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
Date: Wed, 20 Jun 2012 11:33:37 +0530
Subject: [PATCH] ath9k_htc: configure bssid on ASSOC/IBSS change

After the change "mac80211: remove spurious BSSID change flag",
BSS_CHANGED_BSSID will not be passed on association or IBSS
status changes. So it could be better to program bssid on ASSOC
or IBSS change notification. Not doing so, is affecting the
packet transmission.

Reported-by: Michael Leun <lkml20120218@newton.leun.net>
Signed-off-by: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 2b8f61c..abbd6ef 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1496,6 +1496,7 @@ static void ath9k_htc_bss_info_changed(struct ieee80211_hw *hw,
 			priv->num_sta_assoc_vif++ : priv->num_sta_assoc_vif--;
 
 		if (priv->ah->opmode == NL80211_IFTYPE_STATION) {
+			ath9k_htc_choose_set_bssid(priv);
 			if (bss_conf->assoc && (priv->num_sta_assoc_vif == 1))
 				ath9k_htc_start_ani(priv);
 			else if (priv->num_sta_assoc_vif == 0)
@@ -1503,13 +1504,11 @@ static void ath9k_htc_bss_info_changed(struct ieee80211_hw *hw,
 		}
 	}
 
-	if (changed & BSS_CHANGED_BSSID) {
+	if (changed & BSS_CHANGED_IBSS) {
 		if (priv->ah->opmode == NL80211_IFTYPE_ADHOC) {
 			common->curaid = bss_conf->aid;
 			memcpy(common->curbssid, bss_conf->bssid, ETH_ALEN);
 			ath9k_htc_set_bssid(priv);
-		} else if (priv->ah->opmode == NL80211_IFTYPE_STATION) {
-			ath9k_htc_choose_set_bssid(priv);
 		}
 	}
 
-- 
1.7.11

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Michael Leun]

On Wed, 20 Jun 2012 11:43:05 +0530
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote:

> On Wed, Jun 20, 2012 at 12:33:15AM +0200, Michael Leun wrote:
> > On Tue, 19 Jun 2012 15:11:38 +0530
> > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> > 
> > > Hi,
> > > 
> > > On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> > > <lkml20120218@newton.leun.net> wrote:
> > > > Hi,
> > > >
> > > > ne-wlan1@elektra:/home/ml4> ping 192.168.2.1
> > > > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> > > > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2010 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1011 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=11.5 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.12 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1002 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.83 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1003 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=4.10 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1003 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.95 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1003 ms
> > > > 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=3.78 ms
> > > >
> > > >
> > > > Please note the additional delay of ~1000ms every 2nd packet.
> > > > This is Kernel 3.4.3, have seen it in 3.4.2 also. Does NOT
> > > > happen in 3.3.1.
> > > >
> > > > Is this Issue already known? If so, I can save the work
> > > > bisecting...
> > > 
> > > looks like some one reported this bug in kernel bugzilla. would be
> > > saving us lot of time
> > > if you can bisect it!
> > > 
> > 
> > 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 is the first bad commit
> > commit 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45
> > Author: Johannes Berg <johannes.berg@intel.com>
> > Date:   Thu Mar 8 15:02:06 2012 +0100
> > 
> >     mac80211: remove spurious BSSID change flag
> > 
> >     The BSSID has been set a lot earlier already and
> >     didn't change again in ieee80211_set_associated().
> > 
> >     Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> >     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > 
> > :040000 040000 67a19a39e4b04c16921a3758ddd2362e02e81dd3
> > 4a7cbd327b59345b83fa613f893770fbf44220bb M      net
> > 
> > Reverting 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 from 3.4.3 fixes
> > the issue.
> > 
> Michael,
> 
> Thanks for the analysis. Can you please try with the attached patch
> without reverting mac80211 change?

[forgotten attachment was added in later mail]

Yes, that also solves the issue. I guess, you will look into getting
that into mainline and stable asap?

-- 
MfG,

Michael Leun

Re: ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

[Rajkumar Manoharan]

On Wed, Jun 20, 2012 at 08:55:15AM +0200, Michael Leun wrote:
> On Wed, 20 Jun 2012 11:43:05 +0530
> Rajkumar Manoharan <rmanohar@qca.qualcomm.com> wrote:
> 
> > On Wed, Jun 20, 2012 at 12:33:15AM +0200, Michael Leun wrote:
> > > On Tue, 19 Jun 2012 15:11:38 +0530
> > > Mohammed Shafi <shafi.wireless@gmail.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> > > > <lkml20120218@newton.leun.net> wrote:
> > > > > Hi,
> > > > >
> > > > > ne-wlan1@elektra:/home/ml4> ping 192.168.2.1
> > > > > PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
> > > > > 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2010 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1011 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=11.5 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=4 ttl=64 time=1.12 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=5 ttl=64 time=1002 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=6 ttl=64 time=3.83 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=7 ttl=64 time=1003 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=8 ttl=64 time=4.10 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=9 ttl=64 time=1003 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=10 ttl=64 time=3.95 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=11 ttl=64 time=1003 ms
> > > > > 64 bytes from 192.168.2.1: icmp_seq=12 ttl=64 time=3.78 ms
> > > > >
> > > > >
> > > > > Please note the additional delay of ~1000ms every 2nd packet.
> > > > > This is Kernel 3.4.3, have seen it in 3.4.2 also. Does NOT
> > > > > happen in 3.3.1.
> > > > >
> > > > > Is this Issue already known? If so, I can save the work
> > > > > bisecting...
> > > > 
> > > > looks like some one reported this bug in kernel bugzilla. would be
> > > > saving us lot of time
> > > > if you can bisect it!
> > > > 
> > > 
> > > 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 is the first bad commit
> > > commit 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45
> > > Author: Johannes Berg <johannes.berg@intel.com>
> > > Date:   Thu Mar 8 15:02:06 2012 +0100
> > > 
> > >     mac80211: remove spurious BSSID change flag
> > > 
> > >     The BSSID has been set a lot earlier already and
> > >     didn't change again in ieee80211_set_associated().
> > > 
> > >     Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> > >     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > > 
> > > :040000 040000 67a19a39e4b04c16921a3758ddd2362e02e81dd3
> > > 4a7cbd327b59345b83fa613f893770fbf44220bb M      net
> > > 
> > > Reverting 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 from 3.4.3 fixes
> > > the issue.
> > > 
> > Michael,
> > 
> > Thanks for the analysis. Can you please try with the attached patch
> > without reverting mac80211 change?
> 
> [forgotten attachment was added in later mail]
> 
> Yes, that also solves the issue. I guess, you will look into getting
> that into mainline and stable asap?
> 
Thanks Michael. I already posted the patch to l-w.
http://comments.gmane.org/gmane.linux.kernel.wireless.general/93099

-Rajkumar