mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Heiner Kallweit <hkallweit1@gmail.com>
To: Chris Clayton <chris2553@googlemail.com>,
	"Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
Cc: Azat Khuzhin <a3at.mail@gmail.com>,
	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: Tue, 9 Oct 2018 23:39:16 +0200	[thread overview]
Message-ID: <e11f8eae-2bca-037b-9a7e-43c4276a2be6@gmail.com> (raw)
In-Reply-To: <7199b1e4-ce40-60ae-2a6a-ef7e95e563ea@googlemail.com>

On 09.10.2018 16:40, Chris Clayton wrote:
> Thanks to Maciej and Heiner for their replies.
> 
> On 09/10/2018 13:32, Maciej S. Szmigiero wrote:
>> On 07.10.2018 21:36, Chris Clayton wrote:
>>> Hi again,
>>>
>>> I didn't think there was anything in 4.19-rc7 to fix this regression, but tried it anyway. I can confirm that the
>>> regression is still present and my network still fails when, after a resume from suspend (to ram or disk), I open my
>>> browser or my mail client. In both those cases the failure is almost immediate - e.g. my home page doesn't get displayed
>>> in the browser. Pinging one of my ISPs name servers doesn't fail quite so quickly but the reported time increases from
>>> 14-15ms to more than 1000ms.
>>
>> You can try comparing chip registers (ethtool -d eth0) in the working
>> state (before a suspend) and in the broken state (after a resume).
>> Maybe there will be some obvious in the difference.
>>
>> The same goes for the PCI configuration (lspci -d :8168 -vv).
>>
> Maciej suggested comparing the output from lspci -vv for the ethernet device. They are identical.
> 
> Both Maciej and Heiner suggested comparing the output from "ethtool -d" pre and post suspend. Again, they are identical.
> Heiner specifically suggested looking at the RxConfig. The value of that is 0x0002870e both pre and post suspend.
> 
> I've attached files I redirected the outputs to.
> 
> Please don't hesitate to ask for any other information needed to solve this problem. In the meantime, I've now got
> scripts that stop the network during suspend and restart it during resume. (Those scripts were removed whilst I gathered
> the diagnostics shown in the attachments.)
> 
I'd like to check whether it may be a timing issue. The following experimental patch
adds a PCI commit after writing register ChipCmd. Could you please check whether
it changes anything?

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7d3f671e1..f3c359492 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4641,6 +4641,7 @@ static void rtl_hw_start(struct  rtl8169_private *tp)
 	/* Initially a 10 us delay. Turned it into a PCI commit. - FR */
 	RTL_R8(tp, IntrMask);
 	RTL_W8(tp, ChipCmd, CmdTxEnb | CmdRxEnb);
+	RTL_R8(tp, ChipCmd);
 	rtl_init_rxcfg(tp);
 	rtl_set_tx_config_registers(tp);
 
-- 
2.19.1


  parent reply	other threads:[~2018-10-09 21:39 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
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 [this message]
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=e11f8eae-2bca-037b-9a7e-43c4276a2be6@gmail.com \
    --to=hkallweit1@gmail.com \
    --cc=a3at.mail@gmail.com \
    --cc=chris2553@googlemail.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

Powered by JetHome