From: Chris Clayton <chris2553@googlemail.com>
To: Heiner Kallweit <hkallweit1@gmail.com>,
"Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: "David S. Miller" <davem@davemloft.net>,
Azat Khuzhin <a3at.mail@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Realtek linux nic maintainers <nic_swsd@realtek.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
Date: Sat, 29 Sep 2018 08:25:29 +0100 [thread overview]
Message-ID: <600d279d-357b-50c6-37f8-a4e96c7436a4@googlemail.com> (raw)
In-Reply-To: <98680351-5123-761f-982a-726098da9716@gmail.com>
On 28/09/2018 23:13, Heiner Kallweit wrote:
> On 29.09.2018 00:00, Chris Clayton wrote:
>> Thanks Maciej.
>>
>> On 28/09/2018 16:54, Maciej S. Szmigiero wrote:
>>> Hi,
>>>
>>>> Hi,
>>>>
>>>> I upgraded my kernel to 4.18.10 recently and have since been experiencing network problems after resuming from a
>>>> suspend to RAM or disk. I previously had 4.18.6 and that was OK.
>>>>
>>>> The pattern of the problem is that when I first boot, the network is fine. But, after resume from suspend I find that
>>>> the time taken for a ping of one of my ISP's nameservers increases from 14-15ms to more than 1000ms. Moreover, when I
>>>> open a browser (chromium or firefox), it fails to retrieve my home page (https://www.google.co.uk) and pings of the
>>>> nameserver fail with the message "Destination Host Unreachable". Often, I can revive the network by stopping it with
>>>> /sbin/if(down,up} but sometimes it is necessary to also remove the r8169 module and load it again.
>>>
>>> Please have a look at the following thread:
>>> https://lkml.org/lkml/2018/9/25/1118
>>>
>>
>> I applied your patch for the 4.18 stable kernels to 4.18.10, but the problem is not solved by it. Similarly, I applied
>> Heiner's patch to the 4.19, but again the problem is not solved.
>>
> I think we talk about two different issues here. The one the fix is for has no link to suspend/resume.
>
> Chris, the lspci output doesn't provide enough detail to determine the exact chip version.
> Can you provide the dmesg part with the XID?
$ dmesg | grep -i r8169
[ 5.320679] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 5.321432] r8169 0000:05:00.2: can't disable ASPM; OS doesn't have ASPM control
[ 5.322892] r8169 0000:05:00.2 eth0: RTL8411, 80:fa:5b:08:d0:3d, XID 48800800, IRQ 19
[ 5.323786] r8169 0000:05:00.2 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 10.232077] r8169 0000:05:00.2 eth0: No native access to PCI extended config space, falling back to CSI
[ 10.235218] r8169 0000:05:00.2 eth0: link down
[ 11.717460] r8169 0000:05:00.2 eth0: link up
$ dmesg | grep -i r8169
[ 5.208040] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 5.208677] r8169 0000:05:00.2: can't disable ASPM; OS doesn't have ASPM control
[ 5.210066] r8169 0000:05:00.2 eth0: RTL8411, 80:fa:5b:08:d0:3d, XID 48800800, IRQ 29
[ 5.210676] r8169 0000:05:00.2 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[ 10.456081] r8169 0000:05:00.2 eth0: No native access to PCI extended config space, falling back to CSI
[ 10.459217] r8169 0000:05:00.2 eth0: link down
[ 10.459880] r8169 0000:05:00.2 eth0: link down
[ 12.015158] r8169 0000:05:00.2 eth0: link up
> According to your lspci output neither MSI nor MSI-X is active.
> Do you have to use nomsi for whatever reason?
No, I do not use nomsi, but MSI wasn't enabled in my kernel config. I'm 99% sure that it used to be - I've no idea how
it got dropped. If I'm not sure about an option, I start by taking the recommendation in the kconfig help. Help on MSI
has a very clear "say Y".
>
> Heiner
>
>>> Maciej
>>>
>> Chris
>>
>
next prev parent reply other threads:[~2018-09-29 7:25 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-28 15:54 Maciej S. Szmigiero
2018-09-28 22:00 ` Chris Clayton
2018-09-28 22:13 ` Heiner Kallweit
2018-09-29 7:25 ` Chris Clayton [this message]
2018-09-29 7:38 ` Chris Clayton
2018-10-04 8:41 ` Chris Clayton
2018-10-07 19:36 ` Chris Clayton
2018-10-09 12:32 ` Maciej S. Szmigiero
2018-10-09 14:40 ` Chris Clayton
2018-10-09 20:36 ` Heiner Kallweit
2018-10-10 0:24 ` Maciej S. Szmigiero
2018-10-10 8:09 ` Chris Clayton
2018-10-10 8:51 ` Chris Clayton
2018-10-10 22:30 ` Chris Clayton
2018-10-10 22:32 ` Chris Clayton
2018-10-10 22:49 ` Chris Clayton
2018-10-11 0:12 ` Maciej S. Szmigiero
2018-10-11 8:24 ` Chris Clayton
2018-10-11 12:23 ` Maciej S. Szmigiero
2018-10-11 13:34 ` Chris Clayton
2018-10-09 21:39 ` Heiner Kallweit
2018-10-09 23:32 ` Chris Clayton
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=600d279d-357b-50c6-37f8-a4e96c7436a4@googlemail.com \
--to=chris2553@googlemail.com \
--cc=a3at.mail@gmail.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mail@maciej.szmigiero.name \
--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
all inboxes | Powered by JetHome®