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.
Created attachment 1555360 [details] kernel messages from 4.20.14
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.
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.
The issue persists with 5.1.17-200.fc29.x86_64.
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
Here is a similar report by someone else: https://bbs.archlinux.org/viewtopic.php?id=247750
*********** 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.
*********** 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.
Still happens on the latest F29 kernel...I'll update to F30 or F31 soon and test again.
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.
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.