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