On Sun, 22 Feb 2026 18:05:12 +0200 "Ruinskiy, Dima" <[email protected]> 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/[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]/ 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
