[ath9k-devel] Slow connection when using eduroam (AR9285)

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

Hi

My connection is slow only when using eduroam.

At home I have a router WPA2 protected and my speed goes to 1.5MB/s
(theoretically maximum).
However, when I am at university the speed is never above 300KB/s (my
friend was right next to me testing the same download link, and he had 2/3
MB/s).
I disabled power management on the device: iwconfig wlp5s0 power off
I disabled hwcrypt: echo "options ath9k nohwcrypt=1" >>
/etc/modprobe.d/ath9k.conf
I tried NetworkManager and Wicd: no improvements.

The kernel I'm using is 3.12.x
I tested with 3 different distros: Arch Linux, Ubuntu 13.10 and Fedora 20.

I believe this is a regression because when i tried a LiveCD based on
Ubuntu 12.04 (kernel was 3.2.x) it worked as intended: my download speed
hit 2/3MB/s.

Is there anything else I could try?

Thanks,
Marco Dinis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140218/753fd6af/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Oleksij Rempel]

Am 18.02.2014 10:50, schrieb Marco Andr? Dinis:
> Hi
> 
> My connection is slow only when using eduroam.
> 
> At home I have a router WPA2 protected and my speed goes to 1.5MB/s
> (theoretically maximum).
> However, when I am at university the speed is never above 300KB/s (my
> friend was right next to me testing the same download link, and he had
> 2/3 MB/s).
> I disabled power management on the device: iwconfig wlp5s0 power off
> I disabled hwcrypt: echo "options ath9k nohwcrypt=1" >>
> /etc/modprobe.d/ath9k.conf
> I tried NetworkManager and Wicd: no improvements.
> 
> The kernel I'm using is 3.12.x
> I tested with 3 different distros: Arch Linux, Ubuntu 13.10 and Fedora 20.
> 
> I believe this is a regression because when i tried a LiveCD based on
> Ubuntu 12.04 (kernel was 3.2.x) it worked as intended: my download speed
> hit 2/3MB/s.
> 
> Is there anything else I could try?

Try different kernels, not distros. If you wont to fix it ASAP, you will
need compile and test wireles-testing kernel and do "git bisect" if it
is regression. (it should be regression.)

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140218/f6b84586/attachment.pgp 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

Hi
Could you point me to a link on how can I do that?

I found this:
http://blog.securism.com/2009/01/how-to-cutting-edge-wireless-drivers-in-ubuntu/
but not sure i can use it since it's using another repo.


On Tue, Feb 18, 2014 at 4:03 PM, Oleksij Rempel <linux@rempel-privat.de>wrote:

> Am 18.02.2014 10:50, schrieb Marco Andr? Dinis:
> > Hi
> >
> > My connection is slow only when using eduroam.
> >
> > At home I have a router WPA2 protected and my speed goes to 1.5MB/s
> > (theoretically maximum).
> > However, when I am at university the speed is never above 300KB/s (my
> > friend was right next to me testing the same download link, and he had
> > 2/3 MB/s).
> > I disabled power management on the device: iwconfig wlp5s0 power off
> > I disabled hwcrypt: echo "options ath9k nohwcrypt=1" >>
> > /etc/modprobe.d/ath9k.conf
> > I tried NetworkManager and Wicd: no improvements.
> >
> > The kernel I'm using is 3.12.x
> > I tested with 3 different distros: Arch Linux, Ubuntu 13.10 and Fedora
> 20.
> >
> > I believe this is a regression because when i tried a LiveCD based on
> > Ubuntu 12.04 (kernel was 3.2.x) it worked as intended: my download speed
> > hit 2/3MB/s.
> >
> > Is there anything else I could try?
>
> Try different kernels, not distros. If you wont to fix it ASAP, you will
> need compile and test wireles-testing kernel and do "git bisect" if it
> is regression. (it should be regression.)
>
> --
> Regards,
> Oleksij
>
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140218/f5f74f61/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Oleksij Rempel]

Am 18.02.2014 18:21, schrieb Marco Andr? Dinis:
> Hi
> Could you point me to a link on how can I do that?
> 
> I found
> this: http://blog.securism.com/2009/01/how-to-cutting-edge-wireless-drivers-in-ubuntu/
> but not sure i can use it since it's using another repo.

You can use it for testing, but you can't use it to bisect regression.

https://wiki.ubuntu.com/KernelTeam/GitKernelBuild

instead of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
use
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

https://wiki.ubuntu.com/Kernel/KernelBisection
"How do I bisect the upstream kernel?"


> 
> 
> On Tue, Feb 18, 2014 at 4:03 PM, Oleksij Rempel <linux@rempel-privat.de
> <mailto:linux@rempel-privat.de>> wrote:
> 
>     Am 18.02.2014 10:50, schrieb Marco Andr? Dinis:
>     > Hi
>     >
>     > My connection is slow only when using eduroam.
>     >
>     > At home I have a router WPA2 protected and my speed goes to 1.5MB/s
>     > (theoretically maximum).
>     > However, when I am at university the speed is never above 300KB/s (my
>     > friend was right next to me testing the same download link, and he had
>     > 2/3 MB/s).
>     > I disabled power management on the device: iwconfig wlp5s0 power off
>     > I disabled hwcrypt: echo "options ath9k nohwcrypt=1" >>
>     > /etc/modprobe.d/ath9k.conf
>     > I tried NetworkManager and Wicd: no improvements.
>     >
>     > The kernel I'm using is 3.12.x
>     > I tested with 3 different distros: Arch Linux, Ubuntu 13.10 and
>     Fedora 20.
>     >
>     > I believe this is a regression because when i tried a LiveCD based on
>     > Ubuntu 12.04 (kernel was 3.2.x) it worked as intended: my download
>     speed
>     > hit 2/3MB/s.
>     >
>     > Is there anything else I could try?
> 
>     Try different kernels, not distros. If you wont to fix it ASAP, you will
>     need compile and test wireles-testing kernel and do "git bisect" if it
>     is regression. (it should be regression.)
> 
>     --
>     Regards,
>     Oleksij
> 
> 
>     _______________________________________________
>     ath9k-devel mailing list
>     ath9k-devel at lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
>     https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> 
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140218/c4f4b15c/attachment.pgp 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Sujith Manoharan]

Marco Andr? Dinis wrote:
> Could you point me to a link on how can I do that?
> 
> I found this:?http://blog.securism.com/2009/01/how-to-cutting-edge-wireless-drivers-in-ubuntu/
> but not sure i can use it since it's using another repo.

backports is the easiest way to get the latest driver.

https://backports.wiki.kernel.org/index.php/Main_Page
Latest release: https://www.kernel.org/pub/linux/kernel/projects/backports/2014/02/10/

Sujith

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

I did try backports but probably messed up somewhere because after reboot
the system was broken, for examlpe: ifconfig blocked terminal (couldn't
CTRL+C and no output from it), and the same goes for "sudo anything".

I'll try wireless-testing as soon as I can.


On Wed, Feb 19, 2014 at 3:31 AM, Sujith Manoharan <sujith@msujith.org>wrote:

> Marco Andr? Dinis wrote:
> > Could you point me to a link on how can I do that?
> >
> > I found this:
> http://blog.securism.com/2009/01/how-to-cutting-edge-wireless-drivers-in-ubuntu/
> > but not sure i can use it since it's using another repo.
>
> backports is the easiest way to get the latest driver.
>
> https://backports.wiki.kernel.org/index.php/Main_Page
> Latest release:
> https://www.kernel.org/pub/linux/kernel/projects/backports/2014/02/10/
>
> Sujith
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140219/ed6bcd17/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

Using kernel 3.14 ( 3.14.0-1-mainline) had no effect on performance
improvement.

However, I did find something that can help.
Today i connected at two different places and in one of them i had normal
speeds.
One of the places is relatively new (and probably has new WAPs, and
probably those WAPs use 802.11n ).

I think the problem is that this driver does not work well under 802.11n

Is it possible to disable 802.11n and force the driver to use a previous
mode?

Thanks


On Wed, Feb 19, 2014 at 9:24 AM, Marco Andr? Dinis <
marcoandredinis@gmail.com> wrote:

> I did try backports but probably messed up somewhere because after reboot
> the system was broken, for examlpe: ifconfig blocked terminal (couldn't
> CTRL+C and no output from it), and the same goes for "sudo anything".
>
> I'll try wireless-testing as soon as I can.
>
>
> On Wed, Feb 19, 2014 at 3:31 AM, Sujith Manoharan <sujith@msujith.org>wrote:
>
>> Marco Andr? Dinis wrote:
>> > Could you point me to a link on how can I do that?
>> >
>> > I found this:
>> http://blog.securism.com/2009/01/how-to-cutting-edge-wireless-drivers-in-ubuntu/
>> > but not sure i can use it since it's using another repo.
>>
>> backports is the easiest way to get the latest driver.
>>
>> https://backports.wiki.kernel.org/index.php/Main_Page
>> Latest release:
>> https://www.kernel.org/pub/linux/kernel/projects/backports/2014/02/10/
>>
>> Sujith
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140221/45e5f455/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Oleksij Rempel]

Am 21.02.2014 22:54, schrieb Marco Andr? Dinis:
> Using kernel 3.14 ( 3.14.0-1-mainline) had no effect on performance
> improvement.
> 
> However, I did find something that can help.
> Today i connected at two different places and in one of them i had
> normal speeds.
> One of the places is relatively new (and probably has new WAPs, and
> probably those WAPs use 802.11n ).
> 
> I think the problem is that this driver does not work well under 802.11n
> 
> Is it possible to disable 802.11n and force the driver to use a previous
> mode?

I would suggest you to search where is actual regression.
Right now i have access to Asus Eeepc 1005HA with AR9285.
Kernel 3.13.0-994-generic. I get good speed with it:

netperf -H zwerg.local -t TCP_MAERTS
MIGRATED TCP MAERTS TEST from 0.0.0.0 () port 0 AF_INET to zwerg.lan ()
port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.00      94.00


netperf -H zwerg.local -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to zwerg.lan ()
port 0 AF_INET : demo
Recv   Send    Send
Socket Socket  Message  Elapsed
Size   Size    Size     Time     Throughput
bytes  bytes   bytes    secs.    10^6bits/sec

 87380  16384  16384    10.05      93.99


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140222/5d21cdaf/attachment.pgp 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

I don't know if I understood what you are suggesting
Should i look at kernel's code from 3.2 to 3.X until i find what caused
this regression?


On Sat, Feb 22, 2014 at 8:59 AM, Oleksij Rempel <linux@rempel-privat.de>wrote:

> Am 21.02.2014 22:54, schrieb Marco Andr? Dinis:
> > Using kernel 3.14 ( 3.14.0-1-mainline) had no effect on performance
> > improvement.
> >
> > However, I did find something that can help.
> > Today i connected at two different places and in one of them i had
> > normal speeds.
> > One of the places is relatively new (and probably has new WAPs, and
> > probably those WAPs use 802.11n ).
> >
> > I think the problem is that this driver does not work well under 802.11n
> >
> > Is it possible to disable 802.11n and force the driver to use a previous
> > mode?
>
> I would suggest you to search where is actual regression.
> Right now i have access to Asus Eeepc 1005HA with AR9285.
> Kernel 3.13.0-994-generic. I get good speed with it:
>
> netperf -H zwerg.local -t TCP_MAERTS
> MIGRATED TCP MAERTS TEST from 0.0.0.0 () port 0 AF_INET to zwerg.lan ()
> port 0 AF_INET : demo
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^6bits/sec
>
>  87380  16384  16384    10.00      94.00
>
>
> netperf -H zwerg.local -t TCP_STREAM
> MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to zwerg.lan ()
> port 0 AF_INET : demo
> Recv   Send    Send
> Socket Socket  Message  Elapsed
> Size   Size    Size     Time     Throughput
> bytes  bytes   bytes    secs.    10^6bits/sec
>
>  87380  16384  16384    10.05      93.99
>
>
> --
> Regards,
> Oleksij
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140222/f32932d6/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Oleksij Rempel]

Am 22.02.2014 14:39, schrieb Marco Andr? Dinis:
> I don't know if I understood what you are suggesting
> Should i look at kernel's code from 3.2 to 3.X until i find what caused
> this regression?

If it is kernel regression and not some thing else, then i repost my
previous email:
======================================================================
You can use it for testing, but you can't use it to bisect regression.

https://wiki.ubuntu.com/KernelTeam/GitKernelBuild

instead of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
use
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git

https://wiki.ubuntu.com/Kernel/KernelBisection
"How do I bisect the upstream kernel?"
======================================================================

> 
> On Sat, Feb 22, 2014 at 8:59 AM, Oleksij Rempel <linux@rempel-privat.de
> <mailto:linux@rempel-privat.de>> wrote:
> 
>     Am 21.02.2014 22:54, schrieb Marco Andr? Dinis:
>     > Using kernel 3.14 ( 3.14.0-1-mainline) had no effect on performance
>     > improvement.
>     >
>     > However, I did find something that can help.
>     > Today i connected at two different places and in one of them i had
>     > normal speeds.
>     > One of the places is relatively new (and probably has new WAPs, and
>     > probably those WAPs use 802.11n ).
>     >
>     > I think the problem is that this driver does not work well under
>     802.11n
>     >
>     > Is it possible to disable 802.11n and force the driver to use a
>     previous
>     > mode?
> 
>     I would suggest you to search where is actual regression.
>     Right now i have access to Asus Eeepc 1005HA with AR9285.
>     Kernel 3.13.0-994-generic. I get good speed with it:
> 
>     netperf -H zwerg.local -t TCP_MAERTS
>     MIGRATED TCP MAERTS TEST from 0.0.0.0 () port 0 AF_INET to zwerg.lan ()
>     port 0 AF_INET : demo
>     Recv   Send    Send
>     Socket Socket  Message  Elapsed
>     Size   Size    Size     Time     Throughput
>     bytes  bytes   bytes    secs.    10^6bits/sec
> 
>      87380  16384  16384    10.00      94.00
> 
> 
>     netperf -H zwerg.local -t TCP_STREAM
>     MIGRATED TCP STREAM TEST from 0.0.0.0 () port 0 AF_INET to zwerg.lan ()
>     port 0 AF_INET : demo
>     Recv   Send    Send
>     Socket Socket  Message  Elapsed
>     Size   Size    Size     Time     Throughput
>     bytes  bytes   bytes    secs.    10^6bits/sec
> 
>      87380  16384  16384    10.05      93.99
> 
> 
>     --
>     Regards,
>     Oleksij
> 
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140222/e9a1a161/attachment.pgp 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

After testing multiple kernel versions I found the last good one: 3.9.11

wireless-testing does not have minor versions (3.9.x) , so I'm
bisecting v3.9 and v3.10

git bisect startgit bisect good v3.9git bisect bad v3.10


Output:

? wireless-testing $ git bisect start
? wireless-testing $ git bisect good v3.9
? wireless-testing $ git bisect bad v3.10
Bisecting: 7345 revisions left to test after this (roughly 13 steps)
[20b4fb485227404329e41ad15588afad3df23050] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs


What to do now? Can I skip some kernel compilations looking at commit
logs? (it took me one hour to compile linux-mainline).



On Sat, Feb 22, 2014 at 4:02 PM, Oleksij Rempel <linux@rempel-privat.de>wrote:

> Am 22.02.2014 16:57, schrieb Marco Andr? Dinis:
> > I followed the instructions from the link you gave me (and this wiki
> > entry from Arch
> > Linux:
> https://wiki.archlinux.org/index.php/Kernels/Compilation/Traditional)
> >
> > Everything went well on compilation, but the connection is still slow.
> >
> >
> > Now I'll have to bisect the kernel right? That implies testing various
> > versions from the known working version (in this case 3.2)
>
> Yes, it will be easier for you to use precompiled kernels from kernel
> ppa to limit number of test you need to do. If you can say: kernel 3.2
> is working and 3.3 is not working it will be great advantage.
>
> PS: i still have some doubts that is is kernel regression. But may be
> there is some thing different between your and my hardware.
>
>
> --
> Regards,
> Oleksij
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140222/f78bc591/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Oleksij Rempel]

Am 22.02.2014 19:14, schrieb Marco Andr? Dinis:
> After testing multiple kernel versions I found the last good one: 3.9.11
> 
> wireless-testing does not have minor versions (3.9.x) , so I'm
> bisecting v3.9 and v3.10
> 
> git bisect start
> git bisect good v3.9
> git bisect bad v3.10
> 
> 
> Output:
> 
> ? wireless-testing $ git bisect start
> ? wireless-testing $ git bisect good v3.9
> ? wireless-testing $ git bisect bad v3.10
> Bisecting: 7345 revisions left to test after this (roughly 13 steps)
> [20b4fb485227404329e41ad15588afad3df23050] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs <http://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs>
>  
> What to do now? 

compile; test;
if results is good: git bisect good
if results is bad: git bisect bad

> Can I skip some kernel compilations looking at commit logs? (it took me one hour to compile linux-mainline).

You can try, but in my experience you will not really get less steps.
Beside, if there is no to match changes, compilation will take less time.

-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140222/f0e96141/attachment.pgp 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

(After some hours :D ) I found the first bad commit


? wireless-testing $ git bisect good

723e711356b5a8a95728a890e254e8b0d47b55cf is the first bad commit
> commit 723e711356b5a8a95728a890e254e8b0d47b55cf
> Author: Felix Fietkau <nbd@openwrt.org>
> Date:   Mon Apr 8 00:04:11 2013 +0200
>     ath9k: fix handling of broken descriptors
>
>     As the comment in ath_get_next_rx_buf indicates, if a descriptor with
>     the done bit set follows one with the done bit cleared, both
> descriptors
>     should be discarded, however the driver is not doing that yet.
>
>     To fix this, use the rs->rs_more flag as an indicator that the
> following
>     frame should be discarded. This also helps with the split buffer case:
>     if the first part of the frame is discarded, the following parts need
> to
>     be discarded as well, since they contain no valid header or usable
> data.
>
>     Signed-off-by: Felix Fietkau <nbd@openwrt.org>
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> :040000 040000 04729027f175daa29d7d460bb3c07192739b21b3
> d9c0085342eb17ee67eabf44cbbe935c7485fc4f M drivers




On Sat, Feb 22, 2014 at 7:02 PM, Oleksij Rempel <linux@rempel-privat.de>wrote:

> Am 22.02.2014 19:14, schrieb Marco Andr? Dinis:
> > After testing multiple kernel versions I found the last good one: 3.9.11
> >
> > wireless-testing does not have minor versions (3.9.x) , so I'm
> > bisecting v3.9 and v3.10
> >
> > git bisect start
> > git bisect good v3.9
> > git bisect bad v3.10
> >
> >
> > Output:
> >
> > ? wireless-testing $ git bisect start
> > ? wireless-testing $ git bisect good v3.9
> > ? wireless-testing $ git bisect bad v3.10
> > Bisecting: 7345 revisions left to test after this (roughly 13 steps)
> > [20b4fb485227404329e41ad15588afad3df23050] Merge branch 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs <
> http://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs>
> >
> > What to do now?
>
> compile; test;
> if results is good: git bisect good
> if results is bad: git bisect bad
>
> > Can I skip some kernel compilations looking at commit logs? (it took me
> one hour to compile linux-mainline).
>
> You can try, but in my experience you will not really get less steps.
> Beside, if there is no to match changes, compilation will take less time.
>
> --
> Regards,
> Oleksij
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140223/17f4b3c3/attachment-0001.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Oleksij Rempel]

Hi Felix,

can you please take a look here:


Am 23.02.2014 04:08, schrieb Marco Andr? Dinis:
> (After some hours :D ) I found the first bad commit
> 
> 
>     ? wireless-testing $ git bisect good 
> 
>     723e711356b5a8a95728a890e254e8b0d47b55cf is the first bad commit
>     commit 723e711356b5a8a95728a890e254e8b0d47b55cf
>     Author: Felix Fietkau <nbd at openwrt.org <mailto:nbd@openwrt.org>>
>     Date:   Mon Apr 8 00:04:11 2013 +0200
>         ath9k: fix handling of broken descriptors
>         
>         As the comment in ath_get_next_rx_buf indicates, if a descriptor
>     with
>         the done bit set follows one with the done bit cleared, both
>     descriptors
>         should be discarded, however the driver is not doing that yet.
>         
>         To fix this, use the rs->rs_more flag as an indicator that the
>     following
>         frame should be discarded. This also helps with the split buffer
>     case:
>         if the first part of the frame is discarded, the following parts
>     need to
>         be discarded as well, since they contain no valid header or
>     usable data.
>         
>         Signed-off-by: Felix Fietkau <nbd@openwrt.org
>     <mailto:nbd@openwrt.org>>
>         Signed-off-by: John W. Linville <linville@tuxdriver.com
>     <mailto:linville@tuxdriver.com>>
>     :040000 040000 04729027f175daa29d7d460bb3c07192739b21b3
>     d9c0085342eb17ee67eabf44cbbe935c7485fc4f Mdrivers
> 
> 
> 
> 
> On Sat, Feb 22, 2014 at 7:02 PM, Oleksij Rempel <linux@rempel-privat.de
> <mailto:linux@rempel-privat.de>> wrote:
> 
>     Am 22.02.2014 19:14, schrieb Marco Andr? Dinis:
>     > After testing multiple kernel versions I found the last good one:
>     3.9.11
>     >
>     > wireless-testing does not have minor versions (3.9.x) , so I'm
>     > bisecting v3.9 and v3.10
>     >
>     > git bisect start
>     > git bisect good v3.9
>     > git bisect bad v3.10
>     >
>     >
>     > Output:
>     >
>     > ? wireless-testing $ git bisect start
>     > ? wireless-testing $ git bisect good v3.9
>     > ? wireless-testing $ git bisect bad v3.10
>     > Bisecting: 7345 revisions left to test after this (roughly 13 steps)
>     > [20b4fb485227404329e41ad15588afad3df23050] Merge branch
>     'for-linus' of
>     git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
>     <http://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs>
>     <http://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs>
>     >
>     > What to do now?
> 
>     compile; test;
>     if results is good: git bisect good
>     if results is bad: git bisect bad
> 
>     > Can I skip some kernel compilations looking at commit logs? (it
>     took me one hour to compile linux-mainline).
> 
>     You can try, but in my experience you will not really get less steps.
>     Beside, if there is no to match changes, compilation will take less
>     time.
> 
>     --
>     Regards,
>     Oleksij
> 
> 


-- 
Regards,
Oleksij

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 278 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140223/9aa3dbc8/attachment.pgp 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Felix Fietkau]

On 2014-02-23 04:08, Marco Andr? Dinis wrote:
> (After some hours :D ) I found the first bad commit
> 
> 
>     ? wireless-testing $ git bisect good 
> 
>     723e711356b5a8a95728a890e254e8b0d47b55cf is the first bad commit
>     commit 723e711356b5a8a95728a890e254e8b0d47b55cf
>     Author: Felix Fietkau <nbd at openwrt.org <mailto:nbd@openwrt.org>>
>     Date:   Mon Apr 8 00:04:11 2013 +0200
>         ath9k: fix handling of broken descriptors

Please apply this patch and show me how often the printk triggers.

---
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 076dae1..3c86d08 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -794,8 +794,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 	 * ath_get_next_rx_buf().
 	 */
 	sc->rx.discard_next = rx_stats->rs_more;
-	if (discard_current)
+	if (discard_current) {
+		if (net_ratelimit())
+			ath_printk(KERN_INFO, common, "discard current packet, more: %d\n", rx_stats->rs_more);
 		return -EINVAL;
+	}
 
 	/*
 	 * Discard zero-length packets.

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

Hi

I started downloding a file and this is the output from ''dmesg'' (less
than 30 sec)

[  167.654939] wlp5s0: associated
[  167.654953] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready
[  174.900658] net_ratelimit: 47 callbacks suppressed
[  174.900663] ath: phy0: discard current packet, more: 0
[  175.700585] ath: phy0: discard current packet, more: 0
[  175.701216] ath: phy0: discard current packet, more: 0
[  175.702005] ath: phy0: discard current packet, more: 0
[  175.708847] ath: phy0: discard current packet, more: 0
[  175.974913] ath: phy0: discard current packet, more: 0
[  175.975581] ath: phy0: discard current packet, more: 0
[  177.776297] ath: phy0: discard current packet, more: 0
[  177.899314] ath: phy0: discard current packet, more: 0
[  177.918913] ath: phy0: discard current packet, more: 0
[  180.729440] net_ratelimit: 52 callbacks suppressed
[  180.729450] ath: phy0: discard current packet, more: 0
[  180.761591] ath: phy0: discard current packet, more: 0
[  180.788962] ath: phy0: discard current packet, more: 0
[  180.822209] ath: phy0: discard current packet, more: 0
[  180.882488] ath: phy0: discard current packet, more: 0
[  180.905397] ath: phy0: discard current packet, more: 0
[  180.927816] ath: phy0: discard current packet, more: 0
[  180.956332] ath: phy0: discard current packet, more: 0
[  180.992617] ath: phy0: discard current packet, more: 0
[  181.014866] ath: phy0: discard current packet, more: 0
[  185.808111] net_ratelimit: 175 callbacks suppressed
[  185.808122] ath: phy0: discard current packet, more: 0
[  185.850950] ath: phy0: discard current packet, more: 0
[  185.866959] ath: phy0: discard current packet, more: 0
[  185.893668] ath: phy0: discard current packet, more: 0
[  185.911175] ath: phy0: discard current packet, more: 0
[  185.932139] ath: phy0: discard current packet, more: 0
[  185.932743] ath: phy0: discard current packet, more: 0
[  185.933531] ath: phy0: discard current packet, more: 0
[  185.956540] ath: phy0: discard current packet, more: 0
[  185.957056] ath: phy0: discard current packet, more: 0
[  190.967555] net_ratelimit: 137 callbacks suppressed
[  190.967565] ath: phy0: discard current packet, more: 0
[  191.006481] ath: phy0: discard current packet, more: 0
[  191.120842] ath: phy0: discard current packet, more: 0
[  191.145790] ath: phy0: discard current packet, more: 0
[  191.186840] ath: phy0: discard current packet, more: 0
[  191.204397] ath: phy0: discard current packet, more: 0
[  191.240674] ath: phy0: discard current packet, more: 0
[  191.257571] ath: phy0: discard current packet, more: 0
[  191.279926] ath: phy0: discard current packet, more: 0
[  191.280649] ath: phy0: discard current packet, more: 0


On Sun, Feb 23, 2014 at 8:34 AM, Felix Fietkau <nbd@openwrt.org> wrote:

> On 2014-02-23 04:08, Marco Andr? Dinis wrote:
> > (After some hours :D ) I found the first bad commit
> >
> >
> >     ? wireless-testing $ git bisect good
> >
> >     723e711356b5a8a95728a890e254e8b0d47b55cf is the first bad commit
> >     commit 723e711356b5a8a95728a890e254e8b0d47b55cf
> >     Author: Felix Fietkau <nbd at openwrt.org <mailto:nbd@openwrt.org>>
> >     Date:   Mon Apr 8 00:04:11 2013 +0200
> >         ath9k: fix handling of broken descriptors
>
> Please apply this patch and show me how often the printk triggers.
>
> ---
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c
> b/drivers/net/wireless/ath/ath9k/recv.c
> index 076dae1..3c86d08 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -794,8 +794,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc
> *sc,
>          * ath_get_next_rx_buf().
>          */
>         sc->rx.discard_next = rx_stats->rs_more;
> -       if (discard_current)
> +       if (discard_current) {
> +               if (net_ratelimit())
> +                       ath_printk(KERN_INFO, common, "discard current
> packet, more: %d\n", rx_stats->rs_more);
>                 return -EINVAL;
> +       }
>
>         /*
>          * Discard zero-length packets.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140223/219a9dd4/attachment.htm 

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Jonathan North Washington]

Hi Marco,

I've read through the thread, and can't help but wonder if your issue
is related to one at my university.

We have our "IU Secure" network and "eduroam" networks through the
same APs.  In August the IT people applied a firmware upgrade released
by the manufacturer that prevents most devices supporting 802.11n
speeds to connect from machines running linux or Android.  The
behaviour that's experienced is that of a functioning connection for a
minute or two, and then no passable traffic for maybe 10 minutes (the
times vary though).  The IT staff has informed me that it has
something to do with how most linux wifi drivers do handshakes at n
speeds.  Another firmware upgrade in December didn't fix the issue,
and it persists until today.

I went to another university in October, and the eduroam network there
worked perfectly.  I guess they have different APs, or at least
haven't applied any firmware patches.

In theory, a driver patch could solve my issue, but in practice,
something the manufacturer of the routers has done to the firmware is
seriously wrong.  I wish I knew more about the problem so that I could
file a bug report with the ath9k devs, but the IT people have been
repeatedly brick-walling me, essentially telling me that the problem
is my fault for using linux and Android.

-- 
Jonathan

On 18 February 2014 04:50, Marco Andr? Dinis <marcoandredinis@gmail.com> wrote:
> Hi
>
> My connection is slow only when using eduroam.
>
> At home I have a router WPA2 protected and my speed goes to 1.5MB/s
> (theoretically maximum).
> However, when I am at university the speed is never above 300KB/s (my friend
> was right next to me testing the same download link, and he had 2/3 MB/s).
> I disabled power management on the device: iwconfig wlp5s0 power off
> I disabled hwcrypt: echo "options ath9k nohwcrypt=1" >>
> /etc/modprobe.d/ath9k.conf
> I tried NetworkManager and Wicd: no improvements.
>
> The kernel I'm using is 3.12.x
> I tested with 3 different distros: Arch Linux, Ubuntu 13.10 and Fedora 20.
>
> I believe this is a regression because when i tried a LiveCD based on Ubuntu
> 12.04 (kernel was 3.2.x) it worked as intended: my download speed hit
> 2/3MB/s.
>
> Is there anything else I could try?
>
> Thanks,
> Marco Dinis
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Felix Fietkau]

On 2014-02-23 20:44, Marco Andr? Dinis wrote:
> Hi
> 
> I started downloding a file and this is the output from ''dmesg'' (less
> than 30 sec)
> 
> [  167.654939] wlp5s0: associated
> [  167.654953] IPv6: ADDRCONF(NETDEV_CHANGE): wlp5s0: link becomes ready
> [  174.900658] net_ratelimit: 47 callbacks suppressed
> [  174.900663] ath: phy0: discard current packet, more: 0
> [  175.700585] ath: phy0: discard current packet, more: 0
Please revert the last patch, and check if the connection works better
with this one:
---
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index a0ebdd0..82e340d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -732,11 +732,18 @@ static struct ath_rxbuf *ath_get_next_rx_buf(struct ath_softc *sc,
 			return NULL;
 
 		/*
-		 * mark descriptor as zero-length and set the 'more'
-		 * flag to ensure that both buffers get discarded
+		 * Re-check previous descriptor, in case it has been filled
+		 * in the mean time.
 		 */
-		rs->rs_datalen = 0;
-		rs->rs_more = true;
+		ret = ath9k_hw_rxprocdesc(ah, ds, rs);
+		if (ret == -EINPROGRESS) {
+			/*
+			 * mark descriptor as zero-length and set the 'more'
+			 * flag to ensure that both buffers get discarded
+			 */
+			rs->rs_datalen = 0;
+			rs->rs_more = true;
+		}
 	}
 
 	list_del(&bf->list);
@@ -985,32 +992,32 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 	struct ath_common *common = ath9k_hw_common(ah);
 	struct ieee80211_hdr *hdr;
 	bool discard_current = sc->rx.discard_next;
-	int ret = 0;
 
 	/*
 	 * Discard corrupt descriptors which are marked in
 	 * ath_get_next_rx_buf().
 	 */
-	sc->rx.discard_next = rx_stats->rs_more;
 	if (discard_current)
-		return -EINVAL;
+		goto corrupt;
+
+	sc->rx.discard_next = false;
 
 	/*
 	 * Discard zero-length packets.
 	 */
 	if (!rx_stats->rs_datalen) {
 		RX_STAT_INC(rx_len_err);
-		return -EINVAL;
+		goto corrupt;
 	}
 
-        /*
-         * rs_status follows rs_datalen so if rs_datalen is too large
-         * we can take a hint that hardware corrupted it, so ignore
-         * those frames.
-         */
+	/*
+	 * rs_status follows rs_datalen so if rs_datalen is too large
+	 * we can take a hint that hardware corrupted it, so ignore
+	 * those frames.
+	 */
 	if (rx_stats->rs_datalen > (common->rx_bufsize - ah->caps.rx_status_len)) {
 		RX_STAT_INC(rx_len_err);
-		return -EINVAL;
+		goto corrupt;
 	}
 
 	/* Only use status info from the last fragment */
@@ -1024,10 +1031,8 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 	 * This is different from the other corrupt descriptor
 	 * condition handled above.
 	 */
-	if (rx_stats->rs_status & ATH9K_RXERR_CORRUPT_DESC) {
-		ret = -EINVAL;
-		goto exit;
-	}
+	if (rx_stats->rs_status & ATH9K_RXERR_CORRUPT_DESC)
+		goto corrupt;
 
 	hdr = (struct ieee80211_hdr *) (skb->data + ah->caps.rx_status_len);
 
@@ -1043,18 +1048,15 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 		if (ath_process_fft(sc, hdr, rx_stats, rx_status->mactime))
 			RX_STAT_INC(rx_spectral);
 
-		ret = -EINVAL;
-		goto exit;
+		return -EINVAL;
 	}
 
 	/*
 	 * everything but the rate is checked here, the rate check is done
 	 * separately to avoid doing two lookups for a rate for each frame.
 	 */
-	if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error)) {
-		ret = -EINVAL;
-		goto exit;
-	}
+	if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error))
+		return -EINVAL;
 
 	if (ath_is_mybeacon(common, hdr)) {
 		RX_STAT_INC(rx_beacons);
@@ -1064,15 +1066,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 	/*
 	 * This shouldn't happen, but have a safety check anyway.
 	 */
-	if (WARN_ON(!ah->curchan)) {
-		ret = -EINVAL;
-		goto exit;
-	}
+	if (WARN_ON(!ah->curchan))
+		return -EINVAL;
 
-	if (ath9k_process_rate(common, hw, rx_stats, rx_status)) {
-		ret =-EINVAL;
-		goto exit;
-	}
+	if (ath9k_process_rate(common, hw, rx_stats, rx_status))
+		return -EINVAL;
 
 	ath9k_process_rssi(common, hw, rx_stats, rx_status);
 
@@ -1087,9 +1085,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc *sc,
 		sc->rx.num_pkts++;
 #endif
 
-exit:
-	sc->rx.discard_next = false;
-	return ret;
+	return 0;
+
+corrupt:
+	sc->rx.discard_next = rx_stats->rs_more;
+	return -EINVAL;
 }
 
 static void ath9k_rx_skb_postprocess(struct ath_common *common,

[ath9k-devel] Slow connection when using eduroam (AR9285)

[Marco André Dinis]

@Jonathan
Maybe the problem is related, but in my case the connection is stable (no
disconnects, no problems on connecting). The only problem is the slowness
of it.

Felix thank you so much :D it worked

I'm even trying differente locations to make sure everything is ok.
btw, I'm using the mainline kernel 3.14.0-rc3

Oleksij thanks for your patiente :)

Which version can I expect to have this commited to kernel? 3.14.x 3.13.x?

On Mon, Feb 24, 2014 at 7:34 AM, Felix Fietkau <nbd@openwrt.org> wrote:
>
> Please revert the last patch, and check if the connection works better
> with this one:
> ---
> diff --git a/drivers/net/wireless/ath/ath9k/recv.c
> b/drivers/net/wireless/ath/ath9k/recv.c
> index a0ebdd0..82e340d 100644
> --- a/drivers/net/wireless/ath/ath9k/recv.c
> +++ b/drivers/net/wireless/ath/ath9k/recv.c
> @@ -732,11 +732,18 @@ static struct ath_rxbuf *ath_get_next_rx_buf(struct
> ath_softc *sc,
>                         return NULL;
>
>                 /*
> -                * mark descriptor as zero-length and set the 'more'
> -                * flag to ensure that both buffers get discarded
> +                * Re-check previous descriptor, in case it has been filled
> +                * in the mean time.
>                  */
> -               rs->rs_datalen = 0;
> -               rs->rs_more = true;
> +               ret = ath9k_hw_rxprocdesc(ah, ds, rs);
> +               if (ret == -EINPROGRESS) {
> +                       /*
> +                        * mark descriptor as zero-length and set the
> 'more'
> +                        * flag to ensure that both buffers get discarded
> +                        */
> +                       rs->rs_datalen = 0;
> +                       rs->rs_more = true;
> +               }
>         }
>
>         list_del(&bf->list);
> @@ -985,32 +992,32 @@ static int ath9k_rx_skb_preprocess(struct ath_softc
> *sc,
>         struct ath_common *common = ath9k_hw_common(ah);
>         struct ieee80211_hdr *hdr;
>         bool discard_current = sc->rx.discard_next;
> -       int ret = 0;
>
>         /*
>          * Discard corrupt descriptors which are marked in
>          * ath_get_next_rx_buf().
>          */
> -       sc->rx.discard_next = rx_stats->rs_more;
>         if (discard_current)
> -               return -EINVAL;
> +               goto corrupt;
> +
> +       sc->rx.discard_next = false;
>
>         /*
>          * Discard zero-length packets.
>          */
>         if (!rx_stats->rs_datalen) {
>                 RX_STAT_INC(rx_len_err);
> -               return -EINVAL;
> +               goto corrupt;
>         }
>
> -        /*
> -         * rs_status follows rs_datalen so if rs_datalen is too large
> -         * we can take a hint that hardware corrupted it, so ignore
> -         * those frames.
> -         */
> +       /*
> +        * rs_status follows rs_datalen so if rs_datalen is too large
> +        * we can take a hint that hardware corrupted it, so ignore
> +        * those frames.
> +        */
>         if (rx_stats->rs_datalen > (common->rx_bufsize -
> ah->caps.rx_status_len)) {
>                 RX_STAT_INC(rx_len_err);
> -               return -EINVAL;
> +               goto corrupt;
>         }
>
>         /* Only use status info from the last fragment */
> @@ -1024,10 +1031,8 @@ static int ath9k_rx_skb_preprocess(struct ath_softc
> *sc,
>          * This is different from the other corrupt descriptor
>          * condition handled above.
>          */
> -       if (rx_stats->rs_status & ATH9K_RXERR_CORRUPT_DESC) {
> -               ret = -EINVAL;
> -               goto exit;
> -       }
> +       if (rx_stats->rs_status & ATH9K_RXERR_CORRUPT_DESC)
> +               goto corrupt;
>
>         hdr = (struct ieee80211_hdr *) (skb->data +
> ah->caps.rx_status_len);
>
> @@ -1043,18 +1048,15 @@ static int ath9k_rx_skb_preprocess(struct
> ath_softc *sc,
>                 if (ath_process_fft(sc, hdr, rx_stats, rx_status->mactime))
>                         RX_STAT_INC(rx_spectral);
>
> -               ret = -EINVAL;
> -               goto exit;
> +               return -EINVAL;
>         }
>
>         /*
>          * everything but the rate is checked here, the rate check is done
>          * separately to avoid doing two lookups for a rate for each frame.
>          */
> -       if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats,
> decrypt_error)) {
> -               ret = -EINVAL;
> -               goto exit;
> -       }
> +       if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats,
> decrypt_error))
> +               return -EINVAL;
>
>         if (ath_is_mybeacon(common, hdr)) {
>                 RX_STAT_INC(rx_beacons);
> @@ -1064,15 +1066,11 @@ static int ath9k_rx_skb_preprocess(struct
> ath_softc *sc,
>         /*
>          * This shouldn't happen, but have a safety check anyway.
>          */
> -       if (WARN_ON(!ah->curchan)) {
> -               ret = -EINVAL;
> -               goto exit;
> -       }
> +       if (WARN_ON(!ah->curchan))
> +               return -EINVAL;
>
> -       if (ath9k_process_rate(common, hw, rx_stats, rx_status)) {
> -               ret =-EINVAL;
> -               goto exit;
> -       }
> +       if (ath9k_process_rate(common, hw, rx_stats, rx_status))
> +               return -EINVAL;
>
>         ath9k_process_rssi(common, hw, rx_stats, rx_status);
>
> @@ -1087,9 +1085,11 @@ static int ath9k_rx_skb_preprocess(struct ath_softc
> *sc,
>                 sc->rx.num_pkts++;
>  #endif
>
> -exit:
> -       sc->rx.discard_next = false;
> -       return ret;
> +       return 0;
> +
> +corrupt:
> +       sc->rx.discard_next = rx_stats->rs_more;
> +       return -EINVAL;
>  }
>
>  static void ath9k_rx_skb_postprocess(struct ath_common *common,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20140224/05e3464f/attachment.htm