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 - File copy through network hangs using kernel 5.1.x and Wi-Fi
Summary: File copy through network hangs using kernel 5.1.x and Wi-Fi
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 30
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-06-03 09:04 UTC by Didier G
Modified: 2019-07-19 03:06 UTC (History)
20 users (show)

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:
Clone Of:
Environment:
Last Closed: 2019-07-15 00:56:41 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
successful scp using kernel 5.0.14 (4.93 KB, application/octet-stream)
2019-06-27 13:00 UTC, Didier G
no flags Details
Failed scp using kernel 5.2 (4.29 KB, text/plain)
2019-06-27 13:02 UTC, Didier G
no flags Details
dmesg (89.69 KB, text/plain)
2019-07-03 23:01 UTC, Didier G
no flags Details

Description Didier G 2019-06-03 09:04:22 UTC
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 !

Comment 1 Didier G 2019-06-03 10:23:57 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

Comment 2 Didier G 2019-06-04 17:29:24 UTC
I just upgraded to kernel 5.1.7 and I have exactly the same problem.

Comment 3 Didier G 2019-06-08 13:19:57 UTC
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.

Comment 4 Didier G 2019-06-18 12:38:47 UTC
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.

Comment 5 Stanislaw Gruszka 2019-06-25 12:24:12 UTC
Could you install kernel-debug and try to copy files on it? Perhaps -debug kernel variant will print some hint why system hung.

Comment 6 Didier G 2019-06-27 12:59:03 UTC
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.

Comment 7 Didier G 2019-06-27 13:00:56 UTC
Created attachment 1585149 [details]
successful scp using kernel 5.0.14

Comment 8 Didier G 2019-06-27 13:02:00 UTC
Created attachment 1585150 [details]
Failed scp using kernel 5.2

Comment 9 Stanislaw Gruszka 2019-06-28 08:13:04 UTC
Maybe I did not understand. System hung or file copy hung but system is still running?

Comment 10 Didier G 2019-06-28 08:33:25 UTC
File copy - scp, sftp, sshfs - hung but system is still running.

Comment 11 Stanislaw Gruszka 2019-07-02 09:21:25 UTC
Ok, this looks like iwlwifi driver (or maybe firmware issue) .

Comment 12 Emmanuel Grumbach 2019-07-02 10:16:01 UTC
No dmesg? Nothing?
how do you know it is a WiFi problem?

Comment 13 Emmanuel Grumbach 2019-07-02 10:23:18 UTC
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.

Comment 14 Stanislaw Gruszka 2019-07-03 03:40:45 UTC
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.

Comment 15 Didier G 2019-07-03 23:01:32 UTC
Created attachment 1587205 [details]
dmesg

Apologizes for the delay.

Comment 16 Emmanuel Grumbach 2019-07-04 04:19:58 UTC
Can you please try this:

https://patchwork.kernel.org/patch/11029027/

Comment 17 Didier G 2019-07-04 21:18:00 UTC
(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.

Comment 18 Stanislaw Gruszka 2019-07-05 08:50:44 UTC
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.

Comment 19 Emmanuel Grumbach 2019-07-05 09:02:43 UTC
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.

Comment 20 Didier G 2019-07-07 12:12:31 UTC
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 ?

Comment 21 Jeremy Cline 2019-07-08 20:12:27 UTC
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.

Comment 22 Didier G 2019-07-11 01:58:15 UTC
Fixed in kernel 5.1.17.

You can close this bug.

Thanks to all for your work.

Comment 23 Fedora Update System 2019-07-11 04:07:26 UTC
FEDORA-2019-20b9691305 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-20b9691305

Comment 24 Fedora Update System 2019-07-12 02:15:38 UTC
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

Comment 25 Fedora Update System 2019-07-12 06:09:27 UTC
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

Comment 26 Fedora Update System 2019-07-15 00:56:41 UTC
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.

Comment 27 Fedora Update System 2019-07-16 13:23:13 UTC
FEDORA-2019-a95015e60f has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-a95015e60f

Comment 28 Carwyn Edwards 2019-07-16 21:54:51 UTC
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)

Comment 29 Fedora Update System 2019-07-17 02:06:15 UTC
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

Comment 30 Fedora Update System 2019-07-19 03:06:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.