Bug 207203
| Summary: | Realtek network adapter don't work any longer | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | avbox111 (webmaster) |
| Component: | Network | Assignee: | drivers_network (drivers_network) |
| Status: | NEW --- | ||
| Severity: | blocking | CC: | crinteanu.cristian, hkallweit1, jcook |
| Priority: | P1 | ||
| Hardware: | Intel | ||
| OS: | Linux | ||
| Kernel Version: | 5.4.30/5.4.31 not working, 5.4.25 working | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | reverse f13bc68131b0c0d67a77fb43444e109828a983bf | ||
|
Description
avbox111
2020-04-11 22:11:24 UTC
Please re-test with 5.4.32. Both devices are working again, best thanks for the quick bugfixing. 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. 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). 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 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 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. There is not really something to patch in the kernel, this seems to be a BIOS bug. 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 (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). is IS related - READ initial post Kernel driver in use: r8169 Kernel modules: r8169 [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.. 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. 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. 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.. [EDIT 15] initial problem means on kernel 4.9.113 |