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  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:   Sun, 28 Apr 2019 18:30:00 +0100
From:   Neil MacLeod <>
To:     Heiner Kallweit <>
Cc:     "" <>
Subject: Re: Testing of r8169 workaround removal

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!


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://
> 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:
> 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

Powered by blists - more mailing lists