* Fwd: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
[not found] <af1b08f1-1280-ff66-4a43-70fa4487838c@googlemail.com>
@ 2018-09-28 12:54 ` Chris Clayton
0 siblings, 0 replies; only message in thread
From: Chris Clayton @ 2018-09-28 12:54 UTC (permalink / raw)
To: netdev
Forwarding to corrected netdev address.
-------- Forwarded Message --------
Subject: R8169: Network lockups in 4.18.{8,9,10} (and 4.19 dev)
Date: Fri, 28 Sep 2018 13:14:35 +0100
From: Chris Clayton <chris2553@googlemail.com>
To: linux-netdev@vger.kernel.org
CC: David Miller <davem@davemloft.net>, a3at.mail@gmail.com, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
hkallweit1@gmail.com, nic_swsd@realtek.com
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.
My investigation show that 4.18.7 is also OK, but 4.18.8 has the problem. So I cloned the stable tree and bisected
between 4.18.7 and 4.18.8. The outcome was:
$ git bisect bad
e366979eb8f0c3ad6446abbd81bcb3d4ac569cb3 is the first bad commit
commit e366979eb8f0c3ad6446abbd81bcb3d4ac569cb3
Author: Azat Khuzhin <a3at.mail@gmail.com>
Date: Sun Aug 26 17:03:09 2018 +0300
r8169: set RxConfig after tx/rx is enabled for RTL8169sb/8110sb devices
[ Upstream commit 05212ba8132b42047ab5d63d759c6f9c28e7eab5 ]
I have two Ethernet adapters:
r8169 0000:03:01.0 eth0: RTL8169sb/8110sb, 00:14:d1:14:2d:49, XID 10000000, IRQ 18
r8169 0000:01:00.0 eth0: RTL8168e/8111e, 64:66:b3:11:14:5d, XID 2c200000, IRQ 30
And after upgrading from linux 4.15 [1] to linux 4.18+ [2] RTL8169sb failed to
receive any packets. tcpdump shows a lot of checksum mismatch.
[1]: a0f79386a4968b4925da6db2d1daffd0605a4402
[2]: 0519359784328bfa92bf0931bf0cff3b58c16932 (4.19 merge window opened)
I started bisecting and the found that [3] breaks it. According to [4]:
"For 8110S, 8110SB, and 8110SC series, the initial value of RxConfig
needs to be set after the tx/rx is enabled."
So I moved rtl_init_rxcfg() after enabling tx/rs and now my adapter works
(RTL8168e works too).
[3]: 3559d81e76bfe3803e89f2e04cf6ef7ab4f3aace
[4]: e542a2269f232d61270ceddd42b73a4348dee2bb ("r8169: adjust the RxConfig
settings.")
Also drop "rx" from rtl_set_rx_tx_config_registers(), since it does nothing
with it already.
Fixes: 3559d81e76bfe3803e89f2e04cf6ef7ab4f3aace ("r8169: simplify
rtl_hw_start_8169")
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: Realtek linux nic maintainers <nic_swsd@realtek.com>
Signed-off-by: Azat Khuzhin <a3at.mail@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
:040000 040000 d95481376500f1bc5569fc486bc7573ea201b617 7985ef7b56e340312fe647c7c6e2a24998981304 M drivers
Ignoring the renaming of a function, the patch added a call to rtl_init_rxcfg() to rtl_hw_start(). If I remove that call
from 4.18.10, my network no longer fails after a resume from suspend.
I should add that I get the same problem with the current 4.19 development kernel, but I haven't tried removing the call
to rtl_init_rxcfg() from the driver. I'll do that later today and report back.
Details of my ethernet device from lspci are:
05:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
(rev 0a)
Subsystem: CLEVO/KAPOK Computer RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at f0004000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at f0000000 (64-bit, prefetchable) [size=16K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 10.000W
DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ NonFatalErr- FatalErr- UnsupReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported
AtomicOpsCap: 32bit- 64bit- 128bitCAS-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
AtomicOpsCtl: ReqEn-
LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
pcilib: sysfs_read_vpd: read failed: Input/output error
Not readable
Kernel driver in use: r8169
Kernel modules: r8169
I'm more then happy to provide any additional diagnostics are needed to solve this and to apply diagnostic patches and
proposed fixes.
Thanks
Chris
^ permalink raw reply [flat|nested] only message in thread