On Wed, 11 Feb 2026 15:11:58 +0200 "Ruinskiy, Dima" <[email protected]> wrote:
> On 10/02/2026 13:11, Timo Teras wrote: > > > > This seems to retrigger the malfunction on a Dell Pro 16 Plus PB16250 > > laptop. > > > > CPU Interl Core Ultra 5 235U > > CPU family 6 model 181 stepping 0 > > > > On Mon, 2 Feb 2026 12:32:57 +0200 > > Vitaly Lifshits <[email protected]> wrote: > > > >> Commit 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1") > >> disabled K1 by default on Meteor Lake and newer systems due to packet > >> loss observed on various platforms. However, disabling K1 caused an > >> increase in power consumption due to blocking PC10 state. > >> > >> To mitigate this, reconfigure the PLL clock gate value so that K1 can > >> remain enabled without incurring the additional power consumption. > >> > >> Link: https://bugzilla.kernel.org/show_bug.cgi?id=220954 > >> Fixes: 3c7bf5af21960 ("e1000e: Introduce private flag to disable K1") > >> Signed-off-by: Vitaly Lifshits <[email protected]> > >> --- > > We do not currently have exactly such a setup as you mentioned. I will > see if I can procure one for testing. > > The PLL timeout change proposed in this patch successfully resolved the > original issue on a couple of systems in our lab that were previously > experiencing it, while keeping K1 enabled. Is there other PLL timeout value to test? > With this patch, and manually disabling K1 via the private flag, does > the issue on your Dell laptop disappear? I expect it would. Yes, it disappears in this case. > We are aware that there are some systems in the field, for which we are > unable to fully solve the Rx packet performance issue with K1 active. > > On the other hand, disabling it exposes us to a power penalty more > significant that the K1 itself - blocking PC10 affects the power usage > of the entire system, which, in turn, may prevent compliance with > various regulations, such as Energy Star. > > At the moment we do not have a configuration that allows us to achieve > optimal performance and optimal power settings on 100% of the systems, > so the K1 control flag has to stay. The only question here is that of > the default value. > > The PLL change further reduces the percentage of systems suffering from > Rx packet drop. Choosing between a default value that blocks PC10 in all > situations, versus one that deteriorates LAN connectivity in a small % > of cases, the latter seems the better way. If you look at the earlier issues, the regression happened on numerous devices. You have been able to verify one or two devices? I was able to report that one is still broken. Changes are that there are also other devices that will regress with this change. This patch has two changes: - configure PLL timeout - change K1 default mode for specific models The PLL timeout change is independent and good to go. The K1 default mode changing is wide. Perhaps the change could be scoped to SOCs that are known to be good? Alternatively, the original change that caused this in the first place is commit efaaf344 "e1000e: change k1 configuration on MTP and later platforms" is the K1 exit timeout changed there something that could be tuned differently? 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. Thanks for considering and on the continued assistance on determining the root cause why these devices are affected. 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. Timo
