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 <timo.teras@iki.fi>]

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