I found the reason this happens. Its not the eMMC itself, the boot from eMMC or booting from FAT vs EXT4. It's the much faster system boot speed from eMMC and the network configuration that leads to this bug.
The device that consumes the additional idle power is the Realtek RTL8125 2.5GbE NIC when left in an bugged unmanaged/unconfigured/off state.
When using stock Armbian with Network-Manager it seems to depend on the image, software distribution and the system boot speed with how often the Realtek NIC gets into this bugged state. Properly configuring the NIC in Network-Manager prevents this from happening.
When using Armbian Bullseye with OpenMediaVault installed with the OMVExtras InstallScript this can be reproduced 100%. The InstallScript (without using the option -n to skip network configuration) removes Network-Manager and lets systemd-networkd and OpenMediaVault/Netplan manage the network.
Since the MAC of the Realtek RTL8125 2.5GbE NIC is not fixed and changes every boot systemd-networkd with the policy "MACAddressPolicy=persistent" (default in /usr/lib/systemd/network/99-default.link) automatically adds a persistent MAC address to the Adapter. At the same time OpenMediaVault creates netplan files that assign network configuration based on this added MAC address.
This leads to a race condition in systemd-networkd. If systemd-networkd adds the persistent MAC to the adapter before it tries to assign the configuration matched to this persistent MAC everything works as expected. When the system boots faster systemd-networkd tries to match the configuration to a MAC that is not added yet to the adapter and that leaves the adapter off, unmanaged and bugged.
(In these code parts eth0 = GMAC & Realtek RTL8211F 1GbE and Realtek RTL8125 2.5GbE NIC = enP3p49s0)
Random MAC adresses:
Aug 28 09:53:57 nanopi-r6s kernel: r8125 0003:31:00.0 (unnamed net_device) (uninitialized): Invalid ether addr 00:00:00:00:00:00
Aug 28 09:53:57 nanopi-r6s kernel: r8125 0003:31:00.0 (unnamed net_device) (uninitialized): Random ether addr 4e:54:94:b5:ad:c7
OMV Netplan file (matching with mac!):
root@nanopi-r6s:~# cat /etc/netplan/20-openmediavault-enP3p49s0.yaml
network:
ethernets:
enP3p49s0:
match:
macaddress: de:d1:aa:55:c9:bf
accept-ra: true
dhcp4: yes
dhcp4-overrides:
use-dns: true
use-domains: true
dhcp6: yes
dhcp6-overrides:
use-dns: true
use-domains: true
Netplan auto generated systemd-networkd .network:
root@nanopi-r6s:~# cat /run/systemd/network/10-netplan-enP3p49s0.network
[Match]
MACAddress=de:d1:aa:55:c9:bf
[Network]
DHCP=yes
LinkLocalAddressing=ipv6
IPv6AcceptRA=yes
[DHCP]
RouteMetric=100
UseMTU=true
UseDomains=true
When booting from slow microSD status of enP3p49s0 is ok:
root@nanopi-r6s:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 enP3p49s0 ether no-carrier configuring
3 links listed.
root@nanopi-r6s:~# networkctl status enP3p49s0
● 3: enP3p49s0
Link File: /usr/lib/systemd/network/99-default.link
Network File: /run/systemd/network/10-netplan-enP3p49s0.network
Type: ether
State: no-carrier (configuring)
Path: platform-fe180000.pcie-pci-0003:31:00.0
Driver: r8125
Vendor: Realtek Semiconductor Co., Ltd.
Model: RTL8125 2.5GbE Controller
HW Address: de:d1:aa:55:c9:bf
HW Permanent Address: 4e:54:94:b5:ad:c7
MTU: 1500 (min: 68, max: 9194)
QDisc: mq
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 4/4
Auto negotiation: yes
Speed: n/a
Port: tp
DHCP6 Client DUID: DUID-EN/Vendor:0000ab1166a0671791d79f890000
When booting from much faster eMMC enP3p49s0 is left in a bugged state:
root@nanopi-r6s:~# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 eth0 ether routable configured
3 enP3p49s0 ether off unmanaged
3 links listed.
root@nanopi-r6s:~# networkctl status enP3p49s0
● 3: enP3p49s0
Link File: /usr/lib/systemd/network/99-default.link
Network File: n/a
Type: ether
State: off (unmanaged)
Path: platform-fe180000.pcie-pci-0003:31:00.0
Driver: r8125
Vendor: Realtek Semiconductor Co., Ltd.
Model: RTL8125 2.5GbE Controller
HW Address: de:d1:aa:55:c9:bf
HW Permanent Address: 92:f6:18:f3:59:af
MTU: 1500 (min: 68, max: 9194)
QDisc: noop
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 4/4
Auto negotiation: yes
Speed: n/a
Port: tp
The fix is to install OpenMediaVault without re configuring the network with InstallScript option -n. That keeps Network-Manger and doesn't add the ethernet adapters to the OMV database.
Another option is to remove Network-Manager and also remove the matching by MAC address from OMV netplan files by editing "/srv/salt/omv/deploy/systemd-networkd/netplan/files/ethernet.j2" and deleting:
match:
macaddress: {{ mac_address }}
After saving and applying the new network configuration in OMV webgui the MAC address matching is gone and adapters get only matched by name.
Ok i found the cause of the first bug. It was the USB3 in OTG-Mode!
I took a kernel image where the bug is present (linux-image-legacy-rockchip-rk3588/now 23.05.1--5.10.160-S03c9-Db165-P0000-C5e28Hfe66-HK01ba-Vc222-B9c18 arm64) and added an user overlay:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target = <&usbdrd_dwc3_0>;
__overlay__ {
dr_mode = "host";
};
};
};
That fixed the increased idle power consumption.
The kernel images on the nightly branch beta.armbian.com (linux-image-legacy-rk35xx_23.8.0-trunk*) all have the fix and work fine.
I'll mark this post as the solution and make a new thread for the 2nd bug.
