[BUG?] Possible scheduler bug on Rock 5B RK3588 on 7.2.5

[Chaoyi Chen]

Hello Trevor,

On 9/16/2026 5:14 AM, Trevor Hemsley wrote:
> Hi
> 
> Apologies if this is seen as a repost but I originally sent it to 
> linux-arm-kernel but did not realise the sheer volume of traffic on that 
> list so I think it got lost immediately. I'm hoping this is a more 
> specific venue that might be able to help.
> 
> 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.
> 
> And this is sar from around that time with stress --cpu 8 running:
> 00:00:51        CPU     %user     %nice   %system   %iowait %steal     %idle
> 00:10:43        all     87.41      0.00      0.11      0.00 0.00    12.48
> 00:20:51        all     87.41      0.00      0.11      0.00 0.00    12.48
> 00:30:51        all     87.41      0.00      0.11      0.00 0.00    12.48
> 00:40:43        all     87.41      0.00      0.11      0.00 0.00    12.48
> 00:50:51        all     87.41      0.01      0.11      0.00 0.00    12.47
> 01:00:51        all     87.41      0.00      0.11      0.00 0.00    12.48
> 01:10:43        all     87.41      0.00      0.11      0.00 0.00    12.48
> 
> This looks like a kernel bug to me?
> 
> I'm writing from an email address that is not subscribed to 
> linux-rockchip so if you have any questions or suggestions please cc me 
> direct. I will be reading the archives if not.
> 

Thank you for reporting this problem. 

Would you mind trying to disable `CONFIG_SCHED_CLUSTER` and checking whether
the problem still reproduces?

-- 
Best, 
Chaoyi