From: Chris Chiu <chiu@endlessm.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: nic_swsd <nic_swsd@realtek.com>,
davem@davemloft.net, netdev@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux Upstreaming Team <linux@endlessm.com>
Subject: Re: A weird problem of Realtek r8168 after resume from S3
Date: Tue, 18 Dec 2018 20:31:20 +0800 [thread overview]
Message-ID: <CAB4CAwf5QnCRFRT-=XAdCAKQv8rshnzVVpedCDyOag+nzuFOQA@mail.gmail.com> (raw)
In-Reply-To: <3c0837d1-0e9f-0a4c-ce50-db766c02aa8b@gmail.com>
On Tue, Dec 18, 2018 at 5:45 AM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 17.12.2018 14:25, Chris Chiu wrote:
> > On Fri, Dec 14, 2018 at 3:37 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>
> >> On 14.12.2018 04:33, Chris Chiu wrote:
> >>> On Thu, Dec 13, 2018 at 10:20 AM Chris Chiu <chiu@endlessm.com> wrote:
> >>>>
> >>>> Hi,
> >>>> We got an acer laptop which has a problem with ethernet networking after
> >>>> resuming from S3. The ethernet is popular realtek r8168. The lspci shows as
> >>>> follows.
> >>>> 02:00.1 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd.
> >>>> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 12)
> >>>>
> >> Helpful would be a "dmesg | grep r8169", especially chip name + XID.
> >>
> > [ 22.362774] r8169 0000:02:00.1 (unnamed net_device)
> > (uninitialized): mac_version = 0x2b
> > [ 22.365580] libphy: r8169: probed
> > [ 22.365958] r8169 0000:02:00.1 eth0: RTL8411, 00:e0:b8:1f:cb:83,
> > XID 5c800800, IRQ 38
> > [ 22.365961] r8169 0000:02:00.1 eth0: jumbo features [frames: 9200
> > bytes, tx checksumming: ko]
> >
> >>>> The problem is the ethernet is not accessible after resume. Pinging via
> >>>> ethernet always shows the response `Destination Host Unreachable`. However,
> >>>> the interesting part is, when I run tcpdump to monitor the problematic ethernet
> >>>> interface, the networking is back to alive. But it's dead again after
> >>>> I stop tcpdump.
> >>>> One more thing, if I ping the problematic machine from others, it achieves the
> >>>> same effect as above tcpdump. Maybe it's about the register setting for RX path?
> >>>>
> >> You could compare the register dumps (ethtool -d) before and after S3 sleep
> >> to find out whether there's a difference.
> >>
> >
> > Actually, I just found I lead the wrong direction. The S3 suspend does
> > help to reproduce,
> > but it's not necessary. All I need to do is ping around 5 mins and the
> > network connection
> > fails. And I also find one thing interesting, disabling the MSI-X
> > interrupt like commit
> > [d49c88d7677ba737e9d2759a87db0402d5ab2607] can fix this problem.
> > Although I don't
> > understand the root cause. Anything I can do to help?
> >
> One more thing: I checked the vendor driver and it uses a different sequence
> to initialize the ePHY. Could you please check whether the following patch
> makes a difference? I don't have much hope but it's worth a try.
>
> diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
> index 8462553e3..7cfb22e05 100644
> --- a/drivers/net/ethernet/realtek/r8169.c
> +++ b/drivers/net/ethernet/realtek/r8169.c
> @@ -5097,11 +5097,16 @@ static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
> static void rtl_hw_start_8411_2(struct rtl8169_private *tp)
> {
> static const struct ephy_info e_info_8411_2[] = {
> - { 0x00, 0x0000, 0x0008 },
> - { 0x0c, 0x3df0, 0x0200 },
> - { 0x0f, 0xffff, 0x5200 },
> - { 0x19, 0x0020, 0x0000 },
> - { 0x1e, 0x0000, 0x2000 }
> + { 0x00, 0x0008, 0x0000 },
> + { 0x0c, 0x37d0, 0x0820 },
> + { 0x1e, 0x0000, 0x0001 },
> + { 0x19, 0x8021, 0x0000 },
> + { 0x1e, 0x0000, 0x2000 },
> + { 0x0d, 0x0100, 0x0200 },
> + { 0x00, 0x0000, 0x0080 },
> + { 0x06, 0x0000, 0x0010 },
> + { 0x04, 0x0000, 0x0010 },
> + { 0x1d, 0x0000, 0x4000 },
> };
>
> rtl_hw_start_8168g(tp);
> --
> 2.20.0
>
As you expected, I applied the phy init change for this specific MAC_VER_43,
it makes no difference.
>
> >>>> I tried the latest 4.20 rc version but the problem still there. I
> >>>> also tried some
> >>>> hw_reset or init thing in the resume path but no effect. Any
> >>>> suggestion for this?
> >>>> Thanks
> >>>>
> >> Did previous kernel versions work? If it's a regression, a bisect would be
> >> appreciated, because with the chip versions I've got I can't reproduce the issue.
> >>
> >>>> Chris
> >>>
> >>> Gentle ping. Any additional information required?
> >>>
> >>> Chris
> >>>
> >> Heiner
> >
>
prev parent reply other threads:[~2018-12-18 12:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 2:20 A weird problem of Realtek r8168 after resume from S3 Chris Chiu
2018-12-14 3:33 ` Chris Chiu
2018-12-14 7:36 ` Heiner Kallweit
2018-12-17 13:25 ` Chris Chiu
2018-12-17 19:08 ` Heiner Kallweit
2018-12-18 13:25 ` Chris Chiu
2018-12-18 18:21 ` Heiner Kallweit
2018-12-19 14:37 ` Chris Chiu
2018-12-18 20:28 ` Heiner Kallweit
2018-12-19 15:32 ` Chris Chiu
2018-12-19 19:41 ` Heiner Kallweit
2018-12-20 9:43 ` Chris Chiu
2018-12-20 18:48 ` Heiner Kallweit
2018-12-20 19:21 ` Heiner Kallweit
2018-12-21 15:16 ` Chris Chiu
2018-12-17 21:45 ` Heiner Kallweit
2018-12-18 12:31 ` Chris Chiu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB4CAwf5QnCRFRT-=XAdCAKQv8rshnzVVpedCDyOag+nzuFOQA@mail.gmail.com' \
--to=chiu@endlessm.com \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@endlessm.com \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).