1. Please describe the problem: The ethernet speed drops to 100Mbps if there's low traffic. It jumps up to 1Gbps if I utilize the interface more and jumps back after some time of 'idle' load. This jumping would not be normally an issue if the data flow was not affected during the switch (both directions). I see some drop-offs during e.g. video call which is not really nice. I have Lenovo t480s. It happens on internal and the TB3 dock port as well. 2. What is the Version-Release number of the kernel: # uname -a Linux sopos.local 5.12.10-300.fc34.x86_64 #1 SMP Thu Jun 10 14:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # rpm -q NetworkManager NetworkManager-1.30.4-1.fc34.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue Not sure, I suspect it was always weird. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: a. make sure the IF is at 100Mbps (e.g. ethtool ens1u1) b. copy some larger file (1GB) over the network from e.g. samba c. the data transfer starts at 100Mbps, at some point the speed jumps to 1Gbps d. wait approximattely 1 minute e. check the speed is back at 100Mbps 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``: haven't try yet 6. Are you running any modules that not shipped with directly Fedora's kernel?: no 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. dub 27 19:13:04 kernel: r8152 6-1:1.0 ens1u1: carrier off dub 27 19:13:07 kernel: r8152 6-1:1.0 ens1u1: carrier on dub 27 19:58:05 kernel: r8152 6-1:1.0 ens1u1: carrier off dub 27 19:58:08 kernel: r8152 6-1:1.0 ens1u1: carrier on dub 27 20:39:56 kernel: r8152 6-1:1.0 ens1u1: carrier off dub 27 20:39:58 kernel: r8152 6-1:1.0 ens1u1: carrier on dub 27 20:41:06 kernel: r8152 6-1:1.0 ens1u1: carrier off dub 27 20:41:09 kernel: r8152 6-1:1.0 ens1u1: carrier on dub 27 20:45:02 kernel: r8152 6-1:1.0 ens1u1: carrier off dub 27 20:45:12 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 100 Mbps Half Duplex, Flow Control: Rx/Tx dub 27 20:45:12 kernel: e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO dub 27 20:45:12 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Down dub 27 20:45:15 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None dub 27 20:45:15 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s31f6: link becomes ready dub 27 20:45:18 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx dub 27 20:48:59 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx dub 27 20:49:59 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx dub 27 20:49:59 kernel: e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO dub 27 20:50:29 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx dub 27 20:51:40 kernel: e1000e 0000:00:1f.6 enp0s31f6: NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx dub 27 20:51:40 kernel: e1000e 0000:00:1f.6 enp0s31f6: 10/100 speed: disabling TSO $ journalctl --no-hostname -k | tail čen 18 04:20:56 kernel: r8152 6-1:1.0 ens1u1: carrier off čen 18 04:20:59 kernel: r8152 6-1:1.0 ens1u1: carrier on čen 18 06:13:08 kernel: r8152 6-1:1.0 ens1u1: carrier off čen 18 06:13:11 kernel: r8152 6-1:1.0 ens1u1: carrier on čen 18 06:15:29 kernel: r8152 6-1:1.0 ens1u1: carrier off čen 18 06:15:32 kernel: r8152 6-1:1.0 ens1u1: carrier on What I tried: 1. ethtool -s ens1u1 autoneg off speed 1000 2. echo on > /sys/class/net/ens1u1/power/control 3. setting the autoneg to manual and speed to 1Gb/s in NM 4. sysctl vm.laptop_mode=0 None of those variants work long term - it reverts back to a "power safe" schema after a while. I was trying based on what I googled: https://askubuntu.com/questions/1226192/how-can-i-disable-the-ethernet-card-power-saving https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-power https://wiki.gentoo.org/wiki/Power_management/Ethernet
Looks like the issue is gone. Can somebody confirm there's a intentional fix? # uname -a Linux sopos.local 5.12.6-200.fc33.x86_64 #1 SMP Sat May 22 20:43:23 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # rpm -q NetworkManager NetworkManager-1.26.8-1.fc33.x86_64
it's back # uname -a Linux sopos.local 5.12.8-200.fc33.x86_64 #1 SMP Sat May 29 18:09:27 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # rpm -q NetworkManager NetworkManager-1.26.8-1.fc33.x86_64
so currently it is jumping back and forth even on 5.12.6-200.fc33.x86_64 so I'm not sure what makes the differentce
same on F34 # uname -a Linux sopos.local 5.12.10-300.fc34.x86_64 #1 SMP Thu Jun 10 14:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux # rpm -q NetworkManager NetworkManager-1.30.4-1.fc34.x86_64
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.