From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92B27C1975A for ; Wed, 25 Mar 2020 15:49:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 788352073E for ; Wed, 25 Mar 2020 15:49:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728076AbgCYPtM (ORCPT ); Wed, 25 Mar 2020 11:49:12 -0400 Received: from mx3.molgen.mpg.de ([141.14.17.11]:36069 "EHLO mx1.molgen.mpg.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727840AbgCYPtJ (ORCPT ); Wed, 25 Mar 2020 11:49:09 -0400 Received: from [192.168.0.2] (ip5f5af719.dynamic.kabel-deutschland.de [95.90.247.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: pmenzel) by mx.molgen.mpg.de (Postfix) with ESMTPSA id 16137202254DE; Wed, 25 Mar 2020 16:49:06 +0100 (CET) Subject: Re: [Intel-wired-lan] [PATCH] e1000e: bump up timeout to wait when ME un-configure ULP mode To: Sasha Neftin , Aaron Ma , Kai-Heng Feng Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, David Miller , Rex Tsai References: <20200323191639.48826-1-aaron.ma@canonical.com> <2c765c59-556e-266b-4d0d-a4602db94476@intel.com> <899895bc-fb88-a97d-a629-b514ceda296d@canonical.com> <750ad0ad-816a-5896-de2f-7e034d2a2508@intel.com> From: Paul Menzel Message-ID: Date: Wed, 25 Mar 2020 16:49:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <750ad0ad-816a-5896-de2f-7e034d2a2508@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Dear Linux folks, Am 25.03.20 um 14:58 schrieb Neftin, Sasha: > On 3/25/2020 08:43, Aaron Ma wrote: >> On 3/25/20 2:36 PM, Neftin, Sasha wrote: >>> On 3/25/2020 06:17, Kai-Heng Feng wrote: >>>>> On Mar 24, 2020, at 03:16, Aaron Ma 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 >>>>> --- >>>>> 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()? >>> 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. > > Who can explain - why ME required too much time on this system? > Probably need work with ME/BIOS vendor and understand it. > Delay will just mask the real problem - we need to find root cause. >> Quirk is only for 1 model type. But issue is reproduced by more models. >> So it won't work. (Where is Aaron’s reply? It wasn’t delivered to me yet.) As this is clearly a regression, please revert the commit for now, and then find a way to correctly implement S0ix support. Linux’ regression policy demands that as no fix has been found since v5.5-rc1. Changing Intel ME settings, even if it would work around the issue, is not an acceptable solution. Delaying the resume time is also not a solution. Regarding Intel Management Engine, only Intel knows what it does and what the error is, as the ME firmware is proprietary and closed. Lastly, there is no way to fully disable the Intel Management Engine. The HAP stuff claims to stop the Intel ME execution, but nobody knows, if it’s successful. Aaron, Kai-Hang, can you send the revert? Kind regards, Paul