LinuxLists.cc - ath9k_htc: Every 2nd packet 1000ms delayed in recent kernels

2012-06-19 07:07:42

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

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

2012-06-20 06:16:05

by Michael Leun

[permalink] [raw]

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

On Wed, 20 Jun 2012 11:43:05 +0530
Rajkumar Manoharan <[email protected]> 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

2012-06-20 06:55:32

by Michael Leun

[permalink] [raw]

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

On Wed, 20 Jun 2012 11:43:05 +0530
Rajkumar Manoharan <[email protected]> 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 <[email protected]> wrote:
> >
> > > Hi,
> > >
> > > On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> > > <[email protected]> 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 <[email protected]>
> > 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 <[email protected]>
> > Signed-off-by: John W. Linville <[email protected]>
> >
> > :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

2012-06-20 06:19:34

by Rajkumar Manoharan

[permalink] [raw]

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

On Wed, Jun 20, 2012 at 08:15:53AM +0200, Michael Leun wrote:
> On Wed, 20 Jun 2012 11:43:05 +0530
> Rajkumar Manoharan <[email protected]> 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.

Attachments:

(No filename) (371.00 B)
0001-ath9k_htc-configure-bssid-on-ASSOC-IBSS-change.patch (1.77 kB)
Download all attachments

2012-06-19 09:41:38

by Mohammed Shafi

[permalink] [raw]

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

Hi,

On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
<[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html

--
thanks,
shafi

2012-06-19 22:33:44

by Michael Leun

[permalink] [raw]

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

On Tue, 19 Jun 2012 15:11:38 +0530
Mohammed Shafi <[email protected]> wrote:

> Hi,
>
> On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> <[email protected]> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: John W. Linville <[email protected]>

:040000 040000 67a19a39e4b04c16921a3758ddd2362e02e81dd3 4a7cbd327b59345b83fa613f893770fbf44220bb M net

Reverting 0775f9f90cdaf40fbf69b3192b3dddb2b3436f45 from 3.4.3 fixes the issue.

--
MfG,

Michael Leun

2012-06-20 07:10:57

by Rajkumar Manoharan

[permalink] [raw]

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

On Wed, Jun 20, 2012 at 08:55:15AM +0200, Michael Leun wrote:
> On Wed, 20 Jun 2012 11:43:05 +0530
> Rajkumar Manoharan <[email protected]> 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 <[email protected]> wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> > > > <[email protected]> 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 <[email protected]>
> > > 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 <[email protected]>
> > > Signed-off-by: John W. Linville <[email protected]>
> > >
> > > :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

2012-06-20 06:11:50

by Rajkumar Manoharan

[permalink] [raw]

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

On Wed, Jun 20, 2012 at 12:33:15AM +0200, Michael Leun wrote:
> On Tue, 19 Jun 2012 15:11:38 +0530
> Mohammed Shafi <[email protected]> wrote:
>
> > Hi,
> >
> > On Tue, Jun 19, 2012 at 12:21 PM, Michael Leun
> > <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: John W. Linville <[email protected]>
>
> :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