Bug 199623

Summary:	r8169 takes a long time to get ready
Product:	Drivers	Reporter:	Sven Hesse (drmccoy)
Component:	Network	Assignee:	drivers_network (drivers_network)
Status:	NEW ---
Severity:	normal	CC:	felix.schwarz
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	4.16.7	Subsystem:
Regression:	No	Bisected commit-id:

Description Sven Hesse 2018-05-04 13:31:26 UTC

With kernel 4.16.7, my wired network (Lenovo E570 laptop, lspci line and full system specs below) take a long time to get ready.

So long that up'ing the device and then firing dhclient won't work. I need to up the device, ping my router, wait about 30 seconds of host unreachable messages until I get ping replies, and then I can start dhclient. When I just up the device without pinging anything, the device never becomes ready.

This seems to be a regression in 4.16.7, as it didn't happen in 4.16.6 (and before).

Relevant lspci line:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)

Full system specs via inxi (still with the 4.16.6 kernel): https://gist.github.com/DrMcCoy/d5e77fa937572e9d15c1a1e3505a73c4

dmesg log of me down'ing the device, up'ing, waiting for a bit, then starting the ping until I got replies:

[  845.651402] r8169 0000:04:00.0 enp4s0: link down
[  845.651483] r8169 0000:04:00.0 enp4s0: link down
[  845.651490] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[  848.412449] r8169 0000:04:00.0 enp4s0: link up
[  848.412464] IPv6: ADDRCONF(NETDEV_CHANGE): enp4s0: link becomes ready
[ 1005.034277] r8169 0000:04:00.0 enp4s0: link up

Comment 1 Sven Hesse 2018-05-05 12:30:19 UTC

And just now I got this here:

[ 1071.070745] NETDEV WATCHDOG: enp4s0 (r8169): transmit queue 0 timed out
[ 1071.070783] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:473 dev_watchdog+0x1ee/0x200
[ 1071.070784] Modules linked in: uinput nvidia_uvm(PO) nvidia_drm(PO) nvidia_modeset(PO) nvidia(PO) snd_hda_codec_generic iwlmvm x86_pkg_temp_thermal uvcvideo coretemp videobuf2_vmalloc snd_hda_intel videobuf2_memops videobuf2_v4l2 joydev snd_hda_codec input_leds pcspkr videobuf2_common snd_hwdep snd_hda_core i2c_i801 iwlwifi thinkpad_acpi led_class efivarfs
[ 1071.070874] CPU: 0 PID: 0 Comm: swapper/0 Tainted: P           O     4.16.7-gentoo #1
[ 1071.070877] Hardware name: LENOVO 20H5CTO1WW/20H5CTO1WW, BIOS R0DET91W (1.91 ) 01/24/2018
[ 1071.070882] RIP: 0010:dev_watchdog+0x1ee/0x200
[ 1071.070885] RSP: 0018:ffff88043f403ea0 EFLAGS: 00010286
[ 1071.070889] RAX: 000000000000003b RBX: 0000000000000000 RCX: ffffffff82655158
[ 1071.070891] RDX: 0000000000000001 RSI: 0000000000000092 RDI: ffffffff82e0962c
[ 1071.070894] RBP: ffff88042cf96438 R08: 0000000000000356 R09: 0000000000000003
[ 1071.070897] R10: ffff88043f403f00 R11: 0000000000000001 R12: ffff88042cf96000
[ 1071.070899] R13: 0000000000000000 R14: ffff88043f403ef0 R15: 0000000000000000
[ 1071.070903] FS:  0000000000000000(0000) GS:ffff88043f400000(0000) knlGS:0000000000000000
[ 1071.070907] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1071.070910] CR2: 00007fb697af0000 CR3: 0000000003a0a004 CR4: 00000000003606f0
[ 1071.070911] Call Trace:
[ 1071.070916]  <IRQ>
[ 1071.070924]  ? pfifo_fast_init+0x130/0x130
[ 1071.070933]  call_timer_fn+0x26/0x120
[ 1071.070941]  run_timer_softirq+0x391/0x3d0
[ 1071.070948]  ? tick_sched_timer+0x2f/0x70
[ 1071.070953]  ? __hrtimer_run_queues+0x105/0x260
[ 1071.070960]  ? recalibrate_cpu_khz+0x10/0x10
[ 1071.070964]  ? ktime_get+0x39/0x90
[ 1071.070981]  __do_softirq+0xd3/0x2a3
[ 1071.070991]  irq_exit+0xa3/0xb0
[ 1071.071003]  smp_apic_timer_interrupt+0x67/0x120
[ 1071.071016]  apic_timer_interrupt+0xf/0x20
[ 1071.071025]  </IRQ>
[ 1071.071040] RIP: 0010:cpuidle_enter_state+0x9b/0x2a0
[ 1071.071046] RSP: 0018:ffffffff82603eb0 EFLAGS: 00000216 ORIG_RAX: ffffffffffffff12
[ 1071.071060] RAX: ffff88043f420740 RBX: 00000000007940f5 RCX: 000000000000001f
[ 1071.071067] RDX: 000000f960c9ec31 RSI: 000000002c13bf1e RDI: 0000000000000000
[ 1071.071073] RBP: ffff88043f4288e0 R08: 0000000000007fe0 R09: 0000000000000f4e
[ 1071.071078] R10: ffffffff82603e98 R11: 00000000000014ad R12: 0000000000000006
[ 1071.071086] R13: ffffffff826f26b8 R14: 0000000000000000 R15: 000000f96050ab3c
[ 1071.071097]  do_idle+0x163/0x1a0
[ 1071.071107]  cpu_startup_entry+0x14/0x20
[ 1071.071116]  start_kernel+0x3c4/0x3cc
[ 1071.071127]  secondary_startup_64+0xa5/0xb0
[ 1071.071133] Code: 57 00 48 63 4d e8 eb 93 4c 89 e7 c6 05 80 21 ce 00 01 e8 86 91 fd ff 89 d9 48 89 c2 4c 89 e6 48 c7 c7 10 89 51 82 e8 32 eb 65 ff <0f> 0b eb c0 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 41 57 41 
[ 1071.071214] ---[ end trace a1610e9ae95cd702 ]---
[ 1071.078533] r8169 0000:04:00.0 enp4s0: link up

Comment 2 Felix Schwarz 2019-11-06 10:27:30 UTC

just a random question: It seems as if this might be the same issue as bug 199549 which was fixed 4.17-rc5 ( https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3148dedfe79e422f448a10250d3e2cdf8b7ee617 ).

Can you still reproduce the problem?

Comment 3 Sven Hesse 2019-11-06 10:39:13 UTC

Ah, right, completely forgot about this. No, I don't have that issue anymore.