Description of problem: When using the carl9170 wireless driver, the wireless connection is unstable. Especially under load, I'm often disconnected from my wireless router. Version-Release number of selected component (if applicable): kernel: 3.4.0-1.fc17.x86_6 (but I had the same problems with F16, too. It's been going on for at least a month). firmware API: 1.9.5 2012-03-14 How reproducible: Somewhat reproducible by establishing a wireless connection and putting some load on it Steps to Reproduce: 1. Establish wireless connection 2. Put load on it Actual results: Connection will break down within a couple of minutes. Although it will be re-established, VPN/IRC connections and currently running downloads may not survive this. Expected results: No disconnect. Additional info: Router/access point: a wireless N-draft router. I admit that it's crappy, but it should be possible to establish stable connections with it, as other hardware and operating systems have no problems whatsoever. wireless hardware using the carl9170 driver: ID 0cf3:1002 Atheros Communications, Inc. TP-Link TL-WN821N v2 802.11n [Atheros AR9170] If you load the module with noht=1 and nohwcrypt=1, it's slightly more stable. I can see messages like the following (especially when running noht=1): [13548.136457] ieee80211 phy2: invalid plcp cck rate (0). [13597.224429] ieee80211 phy2: invalid plcp cck rate (0). [13601.512838] ieee80211 phy2: invalid plcp cck rate (0). With HT enabled, these messages mentioned above do not seem to occure that often, but instead I'm seeing more messages like the following: [13215.559590] ieee80211 phy2: channel change: 2432 -> 2437 failed (2). [13215.844041] ieee80211 phy2: channel change: -1 -> 2437 failed (2). [13215.844044] usb 3-1.2: restart device (7) [13216.983593] usb 3-1.2: device restarted successfully. [13216.988414] ieee80211 phy2: Hardware restart was requested So far, my best guess is that this is related to (I've actually copy+pasted the messages from this thread, but they are so similar to mine that there should be no relevant difference): http://www.spinics.net/lists/linux-wireless/msg91621.html However, I'm not sure about that.
Is this still an issue with 3.6.9 kernels?
Actually, I don't really know. I've moved and no longer have access to my former router. I'm currently running 3.6.9-2.fc17.x86_64 and it works without any problems. However, my current router is an old Linksys WRT54G with Linux firmware, which may very well be the reason why I don't see any problems, especially since it doesn't support the n-standard. I'll start running older pre-3.6.9 kernels to see if I can reproduce the problem with my current hardware setup. My ISP will change on Friday and a part of that change will be a switch from the wrt54g to a generic ISP-branded N-standard router. If all goes well, I'll run some further tests with the new router over the weekend and will post some results on Monday.
Any update?
Unfortunately, the problem still remains - symptoms and log output are essentially the same.
Created attachment 691822 [details] Latest carl9170 1.9.7+ firmware
The attached firmware is hot of git HEAD. Hopefully, it survives longer than previous releases. [ That said: don't expect a miracle. How the hardware works is still a mystery, since the available documentation doesn't cover the subject of "error detection and recovery". So a lot of trail and error is involved. ] About: [13548.136457] ieee80211 phy2: invalid plcp cck rate (0). [13597.224429] ieee80211 phy2: invalid plcp cck rate (0). [13601.512838] ieee80211 phy2: invalid plcp cck rate (0). These errors occures when the internal rx fifo overflows (usually, this happens when there's a lot of traffic... I wonder why ;) ). As a result the rx dma engine gets confused and pushes garbage to the host. Other Atheros hardware suffers from similar issues, altough they call it "DMA failed to stop / Could not stop RX" <https://dev.openwrt.org/ticket/9654>.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.