Messages in this thread | | | Date | Wed, 1 Dec 2021 14:00:40 -0500 | Subject | Re: [External] Re: [PATCH 3/3] Revert "e1000e: Add handshake with the CSME to support S0ix" | From | Mark Pearson <> |
| |
On 2021-12-01 11:38, Ruinskiy, Dima wrote: > On 30/11/2021 17:52, Mark Pearson wrote: >> Hi Sasha >> >> On 2021-11-28 08:23, Sasha Neftin wrote: >>> On 11/22/2021 18:19, Kai-Heng Feng wrote: >>>> This reverts commit 3e55d231716ea361b1520b801c6778c4c48de102. >>>> >>>> Bugzilla: >>>> https://bugzilla.kernel.org/show_bug.cgi?id=214821>>>>> >>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> >>>> --- >> <snip> >>>> >>> Hello Kai-Heng, >>> I believe it is the wrong approach. Reverting this patch will put >>> corporate systems in an unpredictable state. SW will perform s0ix flow >>> independent to CSME. (The CSME firmware will continue run >>> independently.) LAN controller could be in an unknown state. >>> Please, afford us to continue to debug the problem (it is could be >>> incredible complexity) >>> >>> You always can skip the s0ix flow on problematic corporate systems by >>> using privilege flag: ethtool --set-priv-flags enp0s31f6 s0ix-enabled >>> off >>> >>> Also, there is no impact on consumer systems. >>> Sasha >> >> I know we've discussed this offline, and your team are working on the >> correct fix but I wanted to check based on your comments above that "it >> was complex". I thought, and maybe misunderstood, that it was going to >> be relatively simple to disable the change for older CPUs - which is the >> biggest problem caused by the patch. >> >> Right now it's breaking networking for folk who happen to have a vPro >> Tigerlake (and I believe even potentially Cometlake or older) system. I >> think the impact of that could potentially be quite severe. >> >> I understand not wanting to revert the change for the ADL platforms I >> believe this is targeting and to fix this instead - but your comment >> made me nervous that Linux users on older Intel based platforms are in >> for a long and painful wait - it is likely a lot of users.... >> >> Can you or Dima confirm the fix for older platforms will be available >> soon? I appreciate the ADL platform might take a bit more work and time >> to get right. >> >> Thanks >> Mark >> > Hi Mark, > > What we currently see is that the issue manifests itself similarly on > ADL and TGL platforms. Thus, the fix will likely be the same for both. > > If we cannot find a proper fix soon, we will provide a workaround (for > example by temporary disabling the feature on vPro platforms until we do > have a fix). > > This can be done without reverting the patch series, and I don't see > much value in selectively disabling it for CML/TGL while leaving it on > for ADL, unless our ongoing debug shows otherwise. > Got it - thanks Dima.
As a note - the obvious advantage of selectively disabling for CML/TGL is there is a ton of those platforms out there in users hands, whereas the ADL platforms won't be landing for a few more months (at least in our case). I'm OK if the fixes take a touch longer with ADL (though we'll want them soon so they have time to make it upstream and down into the distro's) - but there's going to be a lot of unhappy Intel users as soon as they start picking up the updates (that are landing in some distro's) and finding that networking is broken. I'd expect TGL/CML to be a priority...
Keep us posted when the fix is ready please.
Mark
| |