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.
Perhaps you could do a git bisect?
I'm not really familiar how to do a bisect against wireless speed. Can you please advise me?
http://www.landley.net/writing/git-quick.html has some pretty nice instructions.
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).
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.
Created attachment 47812 [details] Bisect Log
Created attachment 47822 [details] List of Commands I Executed to Bisect
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.
Those logs don't look like you finished yet...?
I'm pretty sure I did. Did I do something wrong?
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.
Created attachment 47922 [details] Newest Bisect Log Here is the newest Bisect log, hopefully it's better. Sorry about that.
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..."?
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).
Perhaps you neglected to mark the last commit?
How do I mark the last commit?
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?
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.
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.
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.
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.
(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.
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.
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 #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
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:
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
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.
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.
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.
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 ?
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.
OK, thanks for the clarification, provide the output of: lspci -k
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
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.
Created attachment 48262 [details] Bad Commit from Git Bisect Run Here is the latest info.
Created attachment 48272 [details] Newest Bisect Log
Created attachment 48282 [details] dmesg output
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
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.
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
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.
Created attachment 50292 [details] Bisect log aforementioned bisect log
doing a git checkout v2.6.38-rc7 and reverting that specific commit results in expected performance for me.
(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
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?
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.
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>
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.
Could you apply that patch and report the results here? Thanks!
That commit from wireless-testing also works for me. I'm curious if the original commitor could try it too.
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.
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.