Bug 201109
Summary: | r8169 - crash/lockup since 4.18.5 | ||
---|---|---|---|
Product: | Drivers | Reporter: | Tony (tatkinson321) |
Component: | Network | Assignee: | drivers_network (drivers_network) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | adam |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | >=4.18.5 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Tony
2018-09-12 22:16:08 UTC
I'm seeing the same issue on my Fedora 28 system since upgrading from 4.17.14 to 4.18.8 and later. Only occurs under reasonably high network load. I get a "transmit queue timed out" error, then the link seems to bounce up and down, but seems unable to send/receive packets. Using ethtool to force the interface down to 100Mbit doesn't seem to revive it. lspci -v: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet Flags: bus master, fast devsel, latency 0, IRQ 127 I/O ports at e000 [size=256] Memory at 81500000 (64-bit, non-prefetchable) [size=4K] Memory at a0100000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00 Capabilities: [170] Latency Tolerance Reporting 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c) Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet Flags: bus master, fast devsel, latency 0, IRQ 128 I/O ports at d000 [size=256] Memory at 81400000 (64-bit, non-prefetchable) [size=4K] Memory at a0000000 (64-bit, prefetchable) [size=16K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable- Count=4 Masked- Capabilities: [d0] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 01-00-00-00-68-4c-e0-00 Capabilities: [170] Latency Tolerance Reporting lspci -n: 01:00.0 0200: 10ec:8168 (rev 0c) Subsystem: 1458:e000 02:00.0 0200: 10ec:8168 (rev 0c) Subsystem: 1458:e000 dmesg gives the hardware IDs as: r8169 0000:01:00.0 eth0: RTL8168g/8111g, 40:8d:5c:d0:75:7b, XID 4c000800, IRQ 127 r8169 0000:01:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] r8169 0000:02:00.0 eth1: RTL8168g/8111g, 40:8d:5c:d0:75:7a, XID 4c000800, IRQ 128 r8169 0000:02:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] Disabling power management with: echo 'on' > '/sys/bus/pci/devices/0000:01:00.0/power/control' does not seem to prevent the issue. This issue has been fixed by the following patch by Heiner Kallweit https://www.spinics.net/lists/netdev/msg526003.html Hopefully making it's way up the chain into mainline and then down into the stable kernels Fix is now in mainline commit ad5f97faff4231e72b96bd96adbe1b6e977a9b86 |