So the script does the same than
cat << '_EOF_' > /etc/udev/rules.d/99-dietpi-nanopir5c.rules
SUBSYSTEM=="net", KERNEL=="eth0", KERNELS=="0002:21:00.0", RUN:="/bin/true"
SUBSYSTEM=="net", KERNEL=="eth1", KERNELS=="0001:11:00.0", NAME="to_eth0", RUN:="/bin/true"
SUBSYSTEM=="net", KERNEL=="to_eth0", RUN="/bin/ip l s dev eth0 name eth1", RUN+="/bin/ip l s dev to_eth0 name eth0", RUN+="/bin/udevadm trigger -c add /sys/class/net/eth0 /sys/class/net/eth1"
_EOF_
Yeah that blacklisting explained why the ports kept switching, I will try using the KERNELS=="*3c0400000*" and report back.
So far I have tested the current config/script on:
So far both systems seem to be stable after multiple reboots and the LED rules are not interfering with the setup.
Strangely the LAN LED is lit on both systems and occasionally blinking when no cable is connected in the socket. I have my eth1 set for DHCP and eth0 as static but I wouldnât expect the LED to be on when a cable is disconnected.
$ ip link show | grep eth
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr xx:xx:xx:xx:xx:xx
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff permaddr xx:xx:xx:xx:xx:xx
$ cat /etc/network/interfaces.d/eth1.cnf
# eth1 WAN
auto eth1
iface eth1 inet dhcp
$ cat /etc/network/interfaces.d/eth0.cnf
# eth0 LAN
auto eth0
iface eth0 inet static
hwaddress ether xx:xx:xx:xx:xx:xx
address 192.168.10.1
netmask 255.255.255.0
But it looks like we have a solution to the original problem! I will continue testing this week and report back with my results.
@temp, yes the script will currently generate that file with some safeguards in place to ensure it maps the correct kernels. If the KERNELS=="*3c0400000*" method works then I will update the script accordingly as it should be a safer approach.
Any news here? @firebox
I did some more testing over the past few days. I could not get the kernel agnostic KERNELS=="*3c0400000*" udev rule to work, it just created a long boot wait while trying to bring the devices up.
The bash -c "$(curl -fsSL https://raw.githubusercontent.com/MDBInd/DietPi-Scripts/refs/heads/main/Nanopi_R5C_R5S-Rockchip-fix.sh)" script has been working fine through multiple reboots.
⌠Until today after an update to DietPi v9.20.2 where eth1 is not registered at all.
I ran sudo journalctl -k > ~/boot.log as I did before and grepâd the relevant information and found the following:
$ grep -E "3c0400000|3c0800000|eth0|eth1|xhci|usb|r8169" boot-v9202-removed-time.log
kernel: Kernel command line: root=UUID=ab15c53c-d6f2-42d3-8d05-ac1e972d177b rootfstype=ext4 rootwait console=ttyS2,1500000 console=tty1 consoleblank=0 coherent_pool=2M usb-storage.quirks= video=HDMI-A-1:1280x800@60 ubootpart=19b795d8-bec9-b242-92e5-ca04c8e76d3a
kernel: usbcore: registered new interface driver usbfs
kernel: usbcore: registered new interface driver hub
kernel: usbcore: registered new device driver usb
kernel: usbcore: registered new interface driver usb-storage
kernel: usbcore: registered new interface driver usbhid
kernel: usbhid: USB HID core driver
kernel: xhci-hcd xhci-hcd.7.auto: xHCI Host Controller
kernel: xhci-hcd xhci-hcd.7.auto: new USB bus registered, assigned bus number 1
kernel: xhci-hcd xhci-hcd.7.auto: hcc params 0x0220fe64 hci version 0x110 quirks 0x0000808002000010
kernel: xhci-hcd xhci-hcd.7.auto: irq 78, io mem 0xfcc00000
kernel: xhci-hcd xhci-hcd.7.auto: xHCI Host Controller
kernel: xhci-hcd xhci-hcd.7.auto: new USB bus registered, assigned bus number 2
kernel: xhci-hcd xhci-hcd.7.auto: Host supports USB 3.0 SuperSpeed
kernel: usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.18
kernel: usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb1: Product: xHCI Host Controller
kernel: usb usb1: Manufacturer: Linux 6.18.7-current-rockchip64 xhci-hcd
kernel: usb usb1: SerialNumber: xhci-hcd.7.auto
kernel: usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
kernel: usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.18
kernel: usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb2: Product: xHCI Host Controller
kernel: usb usb2: Manufacturer: Linux 6.18.7-current-rockchip64 xhci-hcd
kernel: usb usb2: SerialNumber: xhci-hcd.7.auto
kernel: xhci-hcd xhci-hcd.8.auto: xHCI Host Controller
kernel: xhci-hcd xhci-hcd.8.auto: new USB bus registered, assigned bus number 3
kernel: xhci-hcd xhci-hcd.8.auto: hcc params 0x0220fe64 hci version 0x110 quirks 0x0000808002000010
kernel: xhci-hcd xhci-hcd.8.auto: irq 79, io mem 0xfd000000
kernel: xhci-hcd xhci-hcd.8.auto: xHCI Host Controller
kernel: xhci-hcd xhci-hcd.8.auto: new USB bus registered, assigned bus number 4
kernel: xhci-hcd xhci-hcd.8.auto: Host supports USB 3.0 SuperSpeed
kernel: usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.18
kernel: usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb3: Product: xHCI Host Controller
kernel: usb usb3: Manufacturer: Linux 6.18.7-current-rockchip64 xhci-hcd
kernel: usb usb3: SerialNumber: xhci-hcd.8.auto
kernel: usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
kernel: usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.18
kernel: usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb4: Product: xHCI Host Controller
kernel: usb usb4: Manufacturer: Linux 6.18.7-current-rockchip64 xhci-hcd
kernel: usb usb4: SerialNumber: xhci-hcd.8.auto
kernel: ehci-platform fd800000.usb: EHCI Host Controller
kernel: ohci-platform fd840000.usb: Generic Platform OHCI controller
kernel: ehci-platform fd800000.usb: new USB bus registered, assigned bus number 5
kernel: ehci-platform fd880000.usb: EHCI Host Controller
kernel: ohci-platform fd840000.usb: new USB bus registered, assigned bus number 6
kernel: ohci-platform fd8c0000.usb: Generic Platform OHCI controller
kernel: ohci-platform fd8c0000.usb: new USB bus registered, assigned bus number 7
kernel: ohci-platform fd840000.usb: irq 82, io mem 0xfd840000
kernel: ohci-platform fd8c0000.usb: irq 83, io mem 0xfd8c0000
kernel: ehci-platform fd800000.usb: irq 80, io mem 0xfd800000
kernel: ehci-platform fd880000.usb: new USB bus registered, assigned bus number 8
kernel: ehci-platform fd880000.usb: irq 81, io mem 0xfd880000
kernel: ehci-platform fd800000.usb: USB 2.0 started, EHCI 1.00
kernel: usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.18
kernel: usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb5: Product: EHCI Host Controller
kernel: usb usb5: Manufacturer: Linux 6.18.7-current-rockchip64 ehci_hcd
kernel: usb usb5: SerialNumber: fd800000.usb
kernel: ehci-platform fd880000.usb: USB 2.0 started, EHCI 1.00
kernel: usb usb8: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.18
kernel: usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb8: Product: EHCI Host Controller
kernel: usb usb8: Manufacturer: Linux 6.18.7-current-rockchip64 ehci_hcd
kernel: usb usb8: SerialNumber: fd880000.usb
kernel: usb usb6: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.18
kernel: usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb6: Product: Generic Platform OHCI controller
kernel: usb usb6: Manufacturer: Linux 6.18.7-current-rockchip64 ohci_hcd
kernel: usb usb6: SerialNumber: fd840000.usb
kernel: usb usb7: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.18
kernel: usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
kernel: usb usb7: Product: Generic Platform OHCI controller
kernel: usb usb7: Manufacturer: Linux 6.18.7-current-rockchip64 ohci_hcd
kernel: usb usb7: SerialNumber: fd8c0000.usb
kernel: rockchip-dw-pcie 3c0800000.pcie: host bridge /pcie@fe280000 ranges:
kernel: rockchip-dw-pcie 3c0800000.pcie: IO 0x00f0100000..0x00f01fffff -> 0x00f0100000
kernel: rockchip-dw-pcie 3c0800000.pcie: MEM 0x00f0200000..0x00f1ffffff -> 0x00f0200000
kernel: rockchip-dw-pcie 3c0800000.pcie: MEM 0x0380000000..0x03bfffffff -> 0x0040000000
kernel: rockchip-dw-pcie 3c0800000.pcie: iATU: unroll T, 8 ob, 8 ib, align 64K, limit 8G
kernel: rockchip-dw-pcie 3c0800000.pcie: PCI host bridge to bus 0002:20
kernel: rockchip-dw-pcie 3c0400000.pcie: host bridge /pcie@fe270000 ranges:
kernel: rockchip-dw-pcie 3c0400000.pcie: IO 0x00f2100000..0x00f21fffff -> 0x00f2100000
kernel: rockchip-dw-pcie 3c0400000.pcie: MEM 0x00f2200000..0x00f3ffffff -> 0x00f2200000
kernel: rockchip-dw-pcie 3c0400000.pcie: MEM 0x0340000000..0x037fffffff -> 0x0040000000
kernel: rockchip-dw-pcie 3c0400000.pcie: iATU: unroll T, 8 ob, 8 ib, align 64K, limit 8G
kernel: rockchip-dw-pcie 3c0400000.pcie: PCI host bridge to bus 0001:10
kernel: r8169 0001:11:00.0: enabling device (0000 -> 0003)
kernel: r8169 0001:11:00.0 eth0: RTL8125B, xx:xx:xx:xx:xx:xx, XID 641, IRQ 116
kernel: r8169 0001:11:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko]
kernel: Realtek Internal NBASE-T PHY r8169-1-1100:00: attached PHY driver (mii_bus:phy_addr=r8169-1-1100:00, irq=MAC)
kernel: r8169 0001:11:00.0 eth0: Link is Down
kernel: Realtek Internal NBASE-T PHY r8169-1-1100:00: attached PHY driver (mii_bus:phy_addr=r8169-1-1100:00, irq=MAC)
kernel: r8169 0001:11:00.0 eth0: Link is Down
kernel: eth0: renamed from vetha2d5ff4
kernel: r8169 0001:11:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
kernel: r8169 0001:11:00.0 eth0: Link is Down
kernel: r8169 0001:11:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
Notably both 0800000 and 0400000 seem to initialise and eth0 was named vetha2d5ff4. With this boot we can see r8169 enables eth0 but r8169 0002:21:00.0: enabling device (0000 -> 0003) is missing from the earlier tests.
kernel: rockchip-dw-pcie 3c0800000.pcie: PCI host bridge to bus 0002:20
kernel: rockchip-dw-pcie 3c0400000.pcie: PCI host bridge to bus 0001:10
kernel: r8169 0001:11:00.0: enabling device (0000 -> 0003)
kernel: eth0: renamed from vetha2d5ff4
What DietPi version are you running @temp? I did a load of reboots on this system which was on
v9.19.2.
I donât think the udev rules are causing this issue now as even when the ports were swapping I always has 2 devices available.
I will carry on testing and report back.