Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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. |