[Hardware Failure] Cannot set ethernet connection to gigabit speeds

-thc · 2025-04-23 06:55:09

Although initially specified in the IEEE spec GbE half-duplex is unused today.

seth · 2025-04-23 07:06:36

The partner still advertises it and if it's not the cable, it's my last best idea for what's going on here (undebuggable bug in usr/lib/firmware/rtl_nic/rtl8125a-3.fw.zst aside)
*shrug*

TheLastTeapot · 2025-04-24 02:49:23

I can't figure out how to remove the r8125 module and reinstate the other. I tried removing it with pacman and modprobe, but neither recognises it, and unblacklisting r8169 had no effect.

seth · 2025-04-24 05:54:17

https://wiki.archlinux.org/title/Dynami … ve_modules

TheLastTeapot · 2025-04-24 10:54:52

Results of ethtool after running

sudo ethtool -s enp39s0 speed 1000 duplex half autoneg off

Settings for enp39s0:
	Supported ports: [ TP	MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                       100baseT/Half 100baseT/Full
	                       1000baseT/Full
	                       2500baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  Not reported
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: No
	Advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Half
	Auto-negotiation: off
	master-slave cfg: preferred slave
	master-slave status: unknown
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	MDI-X: Unknown
netlink error: Operation not permitted
	Link detected: no

As you can see this is clear progress, because both it got rid of the "Unknown!" speed and duplex, and because it allowed setting autonegotiation off, which produced an error previously. However, it still takes down the connection

 sudo dmesg | grep r8169

[    3.953297] r8169 0000:27:00.0: enabling device (0000 -> 0003)
[    3.959740] r8169 0000:27:00.0 eth0: RTL8125A, 2c:f0:5d:10:00:0b, XID 609, IRQ 81
[    3.959746] r8169 0000:27:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    3.961964] r8169 0000:27:00.0 enp39s0: renamed from eth0
[    5.488254] Realtek Internal NBASE-T PHY r8169-0-2700:00: attached PHY driver (mii_bus:phy_addr=r8169-0-2700:00, irq=MAC)
[    5.642421] r8169 0000:27:00.0 enp39s0: Link is Down
[   18.873105] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[   18.873132] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[   20.124204] r8169 0000:27:00.0 enp39s0: Link is Down
[   33.926411] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[   33.926439] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[   38.098169] r8169 0000:27:00.0 enp39s0: Link is Down
[   51.292863] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[   51.292891] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[   55.900429] r8169 0000:27:00.0 enp39s0: Link is Down
[   69.103901] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[   69.103931] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[   72.454098] r8169 0000:27:00.0 enp39s0: Link is Down
[   85.799262] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[   85.799298] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[   88.475225] r8169 0000:27:00.0 enp39s0: Link is Down
[  101.752225] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[  101.752263] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[  103.598264] r8169 0000:27:00.0 enp39s0: Link is Down
[  116.792940] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[  116.792970] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[  124.125728] r8169 0000:27:00.0 enp39s0: Link is Down
[  137.485434] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[  137.485461] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[  143.536220] r8169 0000:27:00.0 enp39s0: Link is Down
[  157.141934] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[  157.141964] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[  162.485852] r8169 0000:27:00.0 enp39s0: Link is Down
[  175.988951] Realtek Internal NBASE-T PHY r8169-0-2700:00: Downshift occurred from negotiated speed 1Gbps to actual speed 100Mbps, check cabling!
[  175.988983] r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
[  178.141937] r8169 0000:27:00.0 enp39s0: Link is Down
[  179.293229] r8169 0000:27:00.0 enp39s0: Link is Down
[  194.691050] r8169 0000:27:00.0 enp39s0: Link is Down

TheLastTeapot · 2025-04-24 10:56:54

Unfortunately once again I will be away from home today and tomorrow, so any suggestions I will try on saturday

seth · 2025-04-24 13:19:39

seth wrote:

my last best idea for what's going on here (undebuggable bug in usr/lib/firmware/rtl_nic/rtl8125a-3.fw.zst aside)

To be sure: you do have linux-firmware installed, right?
Please post your complete system journal for the boot:

sudo journalctl -b | curl -F 'file=@-' 0x0.st

Maybe it's something really silly like concurrent access, but if we rule out cable and link partner and we've gone through two drivers and it's not ASPM and it's not the duplex connection ending up overspeaking itself - I've a hard time imagining what else might cause this (firmware bugs or fused HW aside…)

TheLastTeapot · 2025-04-26 15:49:53

Yes, I do have linux-firmware installed.

System Journal:
https://0x0.st/8WrJ.txt

seth · 2025-04-26 16:04:12

Apr 26 10:43:42 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:43:55 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:43:57 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:44:11 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:44:13 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:44:27 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:44:32 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:44:45 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:44:47 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:45:01 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:45:03 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:45:16 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:45:22 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:45:35 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:45:39 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:45:52 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:45:56 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:46:10 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:46:15 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:46:28 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:46:29 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down
Apr 26 10:46:43 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
Apr 26 10:46:48 Noah-Tower kernel: r8169 0000:27:00.0 enp39s0: Link is Down

You're not only getting downshifted but even then constantly lose the carrier - sometimes within a second.
I'd tell you to get rid of NM and tailscale, but apparently the problem also exists on grml, so that's pointless.

Try the behavior against a completely different peer and in doubt windows on this system, but unless cable, this looks like a HW issue.

TheLastTeapot · 2025-04-26 16:18:55

Would another computer with a gigabit port work to test against, or would that be too difficult to set up?

Isn't the constant loss of connection due to it attempting to shift back up to gigabit? Because when it's connected to the switch that only advertises 100Mbitps, it never loses the connection

seth · 2025-04-26 17:07:26

Isn't the constant loss of connection due to it attempting to shift back up to gigabit?

I've never seen a live upshift, let alone 1s after necessitating a downshift.

when it's connected to the switch that only advertises 100Mbitps, it never loses the connection

What if you override the connection to the troublesome gigabit router, skip autoneg and connect at 100Mbps - does it run stable there as well?

The easiest way would be to just try a different Gbit router, but yeah, sure - you can directly connect two systems via ethernet using static IPs (and you can typically assume auto MDI-X w/ all gbit devices)

TheLastTeapot · 2025-04-26 17:28:36

Interestingly, when I connect to the router directly and force 100Mbps, it still loses the carrier just as often, which implies a problem with the router. I will test against a different gigabit device as soon as I can get one set up.

TheLastTeapot · 2025-04-26 18:15:37

I tested the connection directly to another gigabit laptop, and it behaved just like the network switch. Once connected to my computer, it would only advertise 100Mbps, but did not lose the carrier. Attempting to shift up had the same results as usual, the connection was lost and only regained when I set it back to 100Mbps. So, motherboard issue?

seth · 2025-04-27 06:24:16

But w/ the original router the link went down even on explicit 100Mbps, didn't?
Did those 100Mbit tests all happen with the same cable?

Try to get access to another 1Gbps router, use the shortest, newest, most highly graded, industrially manufactured cable you have/can get. Test the behavior with that setup.
If you're removing the cable and the link partner as culprits, as well as the OS (in doubt windows) it's gonna be the local hardware, yes.

dimich · 2025-04-28 01:28:05

Once I observed similar issue with integrated ethernet in mini-desktop system (I don't remember what chip it was but not RTL8125). Cable and remote end issues were ruled out as it worked fine at 1Gbps when plugged into external USB ethernet adapter. It turned out that the culprit was noisy power supply unit which generated EMI at tens of MHz.

seth · 2025-04-29 06:55:40

x-refs:
https://bbs.archlinux.org/viewtopic.php?id=305216
https://bbs.archlinux.org/viewtopic.php?id=305241

TheLastTeapot · 2025-04-29 13:24:26

seth wrote:

Try to get access to another 1Gbps router, use the shortest, newest, most highly graded, industrially manufactured cable you have/can get. Test the behavior with that setup.

I'm afraid I don't have another router, though there are some at my church, so maybe I will haul my pc up there to test that. However, I did test it to that other gigabit laptop with a brand new 1ft cat6 patch cable and got the same result, so my hope is minimal.

Here's the interesting thing, since one of those other rtl8125 threads mentioned that it worked on windows. I do have windows installed, (fastboot disabled of course) but a while back when I updated my bios GRUB lost its efi partition (I think?). At any rate, it's not booting. But I will see what I can do to get it working, and then see what happens with it.

dimich wrote:

It turned out that the culprit was noisy power supply unit which generated EMI at tens of MHz.

Interesting. I don't think that's what's going on here, because my power supply is supposed to be gold rated, but regardless I don't have another one to test with and I can't afford to buy a new one, so if that's what it is I'll just have to live with it.

seth · 2025-05-01 06:50:58

https://bbs.archlinux.org/viewtopic.php … 2#p2239472 hinges on eee

TheLastTeapot · 2025-05-03 03:27:40

You mean I should test eee with the r8125 driver?

I tested it with the r8169, and it fixed the constant loss of carrier, but still didn't allow gigabit. I also got my windows 11 bootloader fixed, and made sure fastboot was off. It was listed as on, but I think that must have been a side effect of fixing the bootloader because it was definitely off before. Regardless, windows 11 also was stuck at 100Mbps, and rebooting after getting it fixed didn't make it work. So I am about convinced that this is some sort of motherboard issue. Maybe it's some kind of uefi firmware bug and will get fixed eventually, maybe I just have a bad board. Either way, I'll survive fine on wifi.

Thank you so much for your persistent help seth, I really appreciate it. It's people like you that make the Arch Linux forums and wiki the amazing places they are, and that is a beautiful thing. Thank you.

seth · 2025-05-03 06:23:37

No, testing that on r8169 would be sufficient, notably since the windows test results make it extremely likely that it's the hardware after all

Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
In this case maybe use "[HW DEFECT instead of "[SOLVED]"

Arch Linux

#26 2025-04-23 06:55:09

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#27 2025-04-23 07:06:36

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#28 2025-04-24 02:49:23

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#29 2025-04-24 05:54:17

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#30 2025-04-24 10:54:52

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#31 2025-04-24 10:56:54

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#32 2025-04-24 13:19:39

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#33 2025-04-26 15:49:53

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#34 2025-04-26 16:04:12

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#35 2025-04-26 16:18:55

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#36 2025-04-26 17:07:26

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#37 2025-04-26 17:28:36

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#38 2025-04-26 18:15:37

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#39 2025-04-27 06:24:16

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#40 2025-04-28 01:28:05

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#41 2025-04-29 06:55:40

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#42 2025-04-29 13:24:26

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#43 2025-05-01 06:50:58

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#44 2025-05-03 03:27:40

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

#45 2025-05-03 06:23:37

Re: [Hardware Failure] Cannot set ethernet connection to gigabit speeds

Board footer