Possible scheduler bug on Rock 5B RK3588 on 7.2.5

[Trevor Hemsley]

Hi

I recently acquired an 8GB Radxa Rock 5B (they're comparatively cheap), 
which uses a Rockchip RK3588 chip and have installed armbian on there 
and while stress testing the new machine I noticed something quite odd. 
If I run `openssl speed -multi 8` then watch using top or btop that 
shows individual cores, I see it start off using all 8 cores and then 
just stop using one of them at random. Every few minutes it will flip 
the inactive core to a different one but there is always one idle. It 
seems to prefer the 0-3 slower cores to be idle but I've also seen it 
pick the faster cores 4-7 and stop using those but once it starts it 
seems to never use more than 87.5% cpu as one core is dropped from use.

I do not think this is a thermal problem as the cpu temp reported is < 57C.

I​ have also run `for i in {0..7}; do taskset -c $i openssl speed & 
done` and this starts 8 processes and pins each process to a specific 
core in which case they all run at 100%, all of the time. This seems to 
me to indicate that it is a scheduler problem as I'm manually telling it 
where to run it. That solves the problem but is unrealistic in real ife.

I have tested this on several armbian supplied kernels from 6.12.58 to 
7.2.5 and the results are similar on all of them. After some period of 
time, it will stop using one or more cores even though there are 
dispatchable tasks waiting. I have also substituted `stress --cpu 8` for 
openssl speed -multi 8 and the results are the same so that seems to 
rule out an openssl bug. If I increase the number of tasks the problem 
still occurs, I've used 8 9 10 11 and 12 and after a while - the more 
the requested tasks the longer it takes - it still ends up giving up on 
one core. I have also had reports from 2 other Rock 5B users that can 
reproduce this behaviour, one even told me that his was idling 2 cores 
(using a 7.1 kernel) and the other says it's better after installing 
kernel 7.2.5 although that is not my experience. I've tested 6.12.58, 
6.18.44, 7.1.8 and 7.2.5 with very little change in symptoms.

I also have an old Odroid HC1 which uses a Samsung Exynos 5422 and has a 
similar 8 core big:little processor setup and is running Debian 13 with 
a 6.12.107 kernel and this does not exhibit the problem. Same underlying 
Debian 13 version on this as the Rock 5B. I tested the Rock 5B with the 
6.12.58 armbian kernel as it was the most similar to the working one on 
the HC1 in case it was some form of regression.

There are no diagnostic messages in the output from `dmesg -T`. If it 
were thermal or some hardware problem I would expect to be told about it 
there.

$  uname -a
Linux rock-5b 7.2.5-edge-rockchip64 #1 SMP PREEMPT Fri Sep 11 09:51:26 
UTC 2026 aarch64 GNU/Linux

I caught it idling 2 cores for about 2 minutes:
top - 20:49:22 up  1:36,  3 users,  load average: 8.30, 8.31, 8.28
Tasks: 205 total,   9 running, 196 sleeping,   0 stopped,   0 zombie
%Cpu0  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu1  :  0.0 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.3 si,  
0.0 st
%Cpu2  : 99.7 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  
0.0 st
%Cpu3  : 99.7 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.3 hi,  0.0 si,  
0.0 st
%Cpu4  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu5  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu6  :  0.3 us,  0.0 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st
%Cpu7  :100.0 us,  0.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  
0.0 st

    1599 ?        S      0:00  |   \_ sshd-session: trevor at pts/0
    1600 pts/0    Ss     0:00  |       \_ -bash
   10802 pts/0    S+     0:00  |           \_ stress --cpu 8
   10803 pts/0    R+    42:58  |               \_ stress --cpu 8
   10804 pts/0    R+    43:40  |               \_ stress --cpu 8
   10805 pts/0    R+    42:17  |               \_ stress --cpu 8
   10806 pts/0    R+    43:00  |               \_ stress --cpu 8
   10807 pts/0    R+    53:02  |               \_ stress --cpu 8
   10808 pts/0    R+    55:12  |               \_ stress --cpu 8
   10809 pts/0    R+    55:12  |               \_ stress --cpu 8
   10810 pts/0    R+    47:29  |               \_ stress --cpu 8

Still 8 threads running.

This looks like a kernel bug to me?

I'm writing from an email address that is not subscribed to 
linux-arm-kernel as I looked at the archives and it's a bit too active 
for me so if you have any questions or suggestions please include me direct.

Thanks

Trevor Hemsley