linux-kernel - Re: [PATCH] e1000e: bump up timeout to wait when ME un-configure ULP mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 25 Mar 2020 14:43:31 +0800
From:   Aaron Ma <aaron.ma@...onical.com>
To:     "Neftin, Sasha" <sasha.neftin@...el.com>,
        Kai-Heng Feng <kai.heng.feng@...onical.com>
Cc:     "Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
        David Miller <davem@...emloft.net>,
        "moderated list:INTEL ETHERNET DRIVERS" 
        <intel-wired-lan@...ts.osuosl.org>,
        "open list:NETWORKING DRIVERS" <netdev@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        "Lifshits, Vitaly" <vitaly.lifshits@...el.com>, rex.tsai@...el.com
Subject: Re: [PATCH] e1000e: bump up timeout to wait when ME un-configure ULP
 mode



On 3/25/20 2:36 PM, Neftin, Sasha wrote:
> On 3/25/2020 06:17, Kai-Heng Feng wrote:
>> Hi Aaron,
>>
>>> On Mar 24, 2020, at 03:16, Aaron Ma <aaron.ma@...onical.com> wrote:
>>>
>>> ME takes 2+ seconds to un-configure ULP mode done after resume
>>> from s2idle on some ThinkPad laptops.
>>> Without enough wait, reset and re-init will fail with error.
>>
>> Thanks, this patch solves the issue. We can drop the DMI quirk in
>> favor of this patch.
>>
>>>
>>> Fixes: f15bb6dde738cc8fa0 ("e1000e: Add support for S0ix")
>>> BugLink: https://bugs.launchpad.net/bugs/1865570
>>> Signed-off-by: Aaron Ma <aaron.ma@...onical.com>
>>> ---
>>> drivers/net/ethernet/intel/e1000e/ich8lan.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c
>>> b/drivers/net/ethernet/intel/e1000e/ich8lan.c
>>> index b4135c50e905..147b15a2f8b3 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
>>> @@ -1240,9 +1240,9 @@ static s32 e1000_disable_ulp_lpt_lp(struct
>>> e1000_hw *hw, bool force)
>>>             ew32(H2ME, mac_reg);
>>>         }
>>>
>>> -        /* Poll up to 300msec for ME to clear ULP_CFG_DONE. */
>>> +        /* Poll up to 2.5sec for ME to clear ULP_CFG_DONE. */
>>>         while (er32(FWSM) & E1000_FWSM_ULP_CFG_DONE) {
>>> -            if (i++ == 30) {
>>> +            if (i++ == 250) {
>>>                 ret_val = -E1000_ERR_PHY;
>>>                 goto out;
>>>             }
>>
>> The return value was not caught by the caller, so the error ends up
>> unnoticed.
>> Maybe let the caller check the return value of
>> e1000_disable_ulp_lpt_lp()?
>>
>> Kai-Heng
> Hello Kai-Heng and Aaron,
> I a bit confused. In our previous conversation you told ME not running.
> let me shimming in. Increasing delay won't be solve the problem and just
> mask it. We need to understand why ME take too much time. What is
> problem with this specific system?
> So, basically no ME system should works for you.

Some laptops ME work that's why only reproduce issue on some laptops.
In this issue i219 is controlled by ME.

Quirk is only for 1 model type. But issue is reproduced by more models.
So it won't work.

Regard,
Aaron

> 
> Meanwhile I prefer keep DMI quirk.
> Thanks,
> Sasha
>>
>>> -- 
>>> 2.17.1
>>>
>>
>