|Summary:||Realtek network adapter don't work any longer|
|Severity:||blocking||CC:||crinteanu.cristian, hkallweit1, jcook|
|Kernel Version:||5.4.30/5.4.31 not working, 5.4.25 working||Tree:||Mainline|
Description avbox111 2020-04-11 22:11:24 UTC
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller Flags: bus master, fast devsel, latency 0, IRQ 19 I/O ports at e000 [size=256] Memory at f7104000 (64-bit, non-prefetchable) [size=4K] Memory at f7100000 (64-bit, non-prefetchable) [size=16K] Capabilities:  Power Management version 3 Capabilities:  MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities:  Express Endpoint, MSI 01 Capabilities: [b0] MSI-X: Enable+ Count=4 Masked- Capabilities:  Advanced Error Reporting Capabilities:  Virtual Channel Capabilities:  Device Serial Number 01-00-00-00-68-4c-e0-00 Capabilities:  Latency Tolerance Reporting Capabilities:  L1 PM Substates Kernel driver in use: r8169 Kernel modules: r8169 04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07) Subsystem: Hewlett-Packard Company RTL810xE PCI Express Fast Ethernet controller Flags: bus master, fast devsel, latency 0, IRQ 19 I/O ports at 1000 [size=256] Memory at 90500000 (64-bit, non-prefetchable) [size=4K] Memory at 90400000 (64-bit, prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: r8169 Kernel modules: r8169 Upgrading vanilla kernel (no patches) from 5.4.25 to 5.4.30/5.4.31 (both version s tested), the multiple realtek driver (see examples above) does not any longer work. I tried fix from: https://bbs.archlinux.org/viewtopic.php?id=254378 Then the RTL8101/2/6E, but not RTL8111/8168/8411, so I had to go back to 5.4.25, where everything works like a charme.
Comment 1 Heiner Kallweit 2020-04-13 16:06:54 UTC
Please re-test with 5.4.32.
Comment 2 avbox111 2020-04-13 17:16:22 UTC
Both devices are working again, best thanks for the quick bugfixing.
Comment 3 James Cook 2020-04-15 08:49:30 UTC
I am having the some problem, and updating to 5.4.32 didn't fix it. The device works with 5.4.28 but not 5.4.30 or 5.4.32. With 5.4.32, I see the following in my system log: Apr 15 08:15:16 angel kernel: r8169 0000:03:00.0: realtek.ko not loaded, maybe it needs to be added to initramfs? Here is part of the output of lspci -v: 03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 03) Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet Flags: fast devsel, IRQ 18, NUMA node 0 I/O ports at ce00 [size=256] Memory at fdfff000 (64-bit, prefetchable) [size=4K] Memory at fdff8000 (64-bit, prefetchable) [size=16K] Expansion ROM at fd900000 [virtual] [disabled] [size=128K] Capabilities: <access denied> Kernel modules: r8169 When I was debugging with 5.4.30, I tried blacklisting the r8169 module to make sure it was not getting loaded before realtek, but then when I manually ran modprobe r8169 I got the same log message about realtek.ko loaded (even though realtek appeared in lsmod output). I hope this is helpful. Let me know if there's any other information I can provide.
Comment 4 Heiner Kallweit 2020-04-15 08:54:45 UTC
Please provide the PHY ID. For this boot 5.4.28 and search under /sys for phy_id (if you should have multiple network interface make sure you pick the right one).
Comment 5 James Cook 2020-04-15 09:14:58 UTC
I think it's 0xc1071002 james angel ~ $ find /sys | grep phy_id find: ‘/sys/kernel/debug’: Permission denied /sys/devices/pci0000:00/0000:00:0a.0/0000:03:00.0/mdio_bus/r8169-300/r8169-300:00/phy_id find: ‘/sys/fs/bpf’: Permission denied james angel ~ $ cat /sys/devices/pci0000:00/0000:00:0a.0/0000:03:00.0/mdio_bus/r8169-300/r8169-300:00/phy_id 0xc1071002
Comment 6 Heiner Kallweit 2020-04-15 09:34:35 UTC
Thanks for the info. The PHY ID is weird and not a proper Realtek PHY ID. Bug 202275 describes an issue where the PHY also comes up with this strange PHY ID. Maybe the solution the affected user found works for you too: https://bugzilla.kernel.org/show_bug.cgi?id=202275#c7
Comment 7 James Cook 2020-04-15 10:18:33 UTC
Thank you! Based on that comment, I enabled "Onboard LAN Boot ROM" in my BIOS settings, and now the device works with 5.4.32. The problem is fixed for me, but I'm happy to test a patch (with the old BIOS setting) if you think it's worth doing. I don't think I know enough to contribute much besides testing. Details, in case it helps someone: * The PHY ID under /sys is now 0x001cc912 (same the new PHY ID in the linked thread). * rmmod r8169 followed by modprobe r8169 caused the phy id in sysfs to change, just like in Comment 5 in that thread. This was before I enabled the BIOS setting, with 5.4.28 (under 5.4.30 I couldn't rmmod to begin with). * I don't know if it matters, but my motherboard is a Gigabyte GA-MA790XT-UD4P that I bought in 2009. I'm not sure which BIOS version. * I don't have a record of buying the ethernet adapter handy, but it may be from before 2003. I could open up my computer and see what's written on it if anyone wants to dig deeper into this.
Comment 8 Heiner Kallweit 2020-04-15 12:01:45 UTC
There is not really something to patch in the kernel, this seems to be a BIOS bug.
Comment 9 Cristian Crinteanu 2020-05-08 06:42:45 UTC
Created attachment 288995 [details] reverse f13bc68131b0c0d67a77fb43444e109828a983bf https://lkml.org/lkml/2020/3/31/396 which is the commit f13bc68131b0c0d67a77fb43444e109828a983bf applied to > 5.4.29 kernel borks my system too Anyway i use kernel 4.19.121 which have the commit above applied in upstream As a result no eth found after reboot (i have two different eth with 8169 chipset) After reversing the patch above everything worked fine - see attach
Comment 10 Heiner Kallweit 2020-05-08 07:23:05 UTC
(In reply to Cristian Crinteanu from comment #9) > Created attachment 288995 [details] > reverse f13bc68131b0c0d67a77fb43444e109828a983bf > > https://lkml.org/lkml/2020/3/31/396 which is the commit > f13bc68131b0c0d67a77fb43444e109828a983bf applied to > 5.4.29 kernel borks my > system too > Anyway i use kernel 4.19.121 which have the commit above applied in upstream > As a result no eth found after reboot (i have two different eth with 8169 > chipset) > After reversing the patch above everything worked fine - see attach How is this related to the original bug report? You talk about something completely different. You have a RTL8168c and problems with MSI(-X)? A detailed description incl. full dmesg would be helpful (as a new report).
Comment 11 Cristian Crinteanu 2020-05-08 08:10:26 UTC
is IS related - READ initial post Kernel driver in use: r8169 Kernel modules: r8169
Comment 12 Cristian Crinteanu 2020-05-08 08:19:15 UTC
[EDIT 11] don't have any MSI stuff here - just a gigabyte motherboard and a TP-Link PCI-E Card - just looked on it's chip = RTL8168E so again i think this is a BUG and the patch attached worked fine for me..
Comment 13 Heiner Kallweit 2020-05-08 08:33:59 UTC
MSI = Message-signaled interrupt (not the company) The mentioned patch can't make a difference for RTL8168e as it's chip versions RTL_GIGA_MAC_VER_32/33.
Comment 14 Heiner Kallweit 2020-05-08 08:36:32 UTC
And just that it's also about r8169 doesn't mean that the issues are related. Still we don't know what your exact issue is, and we haven't seen any log yet.
Comment 15 Cristian Crinteanu 2020-05-08 09:07:01 UTC
i would say. like post name, Realtek network adapters don't work any longer after kernel upgrade mine case 4.19.113 > 4.19.121 the initial problem i also fixed by doing a patch https://lkml.org/lkml/2020/4/1/827 which are now in upstream Now i have the same problem ( no eth working after kernel upgrade) and fixed by doing the patch attached RTL8168E is what is written on that chip..
Comment 16 Cristian Crinteanu 2020-05-08 09:08:50 UTC
[EDIT 15] initial problem means on kernel 4.9.113