Massive network problems with I219-V on Thinkpad T14 Gen2 (e1000e)

Bug #1927925 reported by Roland Sommer
This bug report is a duplicate of:  Bug #1930754: e1000e extremly slow. Edit Remove
54
This bug affects 9 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Confirmed
Critical
Shengyao Xue
linux (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I recently got a Thinkpad T14 Gen2 with a I219-V network adapter (8086:15fc). I get very slow connection speeds and even total loss of connectivity without seeing much in the logs (like dmesg etc.). ethtool reports CRC errors and paket loss. Besides Ubuntu 21.04/kernel 5.11 I tried to install Ubuntu 20.04 (kernel seems to old) and i tried the e1000e driver directly from upstream (3.8.7) with no success.

A strange behaviour I observed: if connectivity is lost (notebook is not reachable via ping from another host), if I do something like "ping 8.8.8.8" on the notebook itself, it becomes reachable from the other host again.

Downloads in general are very slow if they work at all.

WLAN (AX210) seems to work fine, wired network using a USB-network adapter works fine, too.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu65
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ros 3285 F.... pulseaudio
CasperMD5CheckResult: pass
DistroRelease: Ubuntu 21.04
HibernationDevice: RESUME=none
InstallationDate: Installed on 2021-05-07 (2 days ago)
InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420)
MachineType: LENOVO 20W0004MGE
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_n51dtp@/vmlinuz-5.11.0-16-generic root=ZFS=rpool/ROOT/ubuntu_n51dtp ro quiet splash vt.handoff=1
ProcVersionSignature: Ubuntu 5.11.0-16.17-generic 5.11.12
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-5.11.0-16-generic N/A
 linux-backports-modules-5.11.0-16-generic N/A
 linux-firmware 1.197
Tags: hirsute
Uname: Linux 5.11.0-16-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 03/10/2021
dmi.bios.release: 1.10
dmi.bios.vendor: LENOVO
dmi.bios.version: N34ET21W (1.10 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20W0004MGE
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.8
dmi.modalias: dmi:bvnLENOVO:bvrN34ET21W(1.10):bd03/10/2021:br1.10:efr1.8:svnLENOVO:pn20W0004MGE:pvrThinkPadT14Gen2i:rvnLENOVO:rn20W0004MGE:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T14 Gen 2i
dmi.product.name: 20W0004MGE
dmi.product.sku: LENOVO_MT_20W0_BU_Think_FM_ThinkPad T14 Gen 2i
dmi.product.version: ThinkPad T14 Gen 2i
dmi.sys.vendor: LENOVO
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu27.18
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: ros 1673 F.... pulseaudio
 /dev/snd/controlC1: ros 1673 F.... pulseaudio
CasperMD5CheckResult: skip
DistroRelease: Ubuntu 20.04
InstallationDate: Installed on 2021-05-31 (0 days ago)
InstallationMedia: Ubuntu 20.04.2.0 LTS "Focal Fossa" - Release amd64 (20210209.1)
MachineType: LENOVO 20W0004MGE
Package: linux (not installed)
ProcFB: 0 i915drmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.10.0-1026-oem root=/dev/mapper/vgubuntu-root ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.10.0-1026.27-oem 5.10.31
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions:
 linux-restricted-modules-5.10.0-1026-oem N/A
 linux-backports-modules-5.10.0-1026-oem N/A
 linux-firmware 1.187.12
Tags: focal
Uname: Linux 5.10.0-1026-oem x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 03/10/2021
dmi.bios.release: 1.10
dmi.bios.vendor: LENOVO
dmi.bios.version: N34ET21W (1.10 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20W0004MGE
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40697 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.ec.firmware.release: 1.8
dmi.modalias: dmi:bvnLENOVO:bvrN34ET21W(1.10):bd03/10/2021:br1.10:efr1.8:svnLENOVO:pn20W0004MGE:pvrThinkPadT14Gen2i:rvnLENOVO:rn20W0004MGE:rvrSDK0J40697WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.family: ThinkPad T14 Gen 2i
dmi.product.name: 20W0004MGE
dmi.product.sku: LENOVO_MT_20W0_BU_Think_FM_ThinkPad T14 Gen 2i
dmi.product.version: ThinkPad T14 Gen 2i
dmi.sys.vendor: LENOVO

Revision history for this message
Roland Sommer (rsommer) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :

I also tried fedora 34 (kernel 5.11) on this notebook with the same behaviour, so this seems to be a general kernel/driver-problem. The pre-installed windows on this notebook does not have any problems regarding network connectivity.

Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1927925

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Roland Sommer (rsommer) wrote : AlsaInfo.txt

apport information

tags: added: apport-collected hirsute
description: updated
Revision history for this message
Roland Sommer (rsommer) wrote : CRDA.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : IwConfig.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lspci.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lspci-vt.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lsusb.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lsusb-t.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lsusb-v.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : PaInfo.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcEnviron.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcModules.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : RfKill.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : UdevDb.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : WifiSyslog.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : acpidump.txt

apport information

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Roland Sommer (rsommer) wrote :

This has also been reported here: https://sourceforge.net/p/e1000/bugs/688/

Revision history for this message
Roland Sommer (rsommer) wrote :

This laptop has been certified for 20.04 using the latest OEM kernel:

https://certification.ubuntu.com/hardware/202104-28912

Revision history for this message
Roland Sommer (rsommer) wrote :

I still encounter very bad network connectivity using the 5.10.0-1026-oem kernel while running Ubuntu 20.04.

Rex Tsai (chihchun)
Changed in oem-priority:
importance: Undecided → Critical
assignee: nobody → Bin Li (binli)
assignee: Bin Li (binli) → Shengyao Xue (xueshengyao)
Revision history for this message
Shengyao Xue (xueshengyao) wrote :

@Roland, I tested on a T14 Gen2 laptop and a T15 Gen2 (share the same i219-v card to T14), cannot reproduce this issue so far.

the logs you attached seems based on Ubuntu 21.04 with 5.11.0-16 kernel, since this laptop certified with Ubuntu 20.04 with 5.10.0-10xx-oem kernel, could you pls attached those logs after the test in comment #29(Ubuntu 20.04 plus 5.10.0-1026-oem)? thanks.

Changed in oem-priority:
status: New → Incomplete
Revision history for this message
Roland Sommer (rsommer) wrote :

I reinstalled Ubuntu 20.04 after the certification was granted (even that was more than painful) to test out the OEM kernel, the logs are indeed from my previous installation of 21.04. At that time, the laptop was not certified at all so i tried the newest version after encountering the described problems. I'll repost all logs as soon as possible from the system running 20.04 and 5.10.0-1026-oem.

Revision history for this message
Roland Sommer (rsommer) wrote : AlsaInfo.txt

apport information

tags: added: focal
description: updated
Revision history for this message
Roland Sommer (rsommer) wrote : CRDA.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : CurrentDmesg.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : IwConfig.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lspci.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lspci-vt.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lsusb.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lsusb-t.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : Lsusb-v.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcEnviron.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : ProcModules.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : RfKill.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : UdevDb.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : WifiSyslog.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote : acpidump.txt

apport information

Revision history for this message
Roland Sommer (rsommer) wrote :

Additional information: I just did an internet speed test via speedtest.net (I'm connected on 100/40 DSL). While using the internal network card I get around 40MBit upstream (as expected) but only around 3MBit downstream. Switching to the attached USB network adapter, I instantly get around 40MBit upstream and nearly 100MBit downstream as it should be.

Revision history for this message
Roland Sommer (rsommer) wrote :

In addition, I did some download tests in my local network: using the internal network adapter, I get download speeds around 1MB/s, varying from a few kB to 3MB/sec, if I switch to the attached USB network adapter I get constant rates above 90MB/sec, nearly saturating the gigabit network.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote (last edit ):

This seems even worse (5.10.0-2029-oem) - the local download grinds to a complete halt. ethtool shows errors on rx_errors and rx_crc_errors.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Can you please attach dmesg? Thanks!

Changed in oem-priority:
status: Incomplete → Confirmed
Revision history for this message
Gabriel Zhi Chen (gabrielzchen) wrote :

Please refer to the dmesg.log, thanks.

Revision history for this message
koba (kobako) wrote :

@Gabriel, could you try to fix the speed at 1Gbps and disable AN?

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

I meant boot the kernel in #52 and attach dmesg...

Revision history for this message
Roland Sommer (rsommer) wrote :

Attached dmesg of a fresh boot with the Kernel from #52.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :

Tried the kernel from #59, receive speeds are still very poor.

Revision history for this message
Roland Sommer (rsommer) wrote (last edit ):

Attached the corresponding dmesg output for the last tested kernel.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Does kernel parameter "intel_idle.max_cstate=1" help?

Rex Tsai (chihchun)
tags: added: oem-priority
Revision history for this message
Roland Sommer (rsommer) wrote :

Just booted with "intel_idle.max_cstate=1" added to the kernel cmdline. This seems to have fixed the problem. Network speeds are as expected, ethtool shows no errors after some big network transfers. Tested the kernel from #59 and the default 5.8.0-55-generic, both work when "intel_idle.max_cstate=1" is set.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Thanks for the testing. Please give this kernel a try without any parameter:
https://people.canonical.com/~khfeng/lp1927925-qos/

Revision history for this message
Roland Sommer (rsommer) wrote (last edit ):

Just booted the kernel from #64 without the parameter - downloads suffer from slow speeds, ethtool reports rx_errors and rx_crc_errors again.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

OK, so we know two things now:
1) The issue happens when the CPU reaches deeper power saving state, likely PC10.
2) Temporarily increase CPU usage via cpu_latency_qos_add_request() to disable C-State doesn't help.

So please file an upstream bug at https://bugzilla.kernel.org/
Product: Drivers
Component: Network

Revision history for this message
Roland Sommer (rsommer) wrote (last edit ):
Revision history for this message
Roland Sommer (rsommer) wrote :

Are there any more informations under which specific configuration (like modules, kernel parameters etc.) https://ubuntu.com/certified/202104-28912 has been tested?

As described in the kernel bugtracker, the behaviour seems to flip from time to time - sometimes already tested kernels do not work even if "intel_idle.max_cstate=1" is used (booting several times), and then again without changing much (kernel installs/removals) the kernel parameter starts fixing the problem again, even after several reboots.

Revision history for this message
Daniel Barta (lk7r) wrote (last edit ):

Can you please try to Hibernate your laptop to disk, then start it again and test the LAN connection? On my Fujitsu S7311 with I219-LM with Ubuntu kernel 5.11.0-18-generic hibernating running OS to disk and then turning it on makes LAN working as expected without any error (no special kernel parameters). Very strange behaviour.

Revision history for this message
Roland Sommer (rsommer) wrote :

I just tested this, but after hibernation, the same network errors occur as before.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Rolan, can you please attach dmesg after hibernation wakeup?

Revision history for this message
Roland Sommer (rsommer) wrote :

The current kernel was started using the kernel parameter, speeds where fine. I did hibernate, restart the laptop, and now network was broken.

I did another reboot afterwards, booting clean with kernel parameter but now network connectivity is still broken.

I am not able to spot the system behind all this. Sometimes the behaviour is predictable, sometimes it seems completely random.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Roland, the log shows it didn't really hibernate.

Revision history for this message
Roland Sommer (rsommer) wrote :

That would be strange. After systemctl hibernate, the system went into hibernation, I got the resume message while booting and the system state was restored just as before hibernation. The system was not just suspended. I had to go through grub and the hard disk decryption password.

Revision history for this message
Roland Sommer (rsommer) wrote :

I reported another weird discovery in https://bugzilla.kernel.org/show_bug.cgi?id=213377#c13.

Booted without any additional kernel parameters, I can "fix" the download speed if I plug in an USB stick. That would explain why the installation works in the first place, because I booted ubuntu live from USB.

Revision history for this message
Roland Sommer (rsommer) wrote :

Just for reference, the same/a similar bug has been posted to the netdev mailing list by another user. https://www.spinics.net/lists/netdev/msg743850.html

Revision history for this message
Shengyao Xue (xueshengyao) wrote :

@Roland, could you please test the workaround in this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=213651

by change the status of the MEI device power control status.

$ lspci -vvnns 16 // config 16 is the number of MEI device

$ echo on | sudo tee /sys/bus/pci/devices/0000\:00\:16.0/power/control

Revision history for this message
Roland Sommer (rsommer) wrote :

Just tested, after:

$ echo on | sudo tee /sys/bus/pci/devices/0000\:00\:16.0/power/control

I do get good rx speeds.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :

Just booted the provided kernel from #79. Without any of the workarounds, network connectivity is still broken. Using the MEI fix from #77 fixes the problem.

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :
Revision history for this message
Roland Sommer (rsommer) wrote :

Rebooted with the 5.13.0-10007-oem kernel and the first test run was successful. Transfer speeds are as expected, no errors reported by ethtool on rx_errors or rx_crc_errors.

Revision history for this message
Roland Sommer (rsommer) wrote :

Is there a final root cause for all of this? I'm very interested in the explanation or some link to the specific commits that solve the issue(s).

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

No, I simply implement the workaround in the kernel. Since ME isn't supported under Linux, there's a high chance that there won't be any proper solution soon.

The patch can be found here:
https://lkml.org/lkml/2021/7/12/2926

Revision history for this message
Marco Witte (uiuntcone) wrote :

This https://lkml.org/lkml/2021/7/12/2926 also worked for an Fujitsu U7411.
However no touchpad at this moment, but the network part is working.
Hope this finds it's way to the next kernel.

Revision history for this message
Daniel Barta (lk7r) wrote :

modprobe i2c_hid_acpi fixes the touchpad on Fujitsu U7x11

Revision history for this message
Andreas Fester (andreas-fester) wrote :

I am having a similar issue with my Thinkpad L15 Gen2 (Intel), running Ubuntu 21.04 with Kernel 5.11.0-25-generic: After a suspend/resume cycle, the LAN interface only receives at very low speed (less than 1 MBit/sec reported by iperf). So far only rebooting brought back the full speed (approx. 950 MBits/sec.).

It seems that using the MEI fix from #77 also fixes the problem in this scenario - after applying the fix the network speed was back to normal immediately, and I tried several suspend/resume cycles with no decrease in network speed anymore.

Revision history for this message
Rex Tsai (rextsai) wrote :

Hi Andreas,
Can you please share whether your system is a Intel vPro system?

Revision history for this message
Rex Tsai (rextsai) wrote :

@Shengyao Xue,
1.) Intel suspected that this Lenovo issue might be related to this issue: https://bugs.launchpad.net/somerville/+bug/1933807 on Intel vPro system. Lenovo did mention that vPro systems have the same issue.

2.) Intel SW debug engineer is adding some debug prints to the I219 runtime power managements callbacks to see if they are getting called, even though they shouldn’t. I will share patches once it is available.

3.) Can you please try below and see whether you can reproduce the issue? Please also pay attention if the system cannot enter Suspend to Idle after applying this.

echo on > /sys/bus/pci/devices/0000\:00\:16.0/power/control
Explanation, taken from https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-power:

What: /sys/devices/.../power/control
Date: January 2009

Contact: Rafael J. Wysocki <email address hidden>

Description:

               The /sys/devices/.../power/control attribute allows the user

               space to control the run-time power management of the device.

               All devices have one of the following two values for the

               power/control file:

               + "auto\n" to allow the device to be power managed at run time;

               + "on\n" to prevent the device from being power managed;

               The default for all devices is "auto", which means that they may

               be subject to automatic power management, depending on their

               drivers. Changing this attribute to "on" prevents the driver

               from power managing the device at run time. Doing that while

               the device is suspended causes it to be woken up.

Revision history for this message
Shengyao Xue (xueshengyao) wrote :

@Rex, we have already tried the method of:
 echo on > /sys/bus/pci/devices/0000\:00\:16.0/power/control

It can fix this issue, same to comments #77 and #78.

Revision history for this message
Rex Tsai (rextsai) wrote :

Hi Shengyao,
Thanks; I thought the option is to disable GbE. I will find correct option for you.

Revision history for this message
Rex Tsai (rextsai) wrote (last edit ):

Hi Shengyao,
According to Lenovo, the issue can be reproduced on a failed system in Windows environment. Would you please try? If you can see the same result, let's do debug in Windows environment.

Please provide your system information for me to understand if it is vPro or non-vPro system.
--
SoC Model:
BIOS version:
Windows version:
Windows LAN driver version:
ME FW version:
--

If you can reproduce the issue in Windows, please follow steps below to collect driver logs. Please also collect wireshark log at the same time.
1.) Boot to system to S0
2.) Unzip the folder
3.) Open Windows PowerShell as administrator in the folder of debug tool
4.) Run start_trace.bat e1d 0xffffffff
5.) Start to reproduce the issue
6. Run stop_trace.bat e1d 0xffffffff

Rex

Revision history for this message
Rex Tsai (rextsai) wrote :

Hi,

WW38.2'21: Confirmed Intel LAN issue; promoted to LAN engineering. Please see further details below.
Please verify the issue again with FIA wa.7z, which should be final solution candidate.

Root cause:

The power management flow on TGL shut down a clock that is required for exiting from K1 (K1 Is the equivalent of L1 for the proprietary PCIe like interface between the MAC and the PHY).

Due to missing configuration, the clock request was not asserted properly which caused a long K1 exit latency which is the reason for the performance issue.

Solution:

Update the HW MAC initialization flow. Do not gate DMA clock from the modPHY block. Keeping this clock will prevent drop packets sent in burst mode on the Kumaran interface.

Revision history for this message
Shengyao Xue (xueshengyao) wrote (last edit ):

I applied the patch in #93 to linux/drivers/net/ethernet/intel/e1000e, and then built a new e1000e module and tested it on a ThinkPad T15. This issue was fixed in my testing.

Notes: the online version of patch in #93 is here:

https://patchwork.ozlabs.org/project<email address hidden>/

https://patchwork.ozlabs.org/project<email address hidden>/

Revision history for this message
Kai-Heng Feng (kaihengfeng) wrote :

Will backport it once the fix hits git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git

Revision history for this message
Roland Sommer (rsommer) wrote :

I can confirm good receive speeds using the patches from #93 against 5.15-rc2 (including one atomisp compile fix) on a Lenovo T14 G2 running Ubuntu 20.04. Looking forward for the official backport!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.