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" <[email protected]> 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/[email protected]/
