Bug 1716334
| Summary: | File copy through network hangs using kernel 5.1.x and Wi-Fi | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Didier G <didierg-divers> | ||||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 30 | CC: | airlied, bskeggs, carwyn, hdegoede, ichavero, itamar, jarodwilson, jcline, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, luca, mchehab, mjg59, sgruszka, steved | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | kernel-5.1.17-300.fc30 kernel-5.1.18-200.fc29 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2019-07-15 00:56:41 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
Didier G
2019-06-03 09:04:22 UTC
I did additional tests using USB-Ethernet adapter and Wi-Fi disabled on laptop. In this configuration, with kernel 5.1.6 and with Ethernet cable, copy work fine from laptop to desktop using sftp or sshfs. Wi-Fi adapter on laptop is: 02:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) Subsystem: Intel Corporation Dual Band Wireless-AC 7265 Flags: bus master, fast devsel, latency 0, IRQ 128 Memory at dfa00000 (64-bit, non-prefetchable) [size=8K] Capabilities: [c8] Power Management version 3 Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [40] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Device Serial Number 00-21-5c-ff-ff-af-3a-1b Capabilities: [14c] Latency Tolerance Reporting Capabilities: [154] L1 PM Substates Kernel driver in use: iwlwifi Kernel modules: iwlwifi I just upgraded to kernel 5.1.7 and I have exactly the same problem. I did new tests on my Asus ZenBook UX305 laptop. To do these tests, I specially built an up-to-date Fedora 30 LiveCD including all updates and kernel 5.1.6. Booting on this up-to-date LiveCD, I can connect to my box using 2.4 GHz or 5 GHz WiFi. For the test I tried to transfer a Fedora ISO from my laptop to my desktop simply using scp. If I am connected using 2.4 GHz, the scp transfer completes with no problem. If I am connected using 5 GHz, the scp transfer "hangs" - the transfer stops - after few second and it never complete In this case - hang using 5 GHz - I cancel the transfer using <Ctl><C>. After this cancel, I cannot restart a new transfer. I have to switch from 5 GHz to 2.4 GHz and back to be able to restart a new scp transfer using 5 GHz. During these tests I get no messages in journalctl. As I previous said, everything work fine using 5.0.17 kernel and previous. I don't know if somebody is interested by this problem or even already had a look on it but I continue to document it ! I just upgrade to kernel 5.1.11. As with all 5.1.x kernel I am unable to transfer file using wifi, transfer freezes after few octets. Using kernel 5.1.x I can transfer file only using Ethernet cable. Using kernel 5.0.x I can transfer file with no problem using Wifi or cable. In MY configuration - ASUS Zenbook UX305 - there is definitely a problem with kernel 5.1.x and WiFi. Could you install kernel-debug and try to copy files on it? Perhaps -debug kernel variant will print some hint why system hung. I did a new test with kernel-5.2.0-0.rc6.git1.1.fc31.x86_64 who have debug enabled. With this kernel 5.2 scp hangs like with 5.1 I send two scp log, the first one successful using 5.0.14 and the second who hanged using 5.2. Created attachment 1585149 [details]
successful scp using kernel 5.0.14
Created attachment 1585150 [details]
Failed scp using kernel 5.2
Maybe I did not understand. System hung or file copy hung but system is still running? File copy - scp, sftp, sshfs - hung but system is still running. Ok, this looks like iwlwifi driver (or maybe firmware issue) . No dmesg? Nothing? how do you know it is a WiFi problem? ah now I see that you way it works with a cable. Stanislaw, as you can imagine, we can't really do anything without the minimum information. The minimum is dmesg output. Well, I thought dmesg output was already provided. Anyway, what is requested is run 'dmesg > dmesg.txt' command after wifi file copy failure and attach dmesg.txt file here. Created attachment 1587205 [details]
dmesg
Apologizes for the delay.
Can you please try this: https://patchwork.kernel.org/patch/11029027/ (In reply to Emmanuel Grumbach from comment #16) > Can you please try this: > > https://patchwork.kernel.org/patch/11029027/ Bingo ! Patched kernel works fine. Now I wait for a future kernel version with this patch applied. Thanks for your work. But why TX A-MSDU worked on 5.0 ? As long A-MSDU was not created by network stack on 5.0 and start to be created in 5.1, this really look like workaround not proper fix. Tx A-MSDU were not enabled in 5.0. Until 5.1 iwlwifi didn't use iTXQ which is a prerequisite for A-MSDU in mac80211. I test the patch above since two days and it does the job. Can I suggest to fedora maintainers to port it on 5.1.16 and build a 5.1.16-301 to fix the problem for users of old NICs who encounter this issue ? I've picked up the proposed patch for the 5.1.17 build so it should be in updates-testing in the next couple days. Fixed in kernel 5.1.17. You can close this bug. Thanks to all for your work. FEDORA-2019-20b9691305 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-20b9691305 kernel-5.1.17-300.fc30, kernel-headers-5.1.17-300.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-652cbd5ec1 kernel-5.1.17-200.fc29, kernel-headers-5.1.17-200.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-20b9691305 kernel-5.1.17-300.fc30, kernel-headers-5.1.17-300.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report. FEDORA-2019-a95015e60f has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a95015e60f I can confirm that kernel-5.1.17-300.fc30.x86_64 fixes the Tx jamming issue on: Network controller: Intel Corporation Wireless 7265 (rev 59) kernel-5.1.18-200.fc29, kernel-headers-5.1.18-200.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a95015e60f kernel-5.1.18-200.fc29, kernel-headers-5.1.18-200.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |