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=-12.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_PASS 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 D06A3C43218 for ; Sun, 28 Apr 2019 22:05:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7CFF120656 for ; Sun, 28 Apr 2019 22:05:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nmacleod-com.20150623.gappssmtp.com header.i=@nmacleod-com.20150623.gappssmtp.com header.b="hkAxS7pl" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726559AbfD1WFg (ORCPT ); Sun, 28 Apr 2019 18:05:36 -0400 Received: from mail-it1-f193.google.com ([209.85.166.193]:37476 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726393AbfD1WFg (ORCPT ); Sun, 28 Apr 2019 18:05:36 -0400 Received: by mail-it1-f193.google.com with SMTP id r85so4842170itc.2 for ; Sun, 28 Apr 2019 15:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nmacleod-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cip4gSDyIHA9j0qYDCVxBDnyFyTSyzxPUwaJRqHEKIs=; b=hkAxS7plwZJ6u8LrWqAqyQn0rCBZcPET8rP0MB6BiIWD+IIr4CgZLzO13G38UFbWE8 tdDtxFzb8LZX5ERtH1dC81PIoxcEDre8ql4OdHFfvgaVaXs4ek8svZUrxzaeM4kQS8pt FlOrhOYw/IOrHr1+AeZArvkLzkO/mEY7lUhyoQKGjLCAIXxb8I7xpFuoemS6RW3LbFMn RFron/qr3K3XCm13mDjIj3sdjzQxY/eJkD6HCpYNgf9N5YtXk0ShcHvEvr0SrZnoOuUM 9qbbRuFBFXd/Y26zPc8FhcmuTlVIFrOjl7QfYp2rza8tgER7dg3cB7RK+jAutF2fuGXX /F9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cip4gSDyIHA9j0qYDCVxBDnyFyTSyzxPUwaJRqHEKIs=; b=Ve20yTVaPl/clEWRDbwlfnT5SBE1Yp0oXYZ8u6ZcIQCa/ZD4zNLL7lQKkZdxRiCY4/ ZTP055zeXWiIqpMKujtYP5IlfohwgV/mzHdHGuUn+tt0Va/feF2bS93Op8MU0/H3E1ng 7BJT0mw8sLkYgCSNNp1jj9r7LZ/QWcCxzC4QTrCCZm5dfob7xx8eMZmacVMQR8ni3p+H r8a8hCXW7PAQNgOhl9RW31KcoYf2ljn7NQVD3MMuTN8Zl/Unm+NVazNdtiLJRr/232vG 1AugIF/YDzHqkHCgLtiGdUO6sU7pmz0wUKZHPgMcK9iy/FAfWvpjhffDduupezGLlXuF yW8A== X-Gm-Message-State: APjAAAWRyi1H5WKRG+f3RFjOTfNDlU7mJd3F5M8cWyGiNk/vgheOCCbS cMcxfMyXphpZ8XLmWcTKigTm1yi1fnW3cgEGVYRtl4buQN8= X-Google-Smtp-Source: APXvYqxiysHjWfZsD2GWAU7mCOwPRMiWbgX+spipJJeh+iGJshl9vq+E3JGeYvwYWJndgxtwbFzvafmyxSq2D/F76GY= X-Received: by 2002:a24:610b:: with SMTP id s11mr14721991itc.156.1556489135066; Sun, 28 Apr 2019 15:05:35 -0700 (PDT) MIME-Version: 1.0 References: <7dfaf793-1cb1-faef-d700-aa24ff4d50d9@gmail.com> In-Reply-To: <7dfaf793-1cb1-faef-d700-aa24ff4d50d9@gmail.com> From: Neil MacLeod Date: Sun, 28 Apr 2019 23:05:21 +0100 Message-ID: Subject: Re: Testing of r8169 workaround removal To: Heiner Kallweit Cc: "netdev@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Hi Heiner 5.0.6 is the first kernel that does NOT require the workaround. In 5.0.6 the only obvious r8169 change (to my untrained eyes) is: https://github.com/torvalds/linux/commit/4951fc65d9153deded3d066ab371a61977c96e8a but reverting this change in addition to the workaround makes no difference, the resulting kernel still resumes at 1000Mbps so I'm not sure what other change in .5.0.6 might be responsible for this changed behaviour. If you can think of anything I'll give it a try! Regards Neil PS. A while ago (5 Dec 2018 to be precise!) I emailed you about the ASPM issue which it looks like you may have fixed in 5.1-rc5[1]. Unfortunately I don't have this issue myself, and I've been trying to get feedback from the bug reporter[2,3] "Matt Devo" without much success but will confirm to you if/when he replies. 1, https://bugzilla.kernel.org/show_bug.cgi?id=202945 2. https://forum.kodi.tv/showthread.php?tid=298462&pid=2845944#pid2845944 3. https://forum.kodi.tv/showthread.php?tid=343069&pid=2850123#pid2850123 On Sun, 28 Apr 2019 at 19:43, Heiner Kallweit wrote: > > Interesting, thanks for your efforts! I submitted the patch removing > the workaround because it seems now (at least since 5.1-rc1) we're fine. > > Heiner > > On 28.04.2019 20:40, Neil MacLeod wrote: > > Hi Heiner > > > > I'd already kicked off a 5.0.2 build without the workaround and I've > > tested that now, and it resumes at 10Mbps, so it may still be worth > > identifying the exact 5.0.y version when it was fixed just in case > > that provides some understanding of how it was fixed... I'll test the > > remaining kernels between 5.0.3 and 5.0.10 as that's not much extra > > work and let you know what I find! > > > > Regards > > Neil > > > > On Sun, 28 Apr 2019 at 18:39, Heiner Kallweit wrote: > >> > >> Hi Neil, > >> > >> thanks for reporting back. Interesting, then the root cause of the > >> issue seems to have been in a different corner. On my hardware > >> I'm not able to reproduce the issue. It's not that relevant with which > >> exact version the issue vanished. Based on your results I'll just > >> remove the workaround on net-next (adding your Tested-by). > >> > >> Heiner > >> > >> > >> On 28.04.2019 19:30, Neil MacLeod wrote: > >>> Hi Heiner > >>> > >>> Do you know if this is already fixed in 5.1-rc6 (Linus Torvalds tree), > >>> as in order to test your request I thought I would reproduce the issue > >>> with plain 5.1-rc6 with the workaround removed, however without the > >>> workaround 5.1-rc6 is resuming correctly at 1000Mbps. > >>> > >>> I went back to 4.19-rc4 (which we know is brroken) and I can reproduce > >>> the issue with the PC (Revo 3700) resuming at 10Mbps, but with 5.1-rc6 > >>> I can no longer reproduce the issue when the workaround is removed. > >>> > >>> I also tested 5.0.10 without the workaround, and again 5.0.10 is > >>> resuming correctly at 1000Mbps. > >>> > >>> I finally tested 4.19.23 without the workaround (the last iteration of > >>> this kernel I published) and this does NOT resume correctly at > >>> 1000Mbps (it resumes at 10Mbps). > >>> > >>> I'll test a few more iterations of 5.0.y to see if I can identify when > >>> it was "fixed" but if you have any suggestions when it might have been > >>> fixed I can try to confirm this that - currently it's somewhere > >>> between 4.19.24 and 5.0.10! > >>> > >>> Regards > >>> Neil > >>> > >>> > >>> > >>> > >>> On Sun, 28 Apr 2019 at 14:33, Heiner Kallweit wrote: > >>>> > >>>> Hi Neil, > >>>> > >>>> you once reported the original issue resulting in this workaround. > >>>> This workaround shouldn't be needed any longer, but I have no affected HW > >>>> to test on. Do you have the option to apply the patch below to latest > >>>> net-next and test link speed after resume from suspend? > >>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > >>>> That would be much appreciated. > >>>> > >>>> Heiner > >>>> > >>>> ---------------------------------------------------------------- > >>>> > >>>> After 8c90b795e90f ("net: phy: improve genphy_soft_reset") this > >>>> workaround shouldn't be needed any longer. However I don't have > >>>> affected hardware so I can't test it. > >>>> > >>>> This was the bug report leading to the workaround: > >>>> https://bugzilla.kernel.org/show_bug.cgi?id=201081 > >>>> > >>>> Signed-off-by: Heiner Kallweit > >>>> --- > >>>> drivers/net/ethernet/realtek/r8169.c | 8 -------- > >>>> 1 file changed, 8 deletions(-) > >>>> > >>>> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c > >>>> index 383242df0..d4ec08e37 100644 > >>>> --- a/drivers/net/ethernet/realtek/r8169.c > >>>> +++ b/drivers/net/ethernet/realtek/r8169.c > >>>> @@ -4083,14 +4083,6 @@ static void rtl8169_init_phy(struct net_device *dev, struct rtl8169_private *tp) > >>>> phy_speed_up(tp->phydev); > >>>> > >>>> genphy_soft_reset(tp->phydev); > >>>> - > >>>> - /* It was reported that several chips end up with 10MBit/Half on a > >>>> - * 1GBit link after resuming from S3. For whatever reason the PHY on > >>>> - * these chips doesn't properly start a renegotiation when soft-reset. > >>>> - * Explicitly requesting a renegotiation fixes this. > >>>> - */ > >>>> - if (tp->phydev->autoneg == AUTONEG_ENABLE) > >>>> - phy_restart_aneg(tp->phydev); > >>>> } > >>>> > >>>> static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr) > >>>> -- > >>>> 2.21.0 > >>> > >> > > >