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

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

[Vitaly Lifshits]

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);
 
-- 
2.34.1

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

[Loktionov, Aleksandr]

> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Vitaly Lifshits
> Sent: Monday, February 2, 2026 11:33 AM
> To: intel-wired-lan@lists.osuosl.org
> Cc: marmarek@invisiblethingslab.com; timo.teras@iki.fi;
> jeremie.wenger@edu.ge.ch; Lifshits, Vitaly <vitaly.lifshits@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-net v2 1/1] e1000e: reconfigure
> PLL clock gate value and re-enable K1 on Meteor Lake
> 
> 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);
> 
> --
> 2.34.1

Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>

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

[Dahan, AvigailX]

On 02/02/2026 12:32, Vitaly Lifshits 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(-)
> 

Tested-by: Avigail Dahan <avigailx.dahan@intel.com>

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

[Timo Teras]

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);
>  

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]

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

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

[Timo Teras]

On Wed, 11 Feb 2026 15:11:58 +0200
"Ruinskiy, Dima" <dima.ruinskiy@intel.com> wrote:

> On 10/02/2026 13:11, Timo Teras wrote:
> > 
> > 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
> > 
> > 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>
> >> ---
> 
> 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.

Is there other PLL timeout value to test?

> With this patch, and manually disabling K1 via the private flag, does 
> the issue on your Dell laptop disappear? I expect it would.

Yes, it disappears in this case.

> 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.

If you look at the earlier issues, the regression happened on numerous
devices. You have been able to verify one or two devices? I was able to
report that one is still broken. Changes are that there are also other
devices that will regress with this change.

This patch has two changes:
 - configure PLL timeout
 - change K1 default mode for specific models

The PLL timeout change is independent and good to go.

The K1 default mode changing is wide. Perhaps the change could be
scoped to SOCs that are known to be good?

Alternatively, the original change that caused this in the first place
is commit efaaf344 "e1000e: change k1 configuration on MTP and later platforms"
is the K1 exit timeout changed there something that could be tuned
differently?

There was also never reply to the question on how likely / large issue
the potential Rx packet drop is? How many units it may affect?

From the earlier discussion we know that the "network does not work
after cable unplug/plug" issue this causes is affecting multiple different
vendors and is a *major* problem.

Thanks for considering and on the continued assistance on determining
the root cause why these devices are affected.

If you end up changing K1 default, please add a mechanism to add
quirks on how to disable it on affected systems without needing user
space configuration. I find it unacceptable that userspace needs to
be modified to fix kernel driver behavior on known bad devices.

Timo

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]

On 12/02/2026 11:15, Timo Teras wrote:

> Is there other PLL timeout value to test?

Some preliminary calculations we did suggest that raising the value a 
bit further - from 0x1D5 to 0x226 - might be worthwhile. Beyond that you 
may run into other issues.

If you can try it on your machine and report back, that would be great. 
Currently, the only similar system I have is a Pro Max 16 with a U9-285H 
CPU. It is the same SoC generation, but many components are different, 
and I cannot even get the original issue to reproduce there.

> There was also never reply to the question on how likely / large issue
> the potential Rx packet drop is? How many units it may affect?
> 
>  From the earlier discussion we know that the "network does not work
> after cable unplug/plug" issue this causes is affecting multiple different
> vendors and is a *major* problem.

I do not have exact numbers, but it is definitely true that multiple 
system from different vendors have suffered from it.

> If you end up changing K1 default, please add a mechanism to add
> quirks on how to disable it on affected systems without needing user
> space configuration. I find it unacceptable that userspace needs to
> be modified to fix kernel driver behavior on known bad devices.

I have been pondering something like a DMI quirk. These have been 
proposed before for various issues, e.g.:

https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200319052629.7282-1-kai.heng.feng@canonical.com/

Back then we found a better solution, so this approach was dropped. The 
basic idea can be used as a mechanism for a table of "known bad" 
devices, which the driver can check against to determine the default value.

However, I do not have the capacity to maintain the table itself, or 
even validate every device someone might want to add to it.

At one point there was a proposition to introduce such a table of quirks 
to a Realtek network driver, which was also ultimately rejected from 
upstream (note specifically the comments at the end of the thread):

https://patchew.org/linux/20241208191039.2240-1-guyc.linux.patches@gmail.com/

Thanks!
--Dima

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

[Timo Teras]

On Sun, 22 Feb 2026 18:05:12 +0200
"Ruinskiy, Dima" <dima.ruinskiy@intel.com> wrote:

> On 12/02/2026 11:15, Timo Teras wrote:
> 
> > Is there other PLL timeout value to test?  
> 
> Some preliminary calculations we did suggest that raising the value a 
> bit further - from 0x1D5 to 0x226 - might be worthwhile. Beyond that you 
> may run into other issues.

Unfortunately this did not change the situation.

Any other suggestions?

> If you can try it on your machine and report back, that would be great. 
> Currently, the only similar system I have is a Pro Max 16 with a U9-285H 
> CPU. It is the same SoC generation, but many components are different, 
> and I cannot even get the original issue to reproduce there.
> 
> > There was also never reply to the question on how likely / large issue
> > the potential Rx packet drop is? How many units it may affect?
> > 
> >  From the earlier discussion we know that the "network does not work
> > after cable unplug/plug" issue this causes is affecting multiple different
> > vendors and is a *major* problem.  
> 
> I do not have exact numbers, but it is definitely true that multiple 
> system from different vendors have suffered from it.
> 
> > If you end up changing K1 default, please add a mechanism to add
> > quirks on how to disable it on affected systems without needing user
> > space configuration. I find it unacceptable that userspace needs to
> > be modified to fix kernel driver behavior on known bad devices.  
> 
> I have been pondering something like a DMI quirk. These have been 
> proposed before for various issues, e.g.:
> 
> https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20200319052629.7282-1-kai.heng.feng@canonical.com/
> 
> Back then we found a better solution, so this approach was dropped. The 
> basic idea can be used as a mechanism for a table of "known bad" 
> devices, which the driver can check against to determine the default value.
> 
> However, I do not have the capacity to maintain the table itself, or 
> even validate every device someone might want to add to it.
> 
> At one point there was a proposition to introduce such a table of quirks 
> to a Realtek network driver, which was also ultimately rejected from 
> upstream (note specifically the comments at the end of the thread):
> 
> https://patchew.org/linux/20241208191039.2240-1-guyc.linux.patches@gmail.com/

Yes, generally maintaining a large quirk set is infeasible.

But this is my point: if the affected set of machines with this issue
is so large that maintaining a quirk set becomes infeasible, then
the proposed change will make life very difficult for large enough
set of people that a better solution should be devised.

Timo

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]

On 26/02/2026 14:36, Timo Teras wrote:
> Yes, generally maintaining a large quirk set is infeasible.
> 
> But this is my point: if the affected set of machines with this issue
> is so large that maintaining a quirk set becomes infeasible, then
> the proposed change will make life very difficult for large enough
> set of people that a better solution should be devised.
> 
> Timo
> 
> 
At this point, with the current PLL change, it looks like the number of 
affected systems would be smaller than would be with the previous PLL value.

So far we have not received additional reports of regressions caused by 
this patch, other than yours. So, perhaps, the it can be manageable with 
a DMI quirk approach. I went ahead and implemented the infrastructure, 
it's actually quite a small change, and does what I want (automatically 
alters the default value of the K1 disable flag).

Could you share the DMI IDs of your system, where the issue is observed? 
Most likely the sys_vendor, product_family and product_name, located 
under /sys/class/dmi/id would be the most useful. I can add them as an 
initial DMI table entry for v3 of this patch (or a follow-up patch).

Thanks!
--Dima

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]

On 25/03/2026 17:49, Ruinskiy, Dima wrote:
> On 26/02/2026 14:36, Timo Teras wrote:
>> Yes, generally maintaining a large quirk set is infeasible.
>>
>> But this is my point: if the affected set of machines with this issue
>> is so large that maintaining a quirk set becomes infeasible, then
>> the proposed change will make life very difficult for large enough
>> set of people that a better solution should be devised.
>>
>> Timo
>>
>>
> At this point, with the current PLL change, it looks like the number of 
> affected systems would be smaller than would be with the previous PLL 
> value.
> 
> So far we have not received additional reports of regressions caused by 
> this patch, other than yours. So, perhaps, the it can be manageable with 
> a DMI quirk approach. I went ahead and implemented the infrastructure, 
> it's actually quite a small change, and does what I want (automatically 
> alters the default value of the K1 disable flag).
> 
> Could you share the DMI IDs of your system, where the issue is observed? 
> Most likely the sys_vendor, product_family and product_name, located 
> under /sys/class/dmi/id would be the most useful. I can add them as an 
> initial DMI table entry for v3 of this patch (or a follow-up patch).
> 
> Thanks!
> --Dima
Hi Timo,

Just double-checking as a follow-up to my email last week.

We plan to send this patch upstream shortly, since the current situation 
where the upstream kernel is unable to pass Energy Star certification 
with the default settings is not acceptable.

If you want to share the DMI IDs of the problematic system I will go 
ahead and add those in v3 or in a follow-up patch, so that K1 is 
automatically disabled on that class of systems.

Thanks!
--Dima

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

[Timo Teras]

Hi

On Wed, 1 Apr 2026 10:07:45 +0300
"Ruinskiy, Dima" <dima.ruinskiy@intel.com> wrote:

> On 25/03/2026 17:49, Ruinskiy, Dima wrote:
> > On 26/02/2026 14:36, Timo Teras wrote:  
> >> Yes, generally maintaining a large quirk set is infeasible.
> >>
> >> But this is my point: if the affected set of machines with this issue
> >> is so large that maintaining a quirk set becomes infeasible, then
> >> the proposed change will make life very difficult for large enough
> >> set of people that a better solution should be devised.
> >>  
> > At this point, with the current PLL change, it looks like the number of 
> > affected systems would be smaller than would be with the previous PLL 
> > value.
> > 
> > So far we have not received additional reports of regressions caused by 
> > this patch, other than yours. So, perhaps, the it can be manageable with 
> > a DMI quirk approach. I went ahead and implemented the infrastructure, 
> > it's actually quite a small change, and does what I want (automatically 
> > alters the default value of the K1 disable flag).

I would not make quick judgement on not receiving any reports that there
is not other hardware where this causes issues. I do hope this is
the situation. But as it happened in the past the reports start typically
with a delay after the commit makes it into an upstream release.

We had the patched kernel with the PLL change running for a bit longer
time, and we observed that it also caused packet loss / very slow network
issues in the Dell laptop. Especially with the later suggested value 0x226.

> > Could you share the DMI IDs of your system, where the issue is observed? 
> > Most likely the sys_vendor, product_family and product_name, located 
> > under /sys/class/dmi/id would be the most useful. I can add them as an 
> > initial DMI table entry for v3 of this patch (or a follow-up patch).

sys_vendor: Dell Inc.
product_family: Dell Pro Laptops
product_name: Dell Pro 16 Plus PB16250

See also the original report for a full dmesg at:
https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250623/048860.html

From dmesg:

DMI: Dell Inc. Dell Pro 16 Plus PB16250/0W8RP8, BIOS 2.3.1 05/16/2025
e1000e 0000:00:1f.6 eth0: MAC: 16, PHY: 12, PBA No: FFFFFF-0FF

I would not be surprised if other Dell models with same chipset are
affected. But this is the only one I have available to test with.

Maybe its worth to check based on sys_vendor and/or product_family
together with the MAC and/or PHY version? That is to exclude product_name?

Thanks!

Timo

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]

On 01/04/2026 10:25, Timo Teras wrote:
> Hi
> 
> On Wed, 1 Apr 2026 10:07:45 +0300
> "Ruinskiy, Dima" <dima.ruinskiy@intel.com> wrote:
> 
>> On 25/03/2026 17:49, Ruinskiy, Dima wrote:
>>> On 26/02/2026 14:36, Timo Teras wrote:
>>>> Yes, generally maintaining a large quirk set is infeasible.
>>>>
>>>> But this is my point: if the affected set of machines with this issue
>>>> is so large that maintaining a quirk set becomes infeasible, then
>>>> the proposed change will make life very difficult for large enough
>>>> set of people that a better solution should be devised.
>>>>   
>>> At this point, with the current PLL change, it looks like the number of
>>> affected systems would be smaller than would be with the previous PLL
>>> value.
>>>
>>> So far we have not received additional reports of regressions caused by
>>> this patch, other than yours. So, perhaps, the it can be manageable with
>>> a DMI quirk approach. I went ahead and implemented the infrastructure,
>>> it's actually quite a small change, and does what I want (automatically
>>> alters the default value of the K1 disable flag).
> 
> I would not make quick judgement on not receiving any reports that there
> is not other hardware where this causes issues. I do hope this is
> the situation. But as it happened in the past the reports start typically
> with a delay after the commit makes it into an upstream release.
> 
> We had the patched kernel with the PLL change running for a bit longer
> time, and we observed that it also caused packet loss / very slow network
> issues in the Dell laptop. Especially with the later suggested value 0x226.
> 
>>> Could you share the DMI IDs of your system, where the issue is observed?
>>> Most likely the sys_vendor, product_family and product_name, located
>>> under /sys/class/dmi/id would be the most useful. I can add them as an
>>> initial DMI table entry for v3 of this patch (or a follow-up patch).
> 
> sys_vendor: Dell Inc.
> product_family: Dell Pro Laptops
> product_name: Dell Pro 16 Plus PB16250
> 
> See also the original report for a full dmesg at:
> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of-Mon-20250623/048860.html
> 
>  From dmesg:
> 
> DMI: Dell Inc. Dell Pro 16 Plus PB16250/0W8RP8, BIOS 2.3.1 05/16/2025
> e1000e 0000:00:1f.6 eth0: MAC: 16, PHY: 12, PBA No: FFFFFF-0FF
> 
> I would not be surprised if other Dell models with same chipset are
> affected. But this is the only one I have available to test with.
> 
> Maybe its worth to check based on sys_vendor and/or product_family
> together with the MAC and/or PHY version? That is to exclude product_name?
> 
> Thanks!
> 
> Timo
Hi Timo,

You are correct that there will be higher coverage when the commit 
reaches upstream, however we have to start somewhere, and so far you 
have been the only one to report back specifically on the new version, 
thank you for this, by the way. :)

The value of 0x226 was computed as a theoretical upper bound, and as 
such am not totally surprised that it brings its own issues. I do not 
plan to use 0x226 in the patch.

I managed some testing with a Dell Pro Max from the same generation, 
which did not hit even the original issue. So I would not want to 
exclude too broad of a family until/unless I get more reports.

MAC type will be 16 or higher on all potentially affected systems, while 
PHY type is 12 on any I219 device. Currently it seems that the most 
accurate check would be MAC type + product name.

--Dima

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]

On 01/04/2026 11:19, Ruinskiy, Dima wrote:
> On 01/04/2026 10:25, Timo Teras wrote:
>> Hi
>>
>> On Wed, 1 Apr 2026 10:07:45 +0300
>> "Ruinskiy, Dima" <dima.ruinskiy@intel.com> wrote:
>>
>>> On 25/03/2026 17:49, Ruinskiy, Dima wrote:
>>>> On 26/02/2026 14:36, Timo Teras wrote:
>>>>> Yes, generally maintaining a large quirk set is infeasible.
>>>>>
>>>>> But this is my point: if the affected set of machines with this issue
>>>>> is so large that maintaining a quirk set becomes infeasible, then
>>>>> the proposed change will make life very difficult for large enough
>>>>> set of people that a better solution should be devised.
>>>> At this point, with the current PLL change, it looks like the number of
>>>> affected systems would be smaller than would be with the previous PLL
>>>> value.
>>>>
>>>> So far we have not received additional reports of regressions caused by
>>>> this patch, other than yours. So, perhaps, the it can be manageable 
>>>> with
>>>> a DMI quirk approach. I went ahead and implemented the infrastructure,
>>>> it's actually quite a small change, and does what I want (automatically
>>>> alters the default value of the K1 disable flag).
>>
>> I would not make quick judgement on not receiving any reports that there
>> is not other hardware where this causes issues. I do hope this is
>> the situation. But as it happened in the past the reports start typically
>> with a delay after the commit makes it into an upstream release.
>>
>> We had the patched kernel with the PLL change running for a bit longer
>> time, and we observed that it also caused packet loss / very slow network
>> issues in the Dell laptop. Especially with the later suggested value 
>> 0x226.
>>
>>>> Could you share the DMI IDs of your system, where the issue is 
>>>> observed?
>>>> Most likely the sys_vendor, product_family and product_name, located
>>>> under /sys/class/dmi/id would be the most useful. I can add them as an
>>>> initial DMI table entry for v3 of this patch (or a follow-up patch).
>>
>> sys_vendor: Dell Inc.
>> product_family: Dell Pro Laptops
>> product_name: Dell Pro 16 Plus PB16250
>>
>> See also the original report for a full dmesg at:
>> https://lists.osuosl.org/pipermail/intel-wired-lan/Week-of- 
>> Mon-20250623/048860.html
>>
>>  From dmesg:
>>
>> DMI: Dell Inc. Dell Pro 16 Plus PB16250/0W8RP8, BIOS 2.3.1 05/16/2025
>> e1000e 0000:00:1f.6 eth0: MAC: 16, PHY: 12, PBA No: FFFFFF-0FF
>>
>> I would not be surprised if other Dell models with same chipset are
>> affected. But this is the only one I have available to test with.
>>
>> Maybe its worth to check based on sys_vendor and/or product_family
>> together with the MAC and/or PHY version? That is to exclude 
>> product_name?
>>
>> Thanks!
>>
>> Timo
> Hi Timo,
> 
> You are correct that there will be higher coverage when the commit 
> reaches upstream, however we have to start somewhere, and so far you 
> have been the only one to report back specifically on the new version, 
> thank you for this, by the way. :)
> 
> The value of 0x226 was computed as a theoretical upper bound, and as 
> such am not totally surprised that it brings its own issues. I do not 
> plan to use 0x226 in the patch.
> 
> I managed some testing with a Dell Pro Max from the same generation, 
> which did not hit even the original issue. So I would not want to 
> exclude too broad of a family until/unless I get more reports.
> 
> MAC type will be 16 or higher on all potentially affected systems, while 
> PHY type is 12 on any I219 device. Currently it seems that the most 
> accurate check would be MAC type + product name.
> 
> --Dima
V3 sent: 
https://patchwork.ozlabs.org/project/intel-wired-lan/patch/20260417104330.3031987-1-dima.ruinskiy@intel.com/