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/[email protected]/
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/[email protected]/
Thanks!
--Dima
