Bug 1700110

Summary: AR9485 random hangs with ath9k on all kernels newer than 4.20.13
Product: [Fedora] Fedora Reporter: Charles R. Anderson <cra>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 29CC: airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, mchehab, mjg59, steved
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-11-27 23:26:17 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
kernel messages from 4.20.14 none

Description Charles R. Anderson 2019-04-15 21:34:12 UTC 
1. Please describe the problem:

Downloads hang over wireless.

2. What is the Version-Release number of the kernel:
kernel-4.20.14-200.fc29.x86_64
through
kernel-5.0.7-200.fc29.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
kernel-4.20.13-200.fc29.x86_64


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:

- Boot kernel 4.20.13
- Make sure Wi-Fi is connected and wired ethernet is disconnected.
- Repeatedly run this: rm -rf evince ; git clone https://github.com/GNOME/evince.git
- The git clone should finish to 100% every time.

- Boot any kernel 4.20.14 through 5.0.7.
- Make sure Wi-Fi is connected and wired ethernet is disconnected.
- Repeatedly run this: rm -rf evince ; git clone https://github.com/GNOME/evince.git
- Usually after 1-3 runs, git clone hangs at less than 100% complete.
- Ctrl-C and rerun the git clone.  Now it hangs right away.
- Sometimes "ping" stops responding to the default gateway (wi-fi router).


5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
No, it does not happen with:
kernel-5.1.0-0.rc4.git4.1.fc31.x86_64

6. Are you running any modules that not shipped with directly Fedora's kernel?:
No.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
Comment 1 Charles R. Anderson 2019-04-15 21:34:51 UTC 
Created attachment 1555360 [details]
kernel messages from 4.20.14
Comment 2 Charles R. Anderson 2019-04-15 21:37:00 UTC 
To be clearer, kernel-4.20.13 works fine, kernel-4.20.14 and newer fail, all kernel-5.0.x fail, and 5.1.0-0.rc4.git4.1 works fine.
Comment 3 Charles R. Anderson 2019-05-07 14:48:01 UTC 
I've been using kernel-5.1.0-0.rc5.git2.1.fc31.x86_64 lately, and noticed it was hanging as well.  I also tried kernel-5.1.0-1.fc31.x86_64 and kernel-5.0.11-200.fc29.x86_64 and those both have the hanging problem too.  I've gone back to kernel-4.20.13-200.fc29.x86_64 and have not had any hangs.
Comment 4 Charles R. Anderson 2019-07-18 13:14:57 UTC 
The issue persists with 5.1.17-200.fc29.x86_64.
Comment 5 Charles R. Anderson 2019-07-18 13:20:55 UTC 
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)
        Subsystem: Lite-On Communications Inc Device 6628
        Flags: bus master, fast devsel, latency 0, IRQ 17
        Memory at f7d00000 (64-bit, non-prefetchable) [size=512K]
        Expansion ROM at f7d80000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 2
        Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
        Capabilities: [70] Express Endpoint, MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
        Kernel driver in use: ath9k
        Kernel modules: ath9k

The hang and loss of connecitivty happened here I believe:

Jul 18 08:25:40 a kernel: ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02000020 DMADBG_7=0x0000a400
Jul 18 08:25:41 a kernel: wlp2s0: authenticate with 00:25:9c:13:46:7d
Jul 18 08:25:41 a kernel: wlp2s0: send auth to 00:25:9c:13:46:7d (try 1/3)
Jul 18 08:25:41 a kernel: wlp2s0: authenticated
Jul 18 08:25:41 a kernel: wlp2s0: associate with 00:25:9c:13:46:7d (try 1/3)
Jul 18 08:25:41 a kernel: wlp2s0: RX AssocResp from 00:25:9c:13:46:7d (capab=0x31 status=0 aid=2)
Jul 18 08:25:41 a kernel: wlp2s0: associated
Jul 18 08:25:41 a kernel: ath: EEPROM regdomain: 0x8348
Jul 18 08:25:41 a kernel: ath: EEPROM indicates we should expect a country code
Jul 18 08:25:41 a kernel: ath: doing EEPROM country->regdmn map search
Jul 18 08:25:41 a kernel: ath: country maps to regdmn code: 0x3a
Jul 18 08:25:41 a kernel: ath: Country alpha2 being used: US
Jul 18 08:25:41 a kernel: ath: Regpair used: 0x3a
Jul 18 08:25:41 a kernel: ath: regdomain 0x8348 dynamically updated by country element

At this point, I noticed the connectivity loss and used NetworkManager to turn off Wi-Fi and turn it back on again which seems to resolve the issue:

Jul 18 08:27:10 a kernel: wlp2s0: deauthenticating from 00:25:9c:13:46:7d by local choice (Reason: 3=DEAUTH_LEAVING)
Jul 18 08:27:18 a kernel: wlp2s0: authenticate with 00:25:9c:13:46:7d
Jul 18 08:27:18 a kernel: wlp2s0: send auth to 00:25:9c:13:46:7d (try 1/3)
Jul 18 08:27:18 a kernel: wlp2s0: authenticated
Jul 18 08:27:18 a kernel: wlp2s0: associate with 00:25:9c:13:46:7d (try 1/3)
Jul 18 08:27:18 a kernel: wlp2s0: RX AssocResp from 00:25:9c:13:46:7d (capab=0x31 status=0 aid=2)
Jul 18 08:27:18 a kernel: wlp2s0: associated
Jul 18 08:27:18 a kernel: ath: EEPROM regdomain: 0x8348
Jul 18 08:27:18 a kernel: ath: EEPROM indicates we should expect a country code
Jul 18 08:27:18 a kernel: ath: doing EEPROM country->regdmn map search
Jul 18 08:27:18 a kernel: ath: country maps to regdmn code: 0x3a
Jul 18 08:27:18 a kernel: ath: Country alpha2 being used: US
Jul 18 08:27:18 a kernel: ath: Regpair used: 0x3a
Jul 18 08:27:18 a kernel: ath: regdomain 0x8348 dynamically updated by country element
Jul 18 08:27:18 a kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
Comment 6 Charles R. Anderson 2019-07-18 13:25:12 UTC 
Here is a similar report by someone else:

https://bbs.archlinux.org/viewtopic.php?id=247750
Comment 7 Justin M. Forbes 2019-08-20 17:41:42 UTC 
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 29 kernel bugs.

Fedora 29 has now been rebased to 5.2.9-100.fc29.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 30, and are still experiencing this issue, please change the version to Fedora 30.

If you experience different issues, please open a new bug report for those.
Comment 8 Justin M. Forbes 2019-09-17 20:05:26 UTC 
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Comment 9 Charles R. Anderson 2019-09-17 20:18:04 UTC 
Still happens on the latest F29 kernel...I'll update to F30 or F31 soon and test again.
Comment 10 Ben Cotton 2019-10-31 18:50:01 UTC 
This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
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 EOL if it remains open with a
Fedora 'version' of '29'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 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 this bug is closed as described in the policy above.

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 11 Ben Cotton 2019-11-27 23:26:17 UTC 
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.