[Intel-wired-lan] [PATCH iwl-net v1 1/1] e1000e: Fix S0ix residency on Meteor Lake corporate systems

[Paul Menzel]

Dear Mark,


Am 04.06.24 um 16:33 schrieb Mark Pearson:

> On Wed, May 29, 2024, at 7:23 AM, Paul Menzel wrote:

>> Am 29.05.24 um 13:13 schrieb Lifshits, Vitaly:
>>
>>> On 5/28/2024 1:43 PM, Paul Menzel wrote:
>>
>>>> Am 28.05.24 um 12:33 schrieb Vitaly Lifshits:
>>>>> From: Dima Ruinskiy <dima.ruinskiy at intel.com>
>>>>>
>>>>> On vPro systems,the  configuration of the I219-LM to achieve power
>>>>
>>>> s/,the  /, the /
>>> Thank you for noticing it.
>>> I will fix it in a v2.
>>>
>>>>> gating and S0ix residency is split between the driver and the CSME FW.
>>>>> It was discovered that in some scenarios, where the network cable is
>>>>> connected and then disconnected, S0ix residency is not always reached.
>>>>
>>>> Disconnected at any point, or just during suspend?
>>> Yes, at any point.
>>>
>>>> Any URL to the reports?
>>> Yes, https://bugs.launchpad.net/sutton/+bug/2054657
>>
>> This page does not exist.
>>
>>       $ curl -I https://bugs.launchpad.net/sutton/+bug/2054657
>>       HTTP/1.1 404 Not Found
>>       Date: Wed, 29 May 2024 11:20:52 GMT
>>       Server: gunicorn
>>       […]
>>
>> Please reference the (working) URL in a Link: tag in the footer.
> 
> Unfortunately the URL is a private bug between Lenovo and Canonical -
> we hit the issue as we've been working on the Linux enablement for
> our 2024 platforms.

Thank you for the clarification.

> I can't make the bug publicly visible I'm afraid - too much internal
> code name/process in there. I don't think there will be a public
> report of the issue yet - because the platforms have only just been
> released. If it's useful I guess I can create a kernel.org bug to
> track against?
If all relevant information is in the commit message, then that’s not 
necessary. The private bug URL could still be mentioned, as it might be 
useful for those with access. It should only be clearly stated, that 
it’s not public. (Others have different opinion.)

>>>>> This was root-caused to a subset of I219-LM register writes that are not
>>>>> performed by the CSME FW. Therefore, the driver should perform these
>>>>> register writes on corporate setups, regardless of the CSME FW state.
>>>>
>>>> Is that documented somewhere?
>>> Only in an internal documentation.
>>
>> If you can, it’d be great if you summarized why this is triggered by
>> unplugging the network cable.
>>
>>>> Please add more information about the affected systems, and the test
>>>> environment (firmware versions, …).
>>> It is mentioned at the beginning of the commit, Meteorlake vPro systems.
>>
>> Please be more specific. If there is a Meteor Lake vPro system, where
>> this can *not* be reproduced, it’d be great to know the exact system you
>> tested this with. Meteor Lake has been released a long time ago, and not
>> remembering a lot of bug reports, I assume, it’s not always reproducible.
>>
>> (You missed to comment on my previous comments at the end.)
> 
> I can't comment on the technical details, but I can note that it's
> reproduced on multiple Lenovo Thinkpad Meteorlake platforms that have
> ethernet
> E14 G6, E16 G2, L14 G5, L16 G1, P14s G5, P16s G3 & P16v G2
> I think it's common to any Meteorlake platform - but I defer to the
> Intel folk on the specifics.
Adding these model names to the commit message would work for me.


Kind regards,

Paul