You are not logged in.

#1 2018-11-29 18:14:50

pppppass
Member
Registered: 2018-11-29
Posts: 9

[SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

TL;DR My system freezes when managing ethernet with either dhcpcd or NetworkManager since some point between 4.18 and 4.19. I bisected the kernel and finally found this issue is related to rtl8168evl and kernel module r8169. Final solution is
1. Blacklist r8169;
2. Install r8168-dkms.

Hi, everyone. I have two machines running Arch Linux smoothly for roughly one year, but when the kernel upgrades to 4.19, problems occurred on one of the machine. I have spent hours debugging but still cannot figure out how to solve the problem.

What happened:
The system freezes during login. The graphics just freezes as well as the cursor, without broken image (at most cases). It has no response to mouse or keyboard, nor CTRL+ALT+Fn magic key or remote login through ssh (with RJ45 plugged but "no route to host" from another machine). Generally the freeze occurs when the login page (of gdm) is shown and i start to move my mouse for some seconds, but it can still happens before the i move the mouse (so the cursor is shown on the screen but i was unable to move it) or before the login page is shown (so i get a black screen). The freeze can last for hours and only cold power off can stop.
The last success upgrade was on about Nov 08 and the running kernel is 4.18. When I upgrade on about Nov 20 to 4.19, strange freeze comes into the place.

What have I tried:
(-1). "pacman -Syyuu" and reinstalling do not work.
0. Journal gives me no hint since it stops just after "Time spent on flushing to /var is 63.602ms for 693 entries.". A failure case (with 4.19) is https://drive.google.com/open?id=1ggwV3 … tlySB5_y4E, while a success case (with 4.18) is https://drive.google.com/open?id=180b5_ … 1vIy8nKVZz.
1. Disabling gdm does not help. It still gets stuck at the command line login page and i cannot type in my user name. No response again.
1. linux-lts helps, but some other up-to-date applications are not compatible with old kernels, say VirtualBox.
2. Downgrade the packages using pacman history cache helps. To be exact, returning back to Nov 12 (with kernel 4.18.16) helps but Nov 15 (with kernel 4.19.1) fails.
3. linux-mainline (4.20) does not help.
4. Kernel parameter "acpi=off" helps, but two of logical processors are missing since i am using i7-6500 (2 cores, 4 threads) with hyper-threading. "lscpu" gives

$ lscpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
Address sizes:       39 bits physical, 48 bits virtual
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  2
Core(s) per socket:  2
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               78
Model name:          Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz
Stepping:            3
CPU MHz:             3057.877
CPU max MHz:         3100.0000
CPU min MHz:         400.0000
BogoMIPS:            5186.00
Virtualization:      VT-x
L1d cache:           32K
L1i cache:           32K
L2 cache:            256K
L3 cache:            4096K
NUMA node0 CPU(s):   0-3
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp flush_l1d

5. Kernel parameter "acpi=ht", "acpi=oldboot", "acpi= "noapic", "acpi.power_nocheck=1 ", "pci=noacpi" and "acpi=noirq" freezes at the login page. "nolapic" significantly slows down the system and causes time outs in the beginning, activates the rescue shell and cannot load any other things.
6. "dmesg | grep DSDT" yields

# dmesg | grep DSDT
[    0.000000] ACPI: DSDT 0x000000008CE701B8 01D096 (v02 ALASKA A M I    01072009 INTL 20120913)".

7. Kernel parameter "acpi_osi=Linux", "acpi_osi="Windows 2012"", "acpi_os_name=Linux", "acpi_os_name="Windows 2012"" all fails. Both "Linux" and "Windows 2012" are in the conditionals in my disassembled DSDT .asl files.

I am also noticing that after GRUB startup screen, logo of BIOS flashes on the black screen after i have upgraded to 4.19 on both of the machines. I may try upgrading BIOS days later but it seems dangerous operating on Linux.

Last edited by pppppass (2019-01-21 03:51:35)

Offline

#2 2018-11-29 18:31:03

loqs
Member
Registered: 2014-03-06
Posts: 19,105

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

"crng init done" is not present in the bad log can you try booting 4.19.Y with the kernel parameter random.trust_cpu=on to rule out lack of entropy.
Edit:
Oh and welcome to the arch linux forums pppppass.

Last edited by loqs (2018-11-29 18:32:58)

Offline

#3 2018-11-29 18:43:18

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

Thanks loqs. I tried but it still got frozen. The journal is https://drive.google.com/open?id=1N79PP … egx4KJLpb9.

Offline

#4 2018-11-29 19:05:08

loqs
Member
Registered: 2014-03-06
Posts: 19,105

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

Nov 30 02:33:51 LZH-ST-ARCH kernel: general protection fault: 0000 [#1] PREEMPT SMP PTI
Nov 30 02:33:51 LZH-ST-ARCH kernel: CPU: 0 PID: 501 Comm: gnome-shell Tainted: G           OE     4.19.4-arch1-1-ARCH #1
Nov 30 02:33:51 LZH-ST-ARCH kernel: Hardware name: Default string Default string/SKYBAY, BIOS 5.11 08/09/2016
Nov 30 02:33:51 LZH-ST-ARCH kernel: RIP: 0010:do_sys_poll+0x22b/0x520
Nov 30 02:33:51 LZH-ST-ARCH kernel: Code: 83 e1 fc 0f 84 e9 01 00 00 45 0f b7 67 04 44 89 e0 25 ff 27 00 00 83 c8 18 41 89 c4 44 09 f0 89 84 24 68 01 00 00 48 8b 41 28 <48> 8b 40 40 48 85 c0 0f 84 b1 01 00 00 4c 89 44 24 40 48 89 cf 48
Nov 30 02:33:51 LZH-ST-ARCH kernel: RSP: 0018:ffff9546c1517af0 EFLAGS: 00010202
Nov 30 02:33:51 LZH-ST-ARCH kernel: RAX: fff0ffff8faea6e0 RBX: ffff9546c1517b50 RCX: ffff8dfda472e200
Nov 30 02:33:51 LZH-ST-ARCH kernel: RDX: ffff8dfda472e238 RSI: 0000000000004000 RDI: 000000000000000d
Nov 30 02:33:51 LZH-ST-ARCH kernel: RBP: ffff9546c1517f00 R08: ffff8dfda472e201 R09: 00000000000001a2
Nov 30 02:33:51 LZH-ST-ARCH kernel: R10: 00000000000001a2 R11: ffff8dfda6a20be8 R12: 0000000000000019
Nov 30 02:33:51 LZH-ST-ARCH kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff9546c1517b7c
Nov 30 02:33:51 LZH-ST-ARCH kernel: FS:  00007f26f8b56100(0000) GS:ffff8dfda6a00000(0000) knlGS:0000000000000000
Nov 30 02:33:51 LZH-ST-ARCH kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 30 02:33:51 LZH-ST-ARCH kernel: CR2: 00007f26f8313004 CR3: 000000025142c006 CR4: 00000000003606f0
Nov 30 02:33:51 LZH-ST-ARCH kernel: Call Trace:
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? preempt_count_add+0x79/0xb0
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? _raw_spin_lock+0x13/0x40
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? _raw_spin_unlock+0x16/0x30
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? unix_stream_read_generic+0x204/0x850
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  ? compat_poll_select_copy_remaining+0x150/0x150
Nov 30 02:33:51 LZH-ST-ARCH kernel:  __se_sys_poll+0x94/0x130
Nov 30 02:33:51 LZH-ST-ARCH kernel:  do_syscall_64+0x5b/0x170
Nov 30 02:33:51 LZH-ST-ARCH kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Nov 30 02:33:51 LZH-ST-ARCH kernel: RIP: 0033:0x7f2702b0ac21
Nov 30 02:33:51 LZH-ST-ARCH kernel: Code: 00 41 54 41 89 d4 55 48 89 f5 53 48 89 fb 48 83 ec 10 e8 52 85 01 00 44 89 e2 48 89 ee 48 89 df 41 89 c0 b8 07 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 89 44 24 0c e8 8b 85 01 00 8b 44
Nov 30 02:33:51 LZH-ST-ARCH kernel: RSP: 002b:00007fffbb2a2600 EFLAGS: 00000293 ORIG_RAX: 0000000000000007
Nov 30 02:33:51 LZH-ST-ARCH kernel: RAX: ffffffffffffffda RBX: 00005562b976a600 RCX: 00007f2702b0ac21
Nov 30 02:33:51 LZH-ST-ARCH kernel: RDX: 0000000000000003 RSI: 000000000000000e RDI: 00005562b976a600
Nov 30 02:33:51 LZH-ST-ARCH kernel: RBP: 000000000000000e R08: 0000000000000000 R09: 0000000000000001
Nov 30 02:33:51 LZH-ST-ARCH kernel: R10: 00005562b7822a00 R11: 0000000000000293 R12: 0000000000000003
Nov 30 02:33:51 LZH-ST-ARCH kernel: R13: 00007f2702510e90 R14: 0000000000000003 R15: 000000000000000e
Nov 30 02:33:51 LZH-ST-ARCH kernel: Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic brcmsmac cordic brcmutil b43 mac80211 snd_soc_skl snd_soc_skl_ipc i915 snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi intel_rapl cfg80211 snd_soc_core snd_compress ac97_bus x86_pkg_temp_thermal snd_pcm_dmaengine intel_powerclamp coretemp ssb snd_hda_intel kvm_intel mmc_core snd_hda_codec rfkill pcmcia joydev mousedev pcmcia_core input_leds kvmgt rng_core snd_hda_core vfio_mdev mdev vfio_iommu_type1 vfio snd_hwdep crct10dif_pclmul kvm crc32_pclmul ghash_clmulni_intel nls_iso8859_1 snd_pcm nls_cp437 pcbc iTCO_wdt iTCO_vendor_support vfat fat aesni_intel aes_x86_64 irqbypass crypto_simd cryptd glue_helper i2c_algo_bit realtek intel_cstate drm_kms_helper snd_timer intel_th_gth
Nov 30 02:33:51 LZH-ST-ARCH kernel:  r8169 intel_uncore snd intel_rapl_perf drm intel_th_pci bcma pcspkr intel_th libphy i2c_i801 soundcore intel_gtt agpgart syscopyarea sysfillrect evdev sysimgblt fb_sys_fops intel_pch_thermal mac_hid pcc_cpufreq vboxnetflt(OE) vboxnetadp(OE) vboxpci(OE) vboxdrv(OE) sg crypto_user ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 uas fscrypto usb_storage hid_generic usbhid hid sd_mod ahci libahci xhci_pci libata xhci_hcd scsi_mod crc32c_intel
Nov 30 02:33:51 LZH-ST-ARCH kernel: ---[ end trace 99c300e3bf32ff43 ]---
Nov 30 02:33:51 LZH-ST-ARCH kernel: RIP: 0010:do_sys_poll+0x22b/0x520
Nov 30 02:33:51 LZH-ST-ARCH kernel: Code: 83 e1 fc 0f 84 e9 01 00 00 45 0f b7 67 04 44 89 e0 25 ff 27 00 00 83 c8 18 41 89 c4 44 09 f0 89 84 24 68 01 00 00 48 8b 41 28 <48> 8b 40 40 48 85 c0 0f 84 b1 01 00 00 4c 89 44 24 40 48 89 cf 48
Nov 30 02:33:51 LZH-ST-ARCH kernel: RSP: 0018:ffff9546c1517af0 EFLAGS: 00010202
Nov 30 02:33:51 LZH-ST-ARCH kernel: RAX: fff0ffff8faea6e0 RBX: ffff9546c1517b50 RCX: ffff8dfda472e200
Nov 30 02:33:51 LZH-ST-ARCH kernel: RDX: ffff8dfda472e238 RSI: 0000000000004000 RDI: 000000000000000d
Nov 30 02:33:51 LZH-ST-ARCH kernel: RBP: ffff9546c1517f00 R08: ffff8dfda472e201 R09: 00000000000001a2
Nov 30 02:33:51 LZH-ST-ARCH kernel: R10: 00000000000001a2 R11: ffff8dfda6a20be8 R12: 0000000000000019
Nov 30 02:33:51 LZH-ST-ARCH kernel: R13: 0000000000000000 R14: 0000000000000000 R15: ffff9546c1517b7c
Nov 30 02:33:51 LZH-ST-ARCH kernel: FS:  00007f26f8b56100(0000) GS:ffff8dfda6a00000(0000) knlGS:0000000000000000
Nov 30 02:33:51 LZH-ST-ARCH kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Nov 30 02:33:51 LZH-ST-ARCH kernel: CR2: 00007f26f8313004 CR3: 000000025142c006 CR4: 00000000003606f0
Nov 30 02:33:51 LZH-ST-ARCH kernel: BUG: unable to handle kernel paging request at ffff9546c1517ce8

If you do not load vboxnetflt vboxnetadp vboxpci vboxdrv does that make any difference?
Otherwise you might have to besiect between 4.18 and 4.19 to find the causal commit.

Offline

#5 2018-11-29 19:13:41

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

I have once uninstalled VirtualBox and the vbox* module but this did not help either. Thanks a lot.

Offline

#6 2018-11-29 22:14:31

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 78,680

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

Tried haveged instead of random.trust_cpu=on (or just waiting/generating more entropy)?

Offline

#7 2018-11-30 17:05:58

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

Enabling haveged makes no difference. The freeze can lasts for 3 hours until i shut the power, so i suppose just waiting cannot solve the problem. (Maybe i should try keeping moving my mouse to produce more entropy?)

By the way, i am wondering whether the journal is incomplete since it stops at "systemd-journald[239]: Time spent on flushing to /var is 63.602ms for 693 entries"? Sometimes there are core dumps at the end (e.g. the one in #3) but most of them just ends at "flushing to /var". Is it true that the journal is incomplete? It this caused by buffer issues and is it possible to obtain a more complete journal?

Offline

#8 2018-11-30 21:24:04

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 78,680

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

Humm? The journal you posted stops at a kernel paging request bug?
Or is that error gone after removing vbox?

Offline

#9 2018-12-03 06:03:20

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

The failed journal posted on #1 (https://drive.google.com/open?id=1ggwV3 … tlySB5_y4E) just stops at flushing to /var.

And the error is still there after uninstalling vbox.

Last edited by pppppass (2018-12-03 11:40:11)

Offline

#10 2018-12-03 08:48:05

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 78,680

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

But that was before fixing the entropy issue as suggested by loqs. Also the journal flush is no error - but no, it's usually not the end of a log.


The problem is the post #4 excerpt - to be sure: this still shows up in the logs after removing the vbox modules? Can you post an updated journal?
The cause is most likely some bogus module (where the rule of thumb is "more fringe, more likely") - there are three ways to figure which:
   1 . smart guessing
   2. bisecting the kernel (to isolate the compromising conflict)
   3. https://wiki.archlinux.org/index.php/Kdump

(1) is the least PITA, (2) is the most rewarding.

Wild guess would be the wifi-area: brcmsmac, brcmutil, b43, mac80211 - because brcmsmac and b43 cover the same device? and also iirc the rtlwifi issue was actually related to mac80211.
So blacklisting the wifi modules may get you somewhere. https://wiki.archlinux.org/index.php/Ke … acklisting

Offline

#11 2018-12-03 11:38:02

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

I enabled haveged, uninstalled virtualbox and virtualbox-host-modules-arch and made three attempts. One of them (https://drive.google.com/open?id=10dNC6 … sq2B2Hx7pw) printed some information but two of them just ended at flushing (https://drive.google.com/open?id=1-EhoL … 9VKHAfp9T5), (https://drive.google.com/open?id=1faBZU … j3K-J1y3Wq). The parameters and packages are identical.

I also tried blacklisting using kernel parameter "module_blacklist=nouveau,brcmsmac,brcmutil,b43,mac80211", the journal log is shown in (https://drive.google.com/open?id=12F-iI … GjLQj11ir6).

(All of these crashed eventually.)

Offline

#12 2018-12-03 14:04:18

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 78,680

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

https://drive.google.com/file/d/1-EhoLC … fp9T5/view and https://drive.google.com/file/d/1faBZUo … 1y3Wq/view show no indication of haveged, so this is very most likely a lack of entropy, probably due to the crypto_user load?

https://drive.google.com/file/d/10dNC66 … Hx7pw/view is "just" an ordinary userspace segfault in gnome-shell (which interestingly also triggered the kernel protection fault) - so my next best suggestion would be to try w/ "random.trust_cpu=on" (side-stepping the entropy issue) but w/O gnome (or gdm for that matter).
Try to boot into a multi-user.target and startx some openbox session. You can also try sddm/plasma as a more "heavy" and similar HW stressing variation - and see whether the system still crashes.

Other things to try would be whether this is a relation between the intel ddx and kernel module (since you pointed out the kernel version relevance). Try to use xf86-video-intel instead of the modesetting driver (just install the package) and alternatively GDM/gnome on wayland.

Offline

#13 2019-01-16 18:05:45

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

I happen to find that disabling NetworkManager gets the system alive. However, when I try to dhcpcd the interface enp1s0 again, or simply start NetworkManager, the system freezes. Whether the cable is connected seems making no difference.

The output of "sudo dhcpcd enp1s0" is

# dhcpcd enp1s0
enp1s0: waiting for carrier
enp1s0: carrier acquired
DUID 00:01:00:01:22:42:ac:5e:00:e0:4c:68:23:b1
enp1s0: IAID 4c:68:23:b1
enp1s0: adding address fe80::3bb3:f3d5:16bb:a3c2
enp1s0: carrier lost
enp1s0: deleting address fe80::3bb3:f3d5:16bb:a3c2
enp1s0: carrier acquired
enp1s0: IAID 4c:68:23:b1
enp1s0: adding address fe80::3bb3:f3d5:16bb:a3c2
<FROZEN>
<If I try kernel parameter acpi=off as mentioned before, everything works smoothly (except for hyperthreading) and I will get the following>
enp1s0: soliciting an IPv6 router
enp1s0: soliciting a DHCP lease
enp1s0: Router Advertisement from fe80::12bd:18ff:fee5:6200
enp1s0: adding address 2001:da8:201:2700:b9fd:3a75:755c:8b3d/64
enp1s0: adding route to 2001:da8:210:2700::/64
enp1s0: adding default route viad fe80::12bd:18ff:fee5:6200
enp1s0: offered 10.128.200.183 from 115.27.254.2
enp1s0: probing address 10.128.200.183/24
enp1s0: leased 10.128.200.183 for 7200 seconds
enp1s0: adding route to 10.128.200.0/24
enp1s0: adding default route via 10.128.200.1
forked to background, child pid 766

Sometimes there are prompts saying CPU soft lockups, and sometimes call traces are printed on the screen. However I cannot find call traces in the journal. It seems completely random whether call trace is presented... Maybe I need to try some more times?

"lspci" gives

$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation Skylake GT2 [HD Graphics 520] (rev 07)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 20)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 20)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 20)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f0)
00:1c.3 PCI bridge: Intel Corporation Device 9d13 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 20)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 20)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 20)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 20)
00:1f.7 Non-Essential Instrumentation [1300]: Intel Corporation Device 9d26 (rev 20)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07)
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43224 802.11a/b/g/n (rev 01)

(By the way, I have upgraded to 4.20. The whole story is: I made a clean installation on another disk to test whether the cause was something I had installed. The first boot was successful, but when I dhcpcd enp1s0, it stuck. Since lts comes to 4.19, it also freezes now.)

Last edited by pppppass (2019-01-21 03:26:15)

Offline

#14 2019-01-21 03:41:24

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

I managed to bisect the kernel and finally got the solution. The first bad commit is

commit aa1e7d2c31efd561fbbecc77eb785c8af685c1af (HEAD, refs/bisect/bad)
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sat Jun 23 09:53:00 2018 +0200

    r8169: enable ASPM on RTL8168E-VL
    
    Let's enable ASPM also on the RTL8168E-VL (chip version 34).
    Works fine on my Zotac Mini PC with this chip. Temperature when
    being idle is significantly lower than before due to reaching
    deeper PC states.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

Inspecting journal and hardware information verifies that I am indeed using rtl8168evl. As a ethernet driver issue, the system breaks exactly when I try to manage ethernet interfaces, as told in #13.

So the solution is
1. Blacklisting r8169 kernel module and install r8168-dkms from AUR, which is made by Realtek (if I do not mistake).
2. Or building my custom kernel with this commit ``reverted'', say comment line 4967 in "drivers/net/ethernet/realtek/r8169.c"

diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 298930d39b79..4b21e8c4270c 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4964,7 +4964,7 @@ static void rtl_hw_start_8168e_2(struct rtl8169_private *tp)
        RTL_W32(tp, MISC, RTL_R32(tp, MISC) | PWM_EN);
        RTL_W8(tp, Config5, RTL_R8(tp, Config5) & ~Spi_en);
 
-       rtl_hw_aspm_clkreq_enable(tp, true);
+       //rtl_hw_aspm_clkreq_enable(tp, true);
 }
 
 static void rtl_hw_start_8168f(struct rtl8169_private *tp).

Either method works for mainline and stable kernel.

Thanks a lot for your help.

Last edited by pppppass (2019-01-21 04:49:52)

Offline

#15 2019-01-21 09:18:27

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 78,680

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

You should certainly file a bugreport on this,  https://bugzilla.kernel.org/ and you might also want to figure whether this is the direct cause or simply a trigger to https://wiki.archlinux.org/index.php/In … ete_freeze

Offline

#16 2019-01-22 09:42:22

pppppass
Member
Registered: 2018-11-29
Posts: 9

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

I have created https://bugzilla.kernel.org/show_bug.cgi?id=202357 and I will update more information there. Surprisingly, "intel_idle.max_cstate=1" avoids the crashes! However, I am using i7-6500U, which is not a Bay Trail chip (if I do not mistake).

Offline

#17 2019-01-22 12:37:39

seth
Member
From: Won't reply 2 private help req
Registered: 2012-09-03
Posts: 78,680

Re: [SOLVED]Freeze managing ethernet, rtl8168evl (old: at the login page)

Skylake, Baytrail is an Atom - they might have the same problematic component, though.
This however means that the problem isn't the ASPM in and by itself, but the fact that it allows the CPU to idle deeper.

Offline

Board footer

Powered by FluxBB