Thanks Hans
On 14/12/2020 13:31, Mark Pearson wrote:
------------------------------------------------------------------------
*From:* Hans de Goede [off-list ref]
*Sent:* December 14, 2020 13:24
*To:* Mario Limonciello [off-list ref]; Jeff Kirsher
[off-list ref]; Tony Nguyen [off-list ref];
intel-wired-lan@lists.osuosl.org [off-list ref];
David Miller [off-list ref]; Aaron Ma [off-list ref];
Mark Pearson [off-list ref]
*Cc:* linux-kernel@vger.kernel.org [off-list ref];
Netdev [off-list ref]; Alexander Duyck
[off-list ref]; Jakub Kicinski [off-list ref]; Sasha
Netfin [off-list ref]; Aaron Brown [off-list ref];
Stefan Assmann [off-list ref]; darcari@redhat.com
[off-list ref]; Yijun.Shen@dell.com [off-list ref];
Perry.Yuan@dell.com [off-list ref]; anthony.wong@canonical.com
[off-list ref]
*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:
quoted
------------------------------------------------------------------------
*From:* Hans de Goede [off-list ref]
*Sent:* December 14, 2020 13:24
*To:* Mario Limonciello [off-list ref]; Jeff Kirsher
[off-list ref]; Tony Nguyen [off-list ref];
intel-wired-lan@lists.osuosl.org [off-list ref];
David Miller [off-list ref]; Aaron Ma [off-list ref];
Mark Pearson [off-list ref]
*Cc:* linux-kernel@vger.kernel.org [off-list ref];
Netdev [off-list ref]; Alexander Duyck
[off-list ref]; Jakub Kicinski [off-list ref]; Sasha
Netfin [off-list ref]; Aaron Brown [off-list ref];
Stefan Assmann [off-list ref]; darcari@redhat.com
[off-list ref]; Yijun.Shen@dell.com [off-list ref];
Perry.Yuan@dell.com [off-list ref]; anthony.wong@canonical.com
[off-list ref]
*Subject:* [External] Re: [PATCH v4 0/4] Improve s0ix flows for systems
i219LM
Hi All,
<snip>
quoted
###
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
quoted
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:
quoted
quoted
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.