Bug 831953

Summary: carl9170: unstable wireless connection
Product: [Fedora] Fedora Reporter: Stefan Cornelius <scorneli>
Component: kernelAssignee: John Greene <jogreene>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: chunkeey, gansalmon, itamar, jforbes, jonathan, kernel-maint, linville, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-01 01:24:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Latest carl9170 1.9.7+ firmware none

Description Stefan Cornelius 2012-06-14 07:35:53 UTC
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.

Comment 1 Justin M. Forbes 2012-12-07 16:42:43 UTC
Is this still an issue with 3.6.9 kernels?

Comment 2 Stefan Cornelius 2012-12-11 10:59:16 UTC
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.

Comment 3 Josh Boyer 2013-01-02 13:19:37 UTC
Any update?

Comment 4 Stefan Cornelius 2013-01-07 08:00:47 UTC
Unfortunately, the problem still remains - symptoms and log output are essentially the same.

Comment 5 chunkeey 2013-02-02 00:53:38 UTC
Created attachment 691822 [details]
Latest carl9170 1.9.7+ firmware

Comment 6 chunkeey 2013-02-02 01:16:28 UTC
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>.

Comment 7 Fedora End Of Life 2013-07-03 23:03:54 UTC
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.

Comment 8 Fedora End Of Life 2013-08-01 01:24:33 UTC
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.