Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp437288pxk; Thu, 24 Sep 2020 09:08:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw7UwSGRZL5SqI259vJqvjlu/HWOIzWBntZirq6lV0rx+vwsTWh+H0zVwAGoUa8I+1/BiIU X-Received: by 2002:a17:906:e4c:: with SMTP id q12mr569503eji.425.1600963728802; Thu, 24 Sep 2020 09:08:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600963728; cv=none; d=google.com; s=arc-20160816; b=ZCGNLd2gJkEZhgZ4xxdnXYkvAb/ceUkPZbFirt1CGhZsldmXc9LJpVwrBFyktF3qvT mOEkV3rj0o4Bogy/iHoCTKHv2XJbac8XVEG1YG/HfRF34DJM3c3aevUxIICas67/B5+e t/dHrR70Na0/eBL4FjMXqg1wwsnMSKk/j/9gFO5o6/168aAgiYyRiYrwPhLHxUwIhcdd +XxqK1YvWihivzepq+ZaU+/TboEGIjBtReA0uEqcx3Za6YYbrMvRv0c8xt/EnPiqHLwC lnLAjxrl0VLwxKLWTMwWYhtWT0vYfNpjvPDlqcA59FTJOk9y+3hoaYiJg3+o1cutYAgy JhBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=HTn51XREVMXMD4K1qTi2jNukS/84Ws6SfjNZerZNxfk=; b=k+OQFr4ugEdbnnj+L2hYpC8uaohRTgrKH1NJzTDDRgIP/cvkxbx02pLG/Dp7NAzoQg 0M+kIQHjoFbPZiiyc9YFly/vRkifcNWfuvqPhmUi2VcBWSjdLmasdY9doWnRyhHPLUpz p6sJCBYvo9hKNg0SlGwjw1HE/6f/gWXhTAylgkTCxanCJWLsVpMbiThOQ0WAmnTD/KLy fTbbueHsKbL3RLIuQl4lyi9nXMGhzW7cOqaIKcwhYJb5b/I8Xkbg28fALaRZR7Z3LTyj u3ZkmB8GWfL5tEl5lzhJac+E37+Lww7FzsnaTqiANDA0BOhYIKxD7o+vBGywsDomDJ6F rJDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g7si2523155edp.272.2020.09.24.09.08.25; Thu, 24 Sep 2020 09:08:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728655AbgIXQE5 (ORCPT + 99 others); Thu, 24 Sep 2020 12:04:57 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:53476 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728641AbgIXQE4 (ORCPT ); Thu, 24 Sep 2020 12:04:56 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1kLTjj-00G2v0-4T; Thu, 24 Sep 2020 18:04:47 +0200 Date: Thu, 24 Sep 2020 18:04:47 +0200 From: Andrew Lunn To: Paul Menzel Cc: Kai-Heng Feng , Jeff Kirsher , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org, Jakub Kicinski , "David S. Miller" Subject: Re: [Intel-wired-lan] [PATCH v2] e1000e: Increase iteration on polling MDIC ready bit Message-ID: <20200924160447.GD3821492@lunn.ch> References: <20200923074751.10527-1-kai.heng.feng@canonical.com> <20200924150958.18016-1-kai.heng.feng@canonical.com> <748efbf9-573f-ab2a-0c82-a7b2a11cda60@molgen.mpg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <748efbf9-573f-ab2a-0c82-a7b2a11cda60@molgen.mpg.de> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 24, 2020 at 05:32:12PM +0200, Paul Menzel wrote: > Dear Kai-Heng, > > > Thank you for sending version 2. > > Am 24.09.20 um 17:09 schrieb Kai-Heng Feng: > > We are seeing the following error after S3 resume: > > I’d be great if you added the system and used hardware, you are seeing this > with. > > > [ 704.746874] e1000e 0000:00:1f.6 eno1: Setting page 0x6020 > > [ 704.844232] e1000e 0000:00:1f.6 eno1: MDI Write did not complete > > A follow-up patch, should extend the message to include the timeout value. > > > MDI Write did not complete did not complete in … seconds. > > According to the Linux timestamps it’s 98 ms, which makes sense, as (640 * 3 > * 50 μs = 96 ms). > > What crappy hardware is this, that it takes longer than 100 ms? I'm speculating, but i guess this happens with just the first couple of transfers after power up. After that, it probably takes a single loop. It would be good to see some profile data for this. Completely different MDIO driver and implementation, but this patch might give some ideas how to do the profiling: https://github.com/lunn/linux/commit/76c7810a7e2c1b1e28a7a95d08dd440a8f48a516 Look at the debugfs and num_loops/us parts. Andrew