Hi, two RTL8168 cards, first is not working because it is "bad" type, second is working. Kernel 5.10.27. With kernel 5.5.4 both worked. lspci -nnd 10ec:8168 -k -v 03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 03) Subsystem: Gigabyte Technology Co., Ltd Onboard Ethernet [1458:e000] 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 fd400000 [virtual] [disabled] [size=128K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 01 Capabilities: [ac] MSI-X: Enable- Count=4 Masked- Capabilities: [cc] Vital Product Data Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Capabilities: [160] Device Serial Number 03-00-00-00-68-4c-e0-00 06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 01) Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller [10ec:8168] Flags: bus master, fast devsel, latency 0, IRQ 17, NUMA node 0 I/O ports at 9e00 [size=256] Memory at fd7ff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at fd700000 [virtual] [disabled] [size=128K] Capabilities: [40] Power Management version 2 Capabilities: [48] Vital Product Data Capabilities: [50] MSI: Enable- Count=1/2 Maskable- 64bit+ Capabilities: [60] Express Endpoint, MSI 00 Capabilities: [84] Vendor Specific Information: Len=4c <?> Capabilities: [100] Advanced Error Reporting Capabilities: [12c] Virtual Channel Capabilities: [148] Device Serial Number fb-1d-00-00-10-ec-81-68 Capabilities: [154] Power Budgeting <?> Kernel driver in use: r8169 dmesg|grep r8169 [ 1.701937] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 1.702519] libphy: r8169: probed [ 1.702543] r8169 0000:03:00.0: no dedicated PHY driver found for PHY ID 0xc2077002, maybe realtek.ko needs to be added to initramfs? [ 1.702807] r8169: probe of 0000:03:00.0 failed with error -49 [ 1.702877] r8169 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control [ 1.703718] libphy: r8169: probed [ 1.704255] r8169 0000:06:00.0 eth0: RTL8168b/8111b, 00:08:54:56:b6:05, XID 380, IRQ 17 [ 1.704300] r8169 0000:06:00.0 eth0: jumbo features [frames: 4074 bytes, tx checksumming: ko] [ 5.831180] r8169 0000:06:00.0 enp6s0: renamed from eth0 [ 8.609451] RTL8211B Gigabit Ethernet r8169-600:00: attached PHY driver [RTL8211B Gigabit Ethernet] (mii_bus:phy_addr=r8169-600:00, irq=IGNORE) [ 8.665266] r8169 0000:06:00.0 enp6s0: Link is Down [ 11.317519] r8169 0000:06:00.0 enp6s0: Link is Up - 1Gbps/Full - flow control off On kernel 5.5.4 only the "bad" card: dmesg|grep r8169 [ 0.198166] percpu: Embedded 53 pages/cpu s176984 r8192 d31912 u262144 [ 0.198172] pcpu-alloc: s176984 r8192 d31912 u262144 alloc=1*2097152 [ 1.817015] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 1.817733] libphy: r8169: probed [ 1.817867] r8169 0000:03:00.0 eth0: RTL8168d/8111d, 1c:6f:65:2d:41:19, XID 283, IRQ 29 [ 1.817909] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 6.814959] r8169 0000:03:00.0 enp3s0: renamed from eth0 [ 10.148181] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE) [ 10.273562] r8169 0000:03:00.0 enp3s0: Link is Down
Hi, we have two GIGABITE MB with this onboard chip. The chip is detected differ on each MB: [ 1.702543] r8169 0000:03:00.0: no dedicated PHY driver found for PHY ID 0xc2077002, maybe realtek.ko needs to be added to initramfs? [ 1.702544] r8169 0000:03:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? In my case following (not fully correct, but working) patch for kernel 5.10.27 helped: --- a/drivers/net/phy/realtek.c 2020-12-13 23:41:30.000000000 +0100 +++ b/drivers/net/phy/realtek.c 2021-06-17 11:51:00.854994117 +0200 @@ -674,6 +674,14 @@ .config_intr = genphy_no_config_intr, .suspend = genphy_suspend, .resume = genphy_resume, + }, { + .phy_id = 0xc0070002, + .phy_id_mask = 0xf0ff0fff, + .name = "Generic RTL PHY", + .get_features = genphy_read_abilities, + .suspend = genphy_suspend, + .resume = genphy_resume, + .set_loopback = genphy_loopback, }, };
Created attachment 297429 [details] Hotfix for this problem. Hmm, preview not work correctly. Patch attached.
What would be the best way to test this locally to add "Tested-by: " if there are no known collisions with that (apparently rogue Gigabyte) phy id? https://kernel.org/doc/html/latest/process/submitting-patches.html #respond-to-review-comments https://kernel.org/doc/html/latest/process/submitting-patches.html#reviewer-s-statement-of-oversight https://fedoraproject.org/wiki/Building_a_custom_kernel#Building_Only_Kernel_Modules_.28Out_Of_Tree_Modules.29
OT, somewhat-distro-specific notes re: custom kernel packages in [*Fedora COPR*] and thereby Grub boot menu entries for testers https://github.com/bengtfredh/pinebook-pro-fedora-installer/issues/5#issuecomment-710067197
(In reply to petr.bahula from comment #1) > Hi, > we have two GIGABITE MB with this onboard chip. > The chip is detected differ on each MB: > > [ 1.702543] r8169 0000:03:00.0: no dedicated PHY driver found for PHY > ID 0xc2077002, maybe realtek.ko needs to be added to initramfs? > [ 1.702544] r8169 0000:03:00.0: no dedicated PHY driver found for PHY > ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? > > In my case following (not fully correct, but working) patch for kernel > 5.10.27 helped: > > --- a/drivers/net/phy/realtek.c 2020-12-13 23:41:30.000000000 +0100 > +++ b/drivers/net/phy/realtek.c 2021-06-17 11:51:00.854994117 +0200 > @@ -674,6 +674,14 @@ > .config_intr = genphy_no_config_intr, > .suspend = genphy_suspend, > .resume = genphy_resume, > + }, { > + .phy_id = 0xc0070002, > + .phy_id_mask = 0xf0ff0fff, > + .name = "Generic RTL PHY", > + .get_features = genphy_read_abilities, > + .suspend = genphy_suspend, > + .resume = genphy_resume, > + .set_loopback = genphy_loopback, > }, > }; This is a hack that won't make it to mainline. Root cause of the issue a BIOS bug on a number of Gigabyte boards (AFAIK mainly from 2009/2010). There's a number of threads covering this issue. Partially upgrading BIOS helped, for some users also enabling network boot ROM in BIOS.
Created attachment 301136 [details] attachment-23118-0.html Thanks. IIRC I tried a BIOS parameter grid, but should've recorded which parameter sets I tested; unfortunate that the onboard NIC regressed to failing. On Thu, Jun 9, 2022, 4:00 AM <bugzilla-daemon@kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=213469 > > Heiner Kallweit (hkallweit1@gmail.com) changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |hkallweit1@gmail.com > > --- Comment #5 from Heiner Kallweit (hkallweit1@gmail.com) --- > (In reply to petr.bahula from comment #1) > > Hi, > > we have two GIGABITE MB with this onboard chip. > > The chip is detected differ on each MB: > > > > [ 1.702543] r8169 0000:03:00.0: no dedicated PHY driver found for > PHY > > ID 0xc2077002, maybe realtek.ko needs to be added to initramfs? > > [ 1.702544] r8169 0000:03:00.0: no dedicated PHY driver found for > PHY > > ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? > > > > In my case following (not fully correct, but working) patch for kernel > > 5.10.27 helped: > > > > --- a/drivers/net/phy/realtek.c 2020-12-13 23:41:30.000000000 +0100 > > +++ b/drivers/net/phy/realtek.c 2021-06-17 11:51:00.854994117 +0200 > > @@ -674,6 +674,14 @@ > > .config_intr = genphy_no_config_intr, > > .suspend = genphy_suspend, > > .resume = genphy_resume, > > + }, { > > + .phy_id = 0xc0070002, > > + .phy_id_mask = 0xf0ff0fff, > > + .name = "Generic RTL PHY", > > + .get_features = genphy_read_abilities, > > + .suspend = genphy_suspend, > > + .resume = genphy_resume, > > + .set_loopback = genphy_loopback, > > }, > > }; > > This is a hack that won't make it to mainline. Root cause of the issue a > BIOS > bug on a number of Gigabyte boards (AFAIK mainly from 2009/2010). > There's a number of threads covering this issue. Partially upgrading BIOS > helped, for some users also enabling network boot ROM in BIOS. > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug.