RPI3B+ on board ethernet issue (NFS/SCP ...)

[pfrenard]

Is this the right place for my bug report?
My issue is the same as #2482 or #2449
I am using Fedora 31 with kernel 5.4.7 (5.4.7-200.fc31.aarch64) running aarch64.

Describe the bug
when doing a huge transfer using cp on NFS or scp, after more than 1GB upload, upload hangs and failed after a few minutes.

To reproduce

dd if=/dev/zero of=/tmp/data.dd bs=4M count=1000 status=progress
scp /tmp/data.dd login@server:/directory

Expected behaviour
fully transfered file

Actual behaviour
hangs after 1GB and failed after a few minutes

System

• Which model of Raspberry Pi? Pi3B+
• Which OS and version (cat /etc/rpi-issue)? Fedora 31,
• Which firmware version (vcgencmd version)? no vcgencmd on the system
• Which kernel version (uname -a)? 5.4.7-200.fc31.aarch64, Aarch64

Logs
None

Additional context
None

[lategoodbye]

Unfortunately you ignored my suggestion to report this issue to the linux-netdev mailing list.
Could you please explain why?

[pelwell]

Repeat the test on a current Raspbian image and report back.

[pfrenard]

I am not able to reproduce the issue with Raspbian.
If I understand well, Raspbian includes a kernel patch that disables TSO by default, and TSO enabled was the reason of this issue.

[lategoodbye]

Yes, it's the commit 5f0e4c1 i linked in my email on arm@lists.fedoraproject.org.

[JamesH65]

Not sure why this is being reported here, clearly it's a Fedora/other problem and should be reported on the appropriate bug tracker?

[lategoodbye]

Fedora doesn't have the resources to fixes this issue. It should be reported to linux-netdev, as i already wrote before.

[pfrenard]

I reported the issue to the mailing list.
The idea was to let you know that the patch is not available for all distro/kernel.

[pelwell]

I reported the issue to the mailing list.
The idea was to let you know that the patch is not available for all distro/kernel.

Then you should have said so in your report instead of waiting for us to drag it out of you.

[pelwell]

Eric Dumazet has submitted a patch for this upstream - we'll back-port it once it gets merged.

[6by9]

It'll be interesting to test, but I'm not sure it is the cause.

My recollection is as per #2482 (comment) / #2449 (comment)

Should an offloaded packet get dropped (potentially due to skb_linearize failing), then it is never retransmitted, so the other end keeps sending a TCP Selective ACK back reporting the missing section. This continued until it got to the end of the file and still hadn't had the missing section, at which point it stalled.
I think Eric's patch is only dealling with a resource leak, but we'll see.

[pfrenard]

I confirm that this is not solving the issue. :(
I tried on the last kernel 5.5.0.rc5.git0.1.fc32.aarch64 from fedora.

[lategoodbye]

Maybe this fixes at least #2928