On 10/02/2026 13:11, Timo Teras wrote:
Hi
This seems to retrigger the malfunction on a Dell Pro 16 Plus PB16250 laptop.
CPU Interl Core Ultra 5 235U
CPU family 6 model 181 stepping 0
Please advise if you can reproduce or suggest alternative fix?
Thanks,
Timo
On Mon, 2 Feb 2026 12:32:57 +0200
Vitaly Lifshits <[email protected]> wrote:
Commit 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1")
disabled K1 by default on Meteor Lake and newer systems due to packet
loss observed on various platforms. However, disabling K1 caused an
increase in power consumption due to blocking PC10 state.
To mitigate this, reconfigure the PLL clock gate value so that K1 can
remain enabled without incurring the additional power consumption.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=220954
Fixes: 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1")
Signed-off-by: Vitaly Lifshits <[email protected]>
---
v2: add comment for the PLL timeout value and revisit the commit message
v1: initial version
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 6 ++++++
drivers/net/ethernet/intel/e1000e/netdev.c | 3 ---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c
b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 13841daba399..8e88aa9048da 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -1594,6 +1594,12 @@ static s32 e1000_check_for_copper_link_ich8lan(struct
e1000_hw *hw)
phy_reg &= ~I217_PLL_CLOCK_GATE_MASK;
if (speed == SPEED_100 || speed == SPEED_10)
phy_reg |= 0x3E8;
+ else if (hw->mac.type == e1000_pch_mtp ||
+ hw->mac.type == e1000_pch_ptp)
+ /* Increase PLL clock gate timeout to avoid
+ * packet loss
+ */
+ phy_reg |= 0x1D5;
else
phy_reg |= 0xFA;
e1e_wphy_locked(hw, I217_PLL_CLOCK_GATE_REG, phy_reg);
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
b/drivers/net/ethernet/intel/e1000e/netdev.c
index 82d1d5fe51d5..8f0eb822610b 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -7755,9 +7755,6 @@ static int e1000_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* init PTP hardware clock */
e1000e_ptp_init(adapter);
- if (hw->mac.type >= e1000_pch_mtp)
- adapter->flags2 |= FLAG2_DISABLE_K1;
-
/* reset the hardware with the new settings */
e1000e_reset(adapter);
Hi Timo,
We do not currently have exactly such a setup as you mentioned. I will
see if I can procure one for testing.
The PLL timeout change proposed in this patch successfully resolved the
original issue on a couple of systems in our lab that were previously
experiencing it, while keeping K1 enabled.
With this patch, and manually disabling K1 via the private flag, does
the issue on your Dell laptop disappear? I expect it would.
We are aware that there are some systems in the field, for which we are
unable to fully solve the Rx packet performance issue with K1 active.
On the other hand, disabling it exposes us to a power penalty more
significant that the K1 itself - blocking PC10 affects the power usage
of the entire system, which, in turn, may prevent compliance with
various regulations, such as Energy Star.
At the moment we do not have a configuration that allows us to achieve
optimal performance and optimal power settings on 100% of the systems,
so the K1 control flag has to stay. The only question here is that of
the default value.
The PLL change further reduces the percentage of systems suffering from
Rx packet drop. Choosing between a default value that blocks PC10 in all
situations, versus one that deteriorates LAN connectivity in a small %
of cases, the latter seems the better way.
--Dima
