NanoPi R76S - IRQs for both 2.5GbE Eth are stuck on core #0
Posted: Thu Oct 09, 2025 5:14 pm
Good afternoon.
There is no dedicated thread for the Rockchip RK3576 yet, so I'm posting in this section.
I'm experiencing an issue with the NanoPi R76S:
Both network interfaces' IRQs are handled exclusively by CPU core #0, and I've never observed any other cores being utilized.
Even after enabling the RSS driver (which adds hardware queues and creates three additional interrupts), those new interrupts also remain stuck on core #0.
The problem is that CPU core #0 is a little core (0xd03 (Cortex-A53)).
Attempts to change smp_affinity fail:
The situation is the same on FriendlyWrt and sbwml's OpenWrt fork.
Since Receive Packet Steering (RPS) cannot fully resolve this bottleneck, I have the following question:
Is this a hardware limitation of the device, or can it be fixed via kernel parameters / will it be resolved in a future kernel update?
There is no dedicated thread for the Rockchip RK3576 yet, so I'm posting in this section.
I'm experiencing an issue with the NanoPi R76S:
Code: Select all
cat /proc/interrupts | grep eth
95: 123460 0 0 0 0 0 0 0 PCI-MSI 524288 Edge eth1-0
96: 351005 0 0 0 0 0 0 0 PCI-MSI 151519232 Edge eth0-0
cat /proc/irq/95/smp_affinity_list
0-7
cat /proc/irq/95/smp_affinity
ff
cat /proc/irq/96/smp_affinity_list
0-7
cat /proc/irq/96/smp_affinity
ffBoth network interfaces' IRQs are handled exclusively by CPU core #0, and I've never observed any other cores being utilized.
Even after enabling the RSS driver (which adds hardware queues and creates three additional interrupts), those new interrupts also remain stuck on core #0.
Code: Select all
cat /proc/cpuinfo
processor : 0
model name : ARMv8 Processor rev 4 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
model name : ARMv8 Processor rev 4 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
model name : ARMv8 Processor rev 4 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
model name : ARMv8 Processor rev 4 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 4
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd08
CPU revision : 0
processor : 5
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd08
CPU revision : 0
processor : 6
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd08
CPU revision : 0
processor : 7
model name : ARMv8 Processor rev 0 (v8l)
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x1
CPU part : 0xd08
CPU revision : 0The problem is that CPU core #0 is a little core (0xd03 (Cortex-A53)).
Attempts to change smp_affinity fail:
Code: Select all
ash: write error: Invalid argument
bash: echo: write error: Operation not permittedThe situation is the same on FriendlyWrt and sbwml's OpenWrt fork.
Since Receive Packet Steering (RPS) cannot fully resolve this bottleneck, I have the following question:
Is this a hardware limitation of the device, or can it be fixed via kernel parameters / will it be resolved in a future kernel update?