Thanks Hans
On 14/12/2020 13:31, Mark Pearson wrote:
>
>
> ------------------------------------------------------------------------
> *From:* Hans de Goede <[email protected]>
> *Sent:* December 14, 2020 13:24
> *To:* Mario Limonciello <[email protected]>; Jeff Kirsher
> <[email protected]>; Tony Nguyen <[email protected]>;
> [email protected] <[email protected]>;
> David Miller <[email protected]>; Aaron Ma <[email protected]>;
> Mark Pearson <[email protected]>
> *Cc:* [email protected] <[email protected]>;
> Netdev <[email protected]>; Alexander Duyck
> <[email protected]>; Jakub Kicinski <[email protected]>; Sasha
> Netfin <[email protected]>; Aaron Brown <[email protected]>;
> Stefan Assmann <[email protected]>; [email protected]
> <[email protected]>; [email protected] <[email protected]>;
> [email protected] <[email protected]>; [email protected]
> <[email protected]>
> *Subject:* [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems
> i219LM
>
> Hi All,
>
<snip>
>
> ###
>
> I've added Mark Pearson from Lenovo to the Cc so that Lenovo
> can investigate this issue further.
>
> Mark, this thread is about an issue with enabling S0ix support for
> e1000e (i219lm) controllers. This was enabled in the kernel a
> while ago, but then got disabled again on vPro / AMT enabled
> systems because on some systems (Lenovo X1C7 and now also X1C8)
> this lead to suspend/resume issues.
>
> When AMT is active then there is a handover handshake for the
> OS to get access to the ethernet controller from the ME. The
> Intel folks have checked and the Windows driver is using a timeout
> of 1 second for this handshake, yet on Lenovo systems this is
> taking 2 seconds. This likely has something to do with the
> ME firmware on these Lenovo models, can you get the firmware
> team at Lenovo to investigate this further ?
Absolutely - I'll ask them to look into this again.
We did try to make progress with this previously - but it got a bit
stuck and hence the need for these patches....but I believe things may
have changed a bit so it's worth trying again
Mark
On 12/14/2020 20:40, Mark Pearson wrote:
> Thanks Hans
>
> On 14/12/2020 13:31, Mark Pearson wrote:
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Hans de Goede <[email protected]>
>> *Sent:* December 14, 2020 13:24
>> *To:* Mario Limonciello <[email protected]>; Jeff Kirsher
>> <[email protected]>; Tony Nguyen <[email protected]>;
>> [email protected] <[email protected]>;
>> David Miller <[email protected]>; Aaron Ma <[email protected]>;
>> Mark Pearson <[email protected]>
>> *Cc:* [email protected] <[email protected]>;
>> Netdev <[email protected]>; Alexander Duyck
>> <[email protected]>; Jakub Kicinski <[email protected]>; Sasha
>> Netfin <[email protected]>; Aaron Brown <[email protected]>;
>> Stefan Assmann <[email protected]>; [email protected]
>> <[email protected]>; [email protected] <[email protected]>;
>> [email protected] <[email protected]>; [email protected]
>> <[email protected]>
>> *Subject:* [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems
>> i219LM
>>
>> Hi All,
>>
> <snip>
>>
>> ###
>>
>> I've added Mark Pearson from Lenovo to the Cc so that Lenovo
>> can investigate this issue further.
>>
>> Mark, this thread is about an issue with enabling S0ix support for
>> e1000e (i219lm) controllers. This was enabled in the kernel a
>> while ago, but then got disabled again on vPro / AMT enabled
>> systems because on some systems (Lenovo X1C7 and now also X1C8)
>> this lead to suspend/resume issues.
>>
>> When AMT is active then there is a handover handshake for the
>> OS to get access to the ethernet controller from the ME. The
>> Intel folks have checked and the Windows driver is using a timeout
>> of 1 second for this handshake, yet on Lenovo systems this is
>> taking 2 seconds. This likely has something to do with the
>> ME firmware on these Lenovo models, can you get the firmware
>> team at Lenovo to investigate this further ?
> Absolutely - I'll ask them to look into this again.
>
we need to explain why on Windows systems required 1s and on Linux
systems up to 2.5s - otherwise it is not reliable approach - you will
encounter others buggy system.
(ME not POR on the Linux systems - is only one possible answer)
> We did try to make progress with this previously - but it got a bit
> stuck and hence the need for these patches....but I believe things may
> have changed a bit so it's worth trying again
>
> Mark
>
Sasha
> > Absolutely - I'll ask them to look into this again.
> >
> we need to explain why on Windows systems required 1s and on Linux
> systems up to 2.5s - otherwise it is not reliable approach - you will
> encounter others buggy system.
> (ME not POR on the Linux systems - is only one possible answer)
Sasha: In your opinion does this information need to block the series?
or can we follow up with more changes later on as more information becomes
available?
For now v5 of the series extends the timeout but at least makes a mention
that there appears to be a firmware bug when more than 1 second is taken.
On 12/15/2020 19:20, Limonciello, Mario wrote:
>
>>> Absolutely - I'll ask them to look into this again.
>>>
>> we need to explain why on Windows systems required 1s and on Linux
>> systems up to 2.5s - otherwise it is not reliable approach - you will
>> encounter others buggy system.
>> (ME not POR on the Linux systems - is only one possible answer)
>
> Sasha: In your opinion does this information need to block the series?
> or can we follow up with more changes later on as more information becomes
> available?
>
I do not think this should block the patches series.
> For now v5 of the series extends the timeout but at least makes a mention
> that there appears to be a firmware bug when more than 1 second is taken.
>