Re: [Intel-wired-lan] [PATCH iwl-net v2 1/1] e1000e: reconfigure PLL clock gate value and re-enable K1 on Meteor Lake

["Ruinskiy, Dima" <dima.ruinskiy@intel.com>]

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 <vitaly.lifshits@intel.com> 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 <vitaly.lifshits@intel.com>
>> ---
>> 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