Bug 29072 - Internet Speed Drops When Using Wireless
Internet Speed Drops When Using Wireless
Status: CLOSED CODE_FIX
Product: Networking
Classification: Unclassified
Component: Wireless
All Linux
: P1 normal
Assigned To: networking_wireless@kernel-bugs.osdl.org
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-13 19:10 UTC by Jay LaCroix
Modified: 2011-06-28 18:11 UTC (History)
11 users (show)

See Also:
Kernel Version:
Tree: Mainline
Regression: Yes


Attachments
Bisect Log (1.85 KB, text/plain)
2011-02-15 04:06 UTC, Jay LaCroix
Details
List of Commands I Executed to Bisect (2.50 KB, text/plain)
2011-02-15 04:07 UTC, Jay LaCroix
Details
Newest Bisect Log (2.31 KB, text/plain)
2011-02-16 03:14 UTC, Jay LaCroix
Details
test patch (788 bytes, text/plain)
2011-02-17 12:37 UTC, Stanislaw Gruszka
Details
Bad Commit from Git Bisect Run (532 bytes, text/plain)
2011-02-18 04:50 UTC, Jay LaCroix
Details
Newest Bisect Log (2.47 KB, application/octet-stream)
2011-02-18 04:51 UTC, Jay LaCroix
Details
dmesg output (462.38 KB, text/plain)
2011-02-18 04:51 UTC, Jay LaCroix
Details
Bisect log (1.47 KB, text/plain)
2011-03-08 08:02 UTC, Ryan Voots
Details

Description Jay LaCroix 2011-02-13 19:10:37 UTC
I am currently using kernel 2.6.38-rc4, and I notice that when using wireless, my Internet speed drops so low that it can be impossible to use at times. With 2.6.37, my speed while using wireless (wireless N) according to speakeasy.net speed test is up to 12mbps, but with 2.6.38-rc4 I'm lucky to get above 1MBps, and quite often it will drop to 1.4kbs. Youtube videos are impossible to watch with 2.6.38-rc4, taking an average of a half hour for a five minute video to load. No problems at all with 2.6.37. If I use a wired connection with 2.6.38-rc4, I have no issues. 

The card I use is an Atheros AR5B91 which normally has excellent out of the box Linux support. My laptop is a Dell Latitude E6410.

Let me know if there are any logs you guys need, this is the first time I ever submitted a bug against the mainline kernel.
Comment 1 John W. Linville 2011-02-14 17:33:54 UTC
Perhaps you could do a git bisect?
Comment 2 Jay LaCroix 2011-02-14 23:18:03 UTC
I'm not really familiar how to do a bisect against wireless speed. Can you please advise me?
Comment 3 Andrew Morton 2011-02-14 23:41:34 UTC
http://www.landley.net/writing/git-quick.html has some pretty nice instructions.
Comment 4 Jay LaCroix 2011-02-15 00:33:40 UTC
I've seen that, but my question is in regards to when I should do a good/bad against network speed. The wireless speed is always a constant issue with the new kernel, there is no time where it works fine (other than the previous kernel), so I'm not sure what a bisection would actually tell you nor how to apply it against a trigger. Please advise specific instructions in regards to this particular issue. (I'm new to kernel debugging).
Comment 5 John W. Linville 2011-02-15 03:11:41 UTC
If the speed is comparable to 2.6.37 then you mark it good, and if not then you mark it bad.  The bisection peels away changes until it (hopefully) finds the one that triggered the problem.
Comment 6 Jay LaCroix 2011-02-15 04:06:23 UTC
Created attachment 47812 [details]
Bisect Log
Comment 7 Jay LaCroix 2011-02-15 04:07:08 UTC
Created attachment 47822 [details]
List of Commands I Executed to Bisect
Comment 8 Jay LaCroix 2011-02-15 04:09:19 UTC
I created and attached two files. To test, I started to play a music video on Youtube. Whenever the download speed dropped to being almost non-existent, I did a "git bisect bad." I matched my "bad" command to the drop in performance, over and over, until it finished.

The bisect.log is the log file I created. The bisect_commands file is the output I got in the terminal while bisecting.
Comment 9 John W. Linville 2011-02-15 14:32:02 UTC
Those logs don't look like you finished yet...?
Comment 10 Jay LaCroix 2011-02-15 22:23:20 UTC
I'm pretty sure I did. Did I do something wrong?
Comment 11 John W. Linville 2011-02-16 01:48:22 UTC
The output from the last 'git bisect bad' says "4 revisions left to test after this (roughly 2 steps)", so it seems like you are missing at least the last two steps.
Comment 12 Jay LaCroix 2011-02-16 03:14:14 UTC
Created attachment 47922 [details]
Newest Bisect Log

Here is the newest Bisect log, hopefully it's better. Sorry about that.
Comment 13 John W. Linville 2011-02-16 14:22:13 UTC
Well, it still doesn't really seem complete.  For one thing, the last commit is in b43...  Also, there is no final pronouncement of "the first bad commit is..."?
Comment 14 Jay LaCroix 2011-02-16 20:46:01 UTC
I really don't know what to say. I ran the bisect until it said that there were 0 commits left to test and then I exported the log. If it's not helpful maybe there's something else I can do to help you? The b43 module coming up is strange, isn't that Broadcom? My wireless card is an Atheros AR5B91. (This laptop normally comes with Broadcom but I replaced it with Atheros due Atheros having better Linux support).
Comment 15 John W. Linville 2011-02-16 21:16:14 UTC
Perhaps you neglected to mark the last commit?
Comment 16 Jay LaCroix 2011-02-16 21:29:08 UTC
How do I mark the last commit?
Comment 17 Stanislaw Gruszka 2011-02-16 21:39:59 UTC
Seems bad commit is 
4df3071ebd92ef7115b409da64d0eb405d24a631 ath9k_hw: optimize interrupt mask changes
since this is last atheros one.

What about reverting it and see if that helps?
Comment 18 Jay LaCroix 2011-02-16 21:59:44 UTC
I'll try anything I can to help, but please keep in mind that I'm a beginner with file bugs against the kernel, so I'm not sure how to revert anything so maybe I may need some hand holding.

Please be advised that my distribution (Arch) currently utilizes 2.6.37. I can't use that kernel because of severe graphics distortion that makes my laptop unusable. I do not have that problem in 2.6.38, but I do have this wireless problem, but that's why I use 2.6.38. I just installed the package "kernel26-mainline" from the AUR repository to install 2.6.38-rc4 so I'm not sure how to alter it. Patching the kernel is beyond my skill level, I just wanted to report this hoping that you guys could fix it.
Comment 19 Jay LaCroix 2011-02-17 03:15:18 UTC
By the way, same problem with rc5. I did a speed test and on wireless I'm getting 0.34Mbps, and when connected via wire I'm getting 10Mbps.
Comment 20 Stanislaw Gruszka 2011-02-17 07:54:05 UTC
Normally reverts are done by "git revert COMMIT". However automatic revert for this one fail because of further code changes. I'll prepare the patch.
Comment 21 Stanislaw Gruszka 2011-02-17 12:37:13 UTC
Created attachment 48122 [details]
test patch

This is not full revert yet. It change some interrupt settings, that I think could be wrong in 4df3071ebd92ef7115b409da64d0eb405d24a631. I don't know if that will help, but please give it a try.
Comment 22 Stanislaw Gruszka 2011-02-17 12:42:56 UTC
(In reply to comment #18)
> Patching the kernel is beyond my skill level, 
Simply do "patch -p1 < patch.file" in kernel source directory.

> I just wanted to report this hoping that you guys could fix it.
I have 8MB/s performance on my ath9k device with .38-rc5. As long none of developers will be able to reproduce problem locally,  we can only fix this relaying on your help.
Comment 23 Jay LaCroix 2011-02-17 13:09:01 UTC
Is the patch command in the kernel source directory all I have to do, and it automatically takes effect? I'll be more than happy to test anything and learn I just want to make sure I know exactly what I should do.
Comment 24 Stanislaw Gruszka 2011-02-17 13:26:47 UTC
You have to recompile kernel, use the same compilation method you used with bisection. I'm using that 

$ make
$ make modules_install
$ make install
$ reboot

Two last steps are not needed if only ath9k module was compiled, after modues installation is enough to reload module to see the effect.
Comment 25 shafi 2011-02-17 15:18:31 UTC
(In reply to comment #24)
> You have to recompile kernel, use the same compilation method you used with
> bisection. I'm using that 
> 
> $ make
> $ make modules_install
> $ make install
> $ reboot
> 
> Two last steps are not needed if only ath9k module was compiled, after modues
> installation is enough to reload module to see the effect.(In reply to comment #22)
> (In reply to comment #18)
> > Patching the kernel is beyond my skill level, 
> Simply do "patch -p1 < patch.file" in kernel source directory.
> 
> > I just wanted to report this hoping that you guys could fix it.
> I have 8MB/s performance on my ath9k device with .38-rc5. As long none of
> developers will be able to reproduce problem locally,  we can only fix this
> relaying on your help.

I also did not see this issue with a 3 stream card with 38-rc3, but need to verify using You tube probably with a 1x1 or 2x2 card
Comment 26 Jay LaCroix 2011-02-17 15:30:38 UTC
It doesn't appear to be working.


[jlacroix@Athena linux-2.6.38-rc5-mainline]$ sudo patch -p1 < ath9k-interrupts-fix.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
|index 180170d..2915b11 100644
|--- a/drivers/net/wireless/ath/ath9k/mac.c
|+++ b/drivers/net/wireless/ath/ath9k/mac.c
--------------------------
File to patch:
Comment 27 Stanislaw Gruszka 2011-02-17 15:56:19 UTC
No idea. Perhaps sudo change directory, or real sources are in some subdirectory of linux-2.6.38-rc5-mainline . Patch apply here with no problems:

[stasiu@dhcp-27-172 linux-2.6]$ patch -p1 < ~/Downloads/ath9k-interrupts-fix.patch 
patching file drivers/net/wireless/ath/ath9k/mac.c
Comment 28 Jay LaCroix 2011-02-17 16:37:05 UTC
I have tried every directory all the way down to the ath9k directory itself, it does not patch.

I really want to help, but unless I'm given clearer directions or some sort of procedure on how to patch this, I cannot assist. I have little to no experience with kernel compilation. I want to learn as much as I can and help in any way I can to make things better for everyone but I think I've done all I can.
Comment 29 Stanislaw Gruszka 2011-02-17 20:17:53 UTC
You have to apply patch in directory where is drivers/net/wireless/ath/ath9k/mac.c file, ls command should show the file is there i.e. :

> [stasiu@localhost linux-2.6]$ ls drivers/net/wireless/ath/ath9k/mac.c 
> drivers/net/wireless/ath/ath9k/mac.c

I'm not sure if in your sources are full. If not just clone fresh tree:

> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> cd linux-2.6/
> patch -p1 < PATH_TO_PATCH/ath9k-interrupts-fix.patch

then complile kernel with old .config

> cp PATH_TO_YOUR_ARCH_KERNEL_SOURCES/.config .config
> make oldconfig
> make 
> sudo make modules_install
> sudo make install
> sudo reboot

I have no idea how could give you more clearer directions, but I'm pretty sure there are lot's of documentations/howtos/tutorials etc... over internet describing how to patch and compile kernel, just find some at google.
Comment 30 Jay LaCroix 2011-02-17 23:06:38 UTC
I did some more testing and I think what I found may change things a bit. 

First, keep in mind that my wireless card and wireless router are both wireless N. With kernel 2.6.37, this combination works perfect.

However...

...I discovered today that if I connect to any router that is strictly wireless G, everything works perfect. I get full speed and Youtube videos work with no problem.

As soon as I connect to a wireless N router, my speed drops so slow it's barely usable.

So, it appears that I only have an issue when utilizing wireless N, and I do not have an issue utilizing wireless G.
Comment 31 Luis R. Rodriguez 2011-02-17 23:13:02 UTC
So this is not a regression? If its not a regression this could be an interoperability issue that needs to be resolved with your AP. Have you checked that the firmware gets the latest firmware? How about the channel utilization around you? If you are using 5 GHz be sure to see how many APs are around you and choose a channel that no one is on. Some APs will do this automatically today.

What band are you using? What model AP? What is an AR5B91 ? What module do you use, ath5k or ath9k ?
Comment 32 Jay LaCroix 2011-02-17 23:33:59 UTC
Of course this is a regression:

2.6.37 on wireless N: Amazing speeds
2.6.38 on wireless N: Little to no speed at all

So it's not a problem with the settings of my router, the range, or the band, since on 2.6.37 there is no issue whatsoever. It's a regression.

To answer your questions: 

The WAP is a D-Link DIR-655. 

AR5B91 is the model of wireless card I have.

The channel is 2417ghz (channel 2)

Encryption is WPA personal

For the module, I use whatever comes up automatically. I haven't and have never set a module, it always "just works" with every Linux kernel until now, which is why I chose this card. In fact I don't know how to set the module. I never had to.
Comment 33 Luis R. Rodriguez 2011-02-18 01:11:55 UTC
OK, thanks for the clarification, provide the output of:

lspci -k
Comment 34 Jay LaCroix 2011-02-18 02:02:35 UTC
00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
        Subsystem: Dell Device 040a
        Kernel driver in use: agpgart-intel
        Kernel modules: intel-agp
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
        Subsystem: Dell Device 040a
        Kernel driver in use: i915
        Kernel modules: i915
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 05)
        Subsystem: Dell Device 040a
        Kernel driver in use: e1000e
        Kernel modules: e1000e
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
        Subsystem: Dell Device 040a
        Kernel driver in use: ehci_hcd
        Kernel modules: ehci-hcd
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)
        Subsystem: Dell Device 040a
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 05)
        Kernel driver in use: pcieport
        Kernel modules: shpchp
00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 05)
        Kernel driver in use: pcieport
        Kernel modules: shpchp
00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 05)
        Kernel driver in use: pcieport
        Kernel modules: shpchp
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 05)
        Subsystem: Dell Device 040a
        Kernel driver in use: ehci_hcd
        Kernel modules: ehci-hcd
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a5)
00:1f.0 ISA bridge: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller (rev 05)
        Subsystem: Dell Device 040a
        Kernel modules: iTCO_wdt
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 6 port SATA AHCI Controller (rev 05)
        Subsystem: Dell Device 040a
        Kernel driver in use: ahci
        Kernel modules: ahci
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 05)
        Subsystem: Dell Device 040a
        Kernel modules: i2c-i801
00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 05)
        Subsystem: Dell Device 040a
        Kernel driver in use: intel ips
        Kernel modules: intel_ips
01:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)
        Subsystem: Foxconn International, Inc. Device e006
        Kernel driver in use: ath9k
        Kernel modules: ath9k
02:00.0 CardBus bridge: Ricoh Co Ltd Device e476 (rev 02)
        Subsystem: Dell Device 040a
        Kernel driver in use: yenta_cardbus
        Kernel modules: yenta_socket
02:00.1 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 03)
        Subsystem: Dell Device 040a
        Kernel driver in use: sdhci-pci
        Kernel modules: sdhci-pci
02:00.4 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 03)
        Subsystem: Dell Device 040a
        Kernel driver in use: firewire_ohci
        Kernel modules: firewire-ohci
3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02)
        Subsystem: Intel Corporation Device 8086
3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02)
        Subsystem: Intel Corporation Device 8086
3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02)
        Subsystem: Intel Corporation Device 8086
3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 02)
        Subsystem: Intel Corporation Device 8086
3f:02.2 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
        Subsystem: Intel Corporation Device 8086
3f:02.3 Host bridge: Intel Corporation Core Processor Reserved (rev 02)
        Subsystem: Intel Corporation Device 8086
Comment 35 Luis R. Rodriguez 2011-02-18 02:25:35 UTC
Thanks, now provide dmesg output. We'll have to reproduce with the same AP. Senthil do you guys have that AP by chance?

J -- you should be able to bisect this though so if you can do that it would be of great help. I still am baffled about your bisect results though. You have:

Bisecting: 4 revisions left to test after this (roughly 2 steps)
[4df3071ebd92ef7115b409da64d0eb405d24a631] ath9k_hw: optimize interrupt mask changes
[jlacroix@Athena linux-git]$ git bisect log > ~/Desktop/bisect.log

as the last item, aren't you missing one more step, the final one? git bisect should tell you the culprit clearly. I don't see that in your output.
Comment 36 Jay LaCroix 2011-02-18 04:50:35 UTC
Created attachment 48262 [details]
Bad Commit from Git Bisect Run

Here is the latest info.
Comment 37 Jay LaCroix 2011-02-18 04:51:21 UTC
Created attachment 48272 [details]
Newest Bisect Log
Comment 38 Jay LaCroix 2011-02-18 04:51:43 UTC
Created attachment 48282 [details]
dmesg output
Comment 39 Luis R. Rodriguez 2011-02-18 17:38:21 UTC
Your result is:

[jlacroix@Athena linux-git]$ git bisect bad
038aaa382eb0a8fd6a0bbae7abc1383b9b57c543 is the first bad commit
commit 038aaa382eb0a8fd6a0bbae7abc1383b9b57c543
Author: Rafał Miłecki <zajec5@gmail.com>
Date:   Thu Oct 14 23:01:02 2010 +0200

    b43: N-PHY: define channel table struct for rev3+ devices
    
    Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

:040000 040000 bae1f2b693dab521a89097d8297591e69a10109a db83a7cb8dd7d5365042a086b8436d8bda74a157 M drivers

It is impossible for this commit to cause issues with your kernel. It is impossible given that the commit is to another driver than the one you are using for your 802.11 device. The driver you use is ath9k, not b43. Apart from this the commit also is not even a functional change to b43.

You can test this theory by doing:

git reset --hard v2.6.38-rc5

Compile, test that kernel. If the issue is still present do:

git revert 038aaa382eb0a8fd6a0bbae7abc1383b9b57c543

Compile, test that kernel and see if the issue is present. If the issue is gone then I need a good vacation.

My suspicion is actually your git tree might not be setup correctly or you are using some odd branch which is not bisectable. What git tree did you clone and what command did you use to clone the tree?

This is the tree and commands you should use to properly get Linus' tree:

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git reset --hard v2.6.38-rc5
Comment 40 Jay LaCroix 2011-02-18 17:51:57 UTC
I did:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
git bisect reset master

And then I proceeded to bisect.
Comment 41 Luis R. Rodriguez 2011-02-18 17:58:03 UTC
Linus' tree as-is is not something I would recommend to test "v2.6.38-rc5" because his tree would have a lot of new patches which may miss some further commits, you want "blessed" RC releases, and to do that you can simply look for the latest tag'd 2.6.38 and use $(git reset --hard v2.6.38-rc5, for example to get you to a pristine RC release.

You can see the delta from the respective upstream RC release with git describe, it'll tell you how many extra patches on top of the last tagged release have been integrated since then, so do:

git describe

and provide the output of that.

So if testing v2.6.38-rc5, please ensure to:

git reset --hard v2.6.38-rc5
Comment 42 Ryan Voots 2011-03-08 08:00:23 UTC
I too have had this issue (at least I suspect it is) and went and did a bisect.  

I've got an AR9285 in my laptop, I don't see it drop to completely unusual speeds usually but it does go to about 25-50KiB/s.

I started the bisect by doing it on just drivers/net/wireless/ath to try to narrow it down a little faster for me.  Trying with the last good and last bad commits without the directory restriction spews out that that it's already got the first bad commit for me.

I did have to skip the very first commit it went to because it didn't want to compile completely, after that I ran into no issues.
Comment 43 Ryan Voots 2011-03-08 08:02:11 UTC
Created attachment 50292 [details]
Bisect log

aforementioned bisect log
Comment 44 Ryan Voots 2011-03-08 09:02:23 UTC
doing a git checkout v2.6.38-rc7 and reverting that specific commit results in expected performance for me.
Comment 45 shafi 2011-03-08 12:12:11 UTC
(In reply to comment #44)
> doing a git checkout v2.6.38-rc7 and reverting that specific commit results in
> expected performance for me.

Hi can you please mention commit id explicitly that solves this issue.
thanks,
shafi
Comment 46 John W. Linville 2011-03-08 14:29:14 UTC
Yeah, your bisect log seems incomplete -- there should be something like "the first bad commit is..."

The last one you marked bad in the log above is 1c30cc19081c16b1fe73ac13f2cb2abc009cdcc4.  Is that the one you reverted?
Comment 47 Ryan Voots 2011-03-08 18:49:43 UTC
Sorry about that it was late, I must have missed that it wasn't in the log.

1c30cc19081c16b1fe73ac13f2cb2abc009cdcc4 is the first bad commit
commit 1c30cc19081c16b1fe73ac13f2cb2abc009cdcc4
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Tue Dec 28 15:46:16 2010 +0100

    ath9k_hw: fix dma descriptor rx error bit parsing
    
    An Rx DMA descriptor can have multiple error bits set, and some error
    bits (e.g. MIC failure) are filtered by the driver based on other criteria.
    Remove the 'else' in various error bit checks so that all error information
    is properly passed to the driver.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

:040000 040000 0f86e9ffe61bc32d7a8e5da99b9506507082519f 09c3f042ef7db09630fd09157d77dfc3ffe81548 M      drivers

That's the output.  I reverted that commit and got the previous performance.  I've also noticed this morning that I no longer see another symptom of this.  With 1c30cc... iwconfig would report extraordinarily high "Invalid misc:" on the order of 25-50 thousand after a few minutes.  Now it's a relatively constant 85-90 (not thousand) again.  The only thing I can guess in my uninformed opinion is that something is being interpreted as a packet with an error when it shouldn't be.
Comment 48 shafi 2011-03-09 05:49:01 UTC
now this is there which almost reverts it?
commit 115dad7a7f42e68840392767323ceb9306dbdb36
Author: Felix Fietkau <nbd@openwrt.org>
Date:   Fri Jan 14 00:06:27 2011 +0100

    ath9k_hw: partially revert "fix dma descriptor rx error bit parsing"
    
    The rx error bit parsing was changed to consider PHY errors and various
    decryption errors separately. While correct according to the documentation,
    this is causing spurious decryption error reports in some situations.
    
    Fix this by restoring the original order of the checks in those places,
    where the errors are meant to be mutually exclusive.
    
    If a CRC error is reported, then MIC failure and decryption errors
    are irrelevant, and a PHY error is unlikely.
    
    Signed-off-by: Felix Fietkau <nbd@openwrt.org>
    Signed-off-by: John W. Linville <linville@tuxdriver.com>
Comment 49 Ryan Voots 2011-03-09 07:44:27 UTC
I think that could be the issue.  That commit doesn't appear to be in the mainline tree at the moment.  Personally I'd support a call to pulling at least that fix into the mainline kernel for 2.6.38 or this driver seems to be unusable.
Comment 50 John W. Linville 2011-03-09 14:42:30 UTC
Could you apply that patch and report the results here?  Thanks!
Comment 51 Ryan Voots 2011-03-09 20:19:52 UTC
That commit from wireless-testing also works for me.  I'm curious if the original commitor could try it too.
Comment 52 Garri 2011-05-11 08:58:21 UTC
Same problems for me.

03:00.0 Network controller: Atheros Communications Inc. AR9287 Wireless Network Adapter (rev 01)
	Subsystem: Foxconn International, Inc. Device e034
	Kernel driver in use: ath9k
	Kernel modules: ath9k

kernel:2.6.38-gentoo-r3

Git kernel v2.6.39-rc6 didn't helped



Using kernel-2.6.37-gentoo-r4 problem resolved.
Comment 53 John W. Linville 2011-06-28 18:11:09 UTC
Based on the confirmation (and cooperation) from Ryan Voots, I'm closing this one.  If you believe you are still experiencing a similar issue, then please open a new bug with a more specific description of exactly the problem you observe.

Note You need to log in before you can comment on or make changes to this bug.