1. Please describe the problem: File copy (different methods) through network hangs 2. What is the Version-Release number of the kernel: kernel 5.1.6, 5.1.5, 5.1.4, 5.1.1 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 : Problem appear with kernel 5.1.1 No problem with kernel 5.0.17 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Install a 5.1.x kernel Try to copy file between two machines 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``: Problem occurs with kernel 5.1.1 and following until 5.1.6 6. Are you running any modules that not shipped with directly Fedora's kernel?: Only VirtualBox from Oracle site (not RPMfusion) 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. Additional info: I have two machines: - a desktop: Asus P8Z77-V LE, Intel(R) Core(TM) i7-3770, 16 GB memory - a laptop: Asus ZenBook UX305UA, Intel(R) Core(TM) i7-6500U, 8 GB memory Desktop is connected to my box using ethernet cable and laptop is connected to the same box using Wi-Fi Since years I copied files between these two machines in both directions. This worked fine with kernel 5.0.17 and all previous. With kernel 5.1.1 and following, copy works fine from desktop to laptop but hang from laptop to desktop. From laptop to desktop, file is created on desktop but only few blocks are copied then after copy hangs. I tried following methods with same results: - sftp mount of desktop fs on laptop then copy using nautilus drag and drop - sshfs mount of destop fs on laptop then copy using cp command - copy from laptop to desktop using scp command on laptop - copy from laptop to desktop using scp command on desktop From laptop to desktop all hang after few blocks. All methods work fine to copy same files from desktop to laptop. Usinf sftp, I also try to play a movie located on laptop using mpv on desktop. It works and I can move backward and forward in this movie with no problem BUT copy of this movie from laptop to desktop hang !
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.