[REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

[REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

[Javier Herrera]

Hi,

Since commit 578294b8b60d ("e1000e: Reconfigure PLL clock gate timeout and
re-enable K1 on Meteor Lake") the integrated I219-LM in a Lenovo ThinkPad
P14s Gen 5 (Intel variant, Core Ultra 9 185H) shows constant packet loss
and erratic latency on the wired link. Wi-Fi and a USB-C RTL8152 adapter on
the same cable, switch and router are fine, so the network itself is not
the problem.

Setting the private flag "disable-k1" fixes it immediately, so this looks
like another system where the PLL clock gate reconfiguration is not enough
and the DMI quirk table introduced by that commit should be extended.

System
------
  Laptop:          Lenovo ThinkPad P14s Gen 5 (Intel)
  DMI sys_vendor:  LENOVO
  DMI product_name:    21G2CTO1WW
  DMI product_version: ThinkPad P14s Gen 5
  DMI board_name:  21G2CTO1WW
  BIOS:            R2DET43W (1.28), 2026-06-22
  CPU:             Intel(R) Core(TM) Ultra 9 185H (Meteor Lake)
  NIC:             00:1f.6 Ethernet Connection (18) I219-LM [8086:550a] (rev 20)
  dmesg:           MAC: 16, PHY: 12, PBA No: FFFFFF-0FF
  Kernel:          7.2.3-arch1-3 (Arch Linux)
  e1000e:          version 7.2.3-arch1-3, firmware-version 1.1-4
  Link:            1000 Mbps Full Duplex, Flow Control: Rx/Tx
  Link partner:    consumer GbE switch/router at 192.168.10.1

Reproduction
------------
Plug the cable and ping the default gateway on the LAN. No suspend/resume
involved, machine freshly booted and on AC power. Nothing e1000e-related in
dmesg apart from the link up/down messages; no "Hardware Unit Hang".

Default (K1 enabled):

  $ ping -c 30 192.168.10.1
  --- 192.168.10.1 ping statistics ---
  30 packets transmitted, 18 received, 40% packet loss, time 29734ms
  rtt min/avg/max/mdev = 0.211/0.315/0.384/0.046 ms

The lost packets are spread over the run (seq 6, 8, 9, 11, 13, 14, 16, 19,
20, 24, 25, 30), not a single burst. DHCP on this link also takes 1-2
minutes to get a lease, consistent with incoming packets being dropped.

With K1 disabled at runtime:

  # ethtool --set-priv-flags enp0s31f6 disable-k1 on
  $ ethtool --show-priv-flags enp0s31f6
  Private flags for enp0s31f6:
  s0ix-enabled: on
  disable-k1  : on

  $ ping -c 30 192.168.10.1
  --- 192.168.10.1 ping statistics ---
  30 packets transmitted, 30 received, 0% packet loss, time 29713ms
  rtt min/avg/max/mdev = 0.169/0.251/0.468/0.054 ms

  $ ping -c 30 192.168.10.1
  --- 192.168.10.1 ping statistics ---
  30 packets transmitted, 30 received, 0% packet loss, time 29677ms
  rtt min/avg/max/mdev = 0.101/0.222/0.360/0.064 ms

The result is stable across repeated runs and survives link down/up. I am
currently working around it with a udev rule that sets the flag on device
add.

Suggested change
----------------
Add the machine to disable_k1_list. Lenovo encodes the model in
DMI_PRODUCT_VERSION (product_name is the per-configuration machine type
21G2CTO1WW), so matching on that is more robust:

{
.ident = "Lenovo ThinkPad P14s Gen 5",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad P14s Gen 5"),
},
},

Only the Intel variant (machine types 21G2/21G3) has an I219-LM, so the
match cannot hit the AMD version of the same model.

I am happy to test patches or collect more data (register dumps, ethtool
-S, different link partners) if useful.

#regzbot introduced: 578294b8b60d

Thanks,
Javier Herrera

Re: [REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

[Thorsten Leemhuis]

On 9/15/26 10:57, Javier Herrera wrote:
> 
> Since commit 578294b8b60d ("e1000e: Reconfigure PLL clock gate timeout and
> re-enable K1 on Meteor Lake") the integrated I219-LM in a Lenovo ThinkPad
> P14s Gen 5 (Intel variant, Core Ultra 9 185H) shows constant packet loss
> and erratic latency on the wired link. Wi-Fi and a USB-C RTL8152 adapter on
> the same cable, switch and router are fine, so the network itself is not
> the problem.
> 
> Setting the private flag "disable-k1" fixes it immediately, so this looks
> like another system where the PLL clock gate reconfiguration is not enough
> and the DMI quirk table introduced by that commit should be extended.
> [...]

Dima or e1000e maintainers, could you please submit and upstream a quirk
entry to resolve this regression? Ideally with a stable tag? Javier
afaics provided everything needed for this. Reminder, Linus rule of
thumb wrt to regressions is "generally fix them within a week,
preferably before the next rc.":
https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed

Or is there some reason why the quirk entry is a bad idea here?

Sending this as things looked stalled from here; or was there some
progress to resolve this already which I missed?

Ciao, Thorsten

Re: [REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

[Tony Nguyen]

On 9/24/2026 12:34 AM, Thorsten Leemhuis wrote:
> On 9/15/26 10:57, Javier Herrera wrote:
>>
>> Since commit 578294b8b60d ("e1000e: Reconfigure PLL clock gate timeout and
>> re-enable K1 on Meteor Lake") the integrated I219-LM in a Lenovo ThinkPad
>> P14s Gen 5 (Intel variant, Core Ultra 9 185H) shows constant packet loss
>> and erratic latency on the wired link. Wi-Fi and a USB-C RTL8152 adapter on
>> the same cable, switch and router are fine, so the network itself is not
>> the problem.
>>
>> Setting the private flag "disable-k1" fixes it immediately, so this looks
>> like another system where the PLL clock gate reconfiguration is not enough
>> and the DMI quirk table introduced by that commit should be extended.
>> [...]
> 
> Dima or e1000e maintainers, could you please submit and upstream a quirk
> entry to resolve this regression? Ideally with a stable tag? Javier

Dima is out on vacation at the moment; I'll prepare a patch to add this 
entry to the quirks.

Thanks,
Tony

> afaics provided everything needed for this. Reminder, Linus rule of
> thumb wrt to regressions is "generally fix them within a week,
> preferably before the next rc.":
> https://www.kernel.org/doc/html/latest/process/handling-regressions.html#on-how-quickly-regressions-should-be-fixed
> 
> Or is there some reason why the quirk entry is a bad idea here?
> 
> Sending this as things looked stalled from here; or was there some
> progress to resolve this already which I missed?
> 
> Ciao, Thorsten

Re: [REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

[ghrafn]

[-- Attachment #1.1: Type: text/plain, Size: 2329 bytes --]

(Following up on this regression report: [https://lists.openwall.net/netdev/2026/09/15/253](https://lists.openwall.net/netdev/2026/09/15/253?utm_source=chatgpt.com))

Hi,

I appear to be seeing the same issue on a Lenovo ThinkPad T14 Gen 6, with an Intel Ethernet Connection (24) I219-LM [8086:57a0].

With the default e1000e configuration (disable-k1: off), wired Ethernet experiences severe packet loss even to the local gateway. The interface still negotiates normally at 1000 Mb/s, full duplex, and the e1000e statistics do not report CRC, frame, DMA, or other RX errors.

For example:

$ ping -c 10 192.168.0.1
10 packets transmitted, 3 received, 70% packet loss

ARP traffic is affected as well:

$ sudo arping -I enp0s31f6 -c 20 192.168.0.1
20 packets transmitted, 11 packets received, 45% unanswered

A tcpdump on enp0s31f6 showed the outgoing ICMP echo requests, but replies were absent for the lost packets.

The NIC identifies as:

Intel Corporation Ethernet Connection (24) I219-LM [8086:57a0]

and uses e1000e.

Setting the existing private flag:

# ethtool --set-priv-flags enp0s31f6 disable-k1 on

immediately eliminates the problem.

After setting disable-k1:

$ ping -c 30 192.168.0.1
30 packets transmitted, 30 received, 0% packet loss
rtt min/avg/max/mdev = 0.384/0.538/0.885/0.098 ms

and:

$ sudo arping -I enp0s31f6 -c 20 192.168.0.1
20 packets transmitted, 20 packets received, 0% unanswered

The result is repeatable within the same session: the severe local packet loss disappeared immediately after disabling K1.

System information:

Laptop:

Lenovo ThinkPad T14 Gen 6

DMI sys_vendor:

LENOVO

DMI product_name:

21QCS01600

DMI product_version:

ThinkPad T14 Gen 6

DMI board_name:

21QCS01600

BIOS:

N4JET28W (1.18 ) (date:

06/16/2026

)

CPU:

Intel(R) Core(TM) Ultra 5 235U

Kernel:

Linux 7.0.0-38-generic

NIC:

00:1f.6 Intel Ethernet Connection (24) I219-LM [8086:57a0]

e1000e firmware:

0.1-4

Link:

1000 Mb/s Full Duplex

OS:

Ubuntu 26.04.1 LTS

I am currently working around the issue by setting disable-k1 on.

This looks sufficiently similar to the reported P14s Gen 5 issue that I wanted to report the additional affected platform in case the T14 Gen 6 also needs to be added to disable_k1_list.

I'm happy to test a patch or provide additional diagnostics if useful.

Thanks,
Gísli

[-- Attachment #1.2: Type: text/html, Size: 4041 bytes --]

[-- Attachment #2: publickey - ghrafn@proton.me - 0xBDFBA7A8.asc --]
[-- Type: application/pgp-keys, Size: 828 bytes --]

RE: [REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1

[Ruinskiy, Dima]

[-- Attachment #1: Type: text/plain, Size: 3134 bytes --]

We now have the ability to selectively alter the default K1 value on a system-by-system basis. I will send a follow-up patch.

From: ghrafn <ghrafn@proton.me>
Sent: Monday, 5 October 2026 21:52
To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>
Cc: Ruinskiy, Dima <dima.ruinskiy@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; vitaly.lifshits@intel.com; intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; regressions@lists.linux.dev
Subject: Re: [REGRESSION] e1000e: heavy packet loss on Lenovo ThinkPad P14s Gen 5 (I219-LM, Meteor Lake) after K1 re-enable; fixed by disable-k1


(Following up on this regression report: https://lists.openwall.net/netdev/2026/09/15/253<https://lists.openwall.net/netdev/2026/09/15/253?utm_source=chatgpt.com>)

Hi,

I appear to be seeing the same issue on a Lenovo ThinkPad T14 Gen 6, with an Intel Ethernet Connection (24) I219-LM [8086:57a0].

With the default e1000e configuration (disable-k1: off), wired Ethernet experiences severe packet loss even to the local gateway. The interface still negotiates normally at 1000 Mb/s, full duplex, and the e1000e statistics do not report CRC, frame, DMA, or other RX errors.

For example:

$ ping -c 10 192.168.0.1

10 packets transmitted, 3 received, 70% packet loss

ARP traffic is affected as well:

$ sudo arping -I enp0s31f6 -c 20 192.168.0.1

20 packets transmitted, 11 packets received, 45% unanswered

A tcpdump on enp0s31f6 showed the outgoing ICMP echo requests, but replies were absent for the lost packets.

The NIC identifies as:

Intel Corporation Ethernet Connection (24) I219-LM [8086:57a0]

and uses e1000e.

Setting the existing private flag:

# ethtool --set-priv-flags enp0s31f6 disable-k1 on

immediately eliminates the problem.

After setting disable-k1:

$ ping -c 30 192.168.0.1

30 packets transmitted, 30 received, 0% packet loss

rtt min/avg/max/mdev = 0.384/0.538/0.885/0.098 ms

and:

$ sudo arping -I enp0s31f6 -c 20 192.168.0.1

20 packets transmitted, 20 packets received, 0% unanswered

The result is repeatable within the same session: the severe local packet loss disappeared immediately after disabling K1.

System information:

Laptop:              Lenovo ThinkPad T14 Gen 6

DMI sys_vendor:      LENOVO

DMI product_name:    21QCS01600

DMI product_version: ThinkPad T14 Gen 6

DMI board_name:      21QCS01600

BIOS:                N4JET28W (1.18 ) (date: 06/16/2026)

CPU:                 Intel(R) Core(TM) Ultra 5 235U

Kernel:              Linux 7.0.0-38-generic

NIC:                 00:1f.6 Intel Ethernet Connection (24) I219-LM [8086:57a0]

e1000e firmware:     0.1-4

Link:                1000 Mb/s Full Duplex
OS:                  Ubuntu 26.04.1 LTS

I am currently working around the issue by setting disable-k1 on.

This looks sufficiently similar to the reported P14s Gen 5 issue that I wanted to report the additional affected platform in case the T14 Gen 6 also needs to be added to disable_k1_list.

I'm happy to test a patch or provide additional diagnostics if useful.

Thanks,
Gísli

[-- Attachment #2: Type: text/html, Size: 7783 bytes --]