Re: [External] Re: [PATCH 3/3] Revert "e1000e: Add handshake with the CSME to support S0ix"

On 2021-12-01 11:38, Ruinskiy, Dima wrote:

On 30/11/2021 17:52, Mark Pearson wrote:

quoted

Hi Sasha

On 2021-11-28 08:23, Sasha Neftin wrote:

quoted

On 11/22/2021 18:19, Kai-Heng Feng wrote:

quoted

This reverts commit 3e55d231716ea361b1520b801c6778c4c48de102.

Bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=214821>>>>>
Signed-off-by: Kai-Heng Feng <redacted>
---

<snip>

quoted

quoted

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