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=-11.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 9B795C43219 for ; Sun, 28 Apr 2019 18:43:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5379720693 for ; Sun, 28 Apr 2019 18:43:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NAtwL2pv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727112AbfD1Sn0 (ORCPT ); Sun, 28 Apr 2019 14:43:26 -0400 Received: from mail-wr1-f65.google.com ([209.85.221.65]:33947 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726940AbfD1SnZ (ORCPT ); Sun, 28 Apr 2019 14:43:25 -0400 Received: by mail-wr1-f65.google.com with SMTP id v16so10066478wrp.1 for ; Sun, 28 Apr 2019 11:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AE/Fg4BbvVpsJGbL445HFklsWcn1BM/R4/Bp7g3ee1A=; b=NAtwL2pv8gntiGaXscJed1BY5Z+IeaSAXj2+VhclZdAYlraHlvvvIGABBDgh3iJ7n1 o5C3O1BCF4BUrG5GL9gVHgQsmMkHk2484/qUcbuN4yotoOyPyaxDMlj4hK5knJbRYHB7 v3yIVyzTsOYZbZ9m4ycU0JJ+suI/cmgSqSPclUUPS6QMonG1NgCkJhTGHhubaAJjdLH+ dKz1EPTEpZyuPfBtwSwh5yryOE32ZoIVAx7Ntrbrpu5LXqChFxZWLoGqQn/A4L2rOoaB Y1upTJP/nuP6M6XlZNKtB4GDwpurtFxtubmhc6kDpAuGAsrCUPvcopLaRgcvijIc7e5P W4AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AE/Fg4BbvVpsJGbL445HFklsWcn1BM/R4/Bp7g3ee1A=; b=A63xNt8I8j9v56bfraN7qKE2V3R7WwQzRrLfoM9Kswk7qG+nCmM/jgezBfyM6UBLed Jud31V5ekn73Rchp/DqAa7V3mBkpQY8GKK5uv/7mga3hNbigeZCjOhVUbOSPs/VA6QVr 62LdmlGc/NQXJFwTsn1m/ULD/EMNgusabU5p146wXjlwZmkaV5Pej+rIL+ZCrtVsT+xc CBCMECswsWqsUonuU5M93npPzX3Jyv+Q00uplz3Pqte6uvbi0F2d07A6D2xGCHES6kp1 hYoZRmXqlbQjuxcZTKMS2hBXL24Q1dohPv+3vf3WCAMcy9EDo2HdG1C2bt+ftnZf5ct6 M13g== X-Gm-Message-State: APjAAAX0HgdPfRZBZq2c7s1hqbPUXeKLO5aLvvH9zGJtLvoVHo+ptdU4 NJGCAc+/zxKwv61fVecNhMQZSwTVf0s= X-Google-Smtp-Source: APXvYqxaG+gEvWQEYYzG0+5H2wtWUJ9QxaqaG40Fcm8oB8CO0fPbcVbEPkHdUaHVqDFM5pOKDdpWgA== X-Received: by 2002:adf:f34b:: with SMTP id e11mr4122727wrp.18.1556477003153; Sun, 28 Apr 2019 11:43:23 -0700 (PDT) Received: from ?IPv6:2003:ea:8bd4:5700:8cd5:5d39:576c:7f5f? (p200300EA8BD457008CD55D39576C7F5F.dip0.t-ipconnect.de. [2003:ea:8bd4:5700:8cd5:5d39:576c:7f5f]) by smtp.googlemail.com with ESMTPSA id z140sm64593586wmc.27.2019.04.28.11.43.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Apr 2019 11:43:22 -0700 (PDT) Subject: Re: Testing of r8169 workaround removal To: Neil MacLeod Cc: "netdev@vger.kernel.org" References: From: Heiner Kallweit Message-ID: <7dfaf793-1cb1-faef-d700-aa24ff4d50d9@gmail.com> Date: Sun, 28 Apr 2019 20:43:19 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 >>> >> >