I would first check the link, what is on the other side, etc. Also do a flood ping with large enough packages. Or UDP flood, not sure how to do that. Iperf3 might be easier. I have no clue about Radxa OS, never really used it. Maybe also do test boot with mainline based kernel, 6.19 edge I think. And what U-Boot version is used. I use Tianocore EDK2 UEFI v1.1, that might also have effect.

Hi, i think the rpm setting-step#S of the onboard fan is to low. - how can this be adjusted? SBC: Rock5b

...or maybe an r8169 driver problem under heavy load dmesg -w | grep -i r8169 [ 5.072779] r8169 0004:41:00.0: enabling device (0000 -> 0003) [ 5.115535] r8169 0004:41:00.0 eth0: RTL8125B, 00:e0:4c:03:00:fc, XID 641, IRQ 166 [ 5.115550] r8169 0004:41:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko] [ 6.328634] RTL8226B_RTL8221B 2.5Gbps PHY r8169-4-4100:00: attached PHY driver (mii_bus:phy_addr=r8169-4-4100:00, irq=MAC) [ 6.518776] r8169 0004:41:00.0 eth0: Link is Down [ 9.721015] r8169 0004:41:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control off [ 9717.405068] r8169 0004:41:00.0 eth0: NETDEV WATCHDOG: CPU: 3: transmit queue 0 timed out 5227 ms [ 9717.405345] r8169 0004:41:00.0 eth0: ASPM disabled on Tx timeout [ 9717.418437] r8169 0004:41:00.0 eth0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100). [ 9941.759110] r8169 0004:41:00.0 eth0: Link is Down [ 9945.329364] r8169 0004:41:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control off I have a frigate container running on this sbc. A second Rock 5b (same os version) with 10 docker images but very low traffic run smoth on the same switch with 2.5Gbps. Could someone check which driver Radxa OS uses?

Hello everyone, I'm still having trouble flashing the h96 max m9 to armbian os, I still haven't succeeded in using the maskrom, but the uart connection has worked, is it possible to flash only the uart connection? Please help me with the steps for flashing the H96 M9.

already in the first dmesg part I see: [54475.779558] r8169 0004:41:00.0 eth0: Link is Down [54479.115749] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [54479.115748] r8169 0004:41:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control off [55390.928391] br-ce724241dce3: port 1(veth1664549) entered disabled state [55390.928949] veth6932af4: renamed from eth0 [55391.020157] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.021811] device veth1664549 left promiscuous mode [55391.021831] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.493933] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.493954] br-ce724241dce3: port 1(veth1a65439) entered disabled state [55391.494085] device veth1a65439 entered promiscuous mode [55391.500502] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.500519] br-ce724241dce3: port 1(veth1a65439) entered forwarding state [55391.539757] eth0: renamed from vethb9b9ca0 [55391.561925] IPv6: ADDRCONF(NETDEV_CHANGE): veth1a65439: link becomes ready Which means to me that you use containers/docker or so and something on that networking level goes wrong. I think it had nothing specifically to do with Armbian nor ROCK5B. You should figure out what is running on your computer and what is done to networking in general. I do not use containers like seems to be done here, so cannot really help here. I have no clue about your networking setup and plans. I use various bridges and VLANs on my ROCK5B (Armbian Trixie), but all strict manually done by myself, only own files in /etc/NetworkManager/system-connections/