why can’t e thread be added to the run queue?


Justin Huang
 

Sure I will submit a ticket in GH and assign it to you.
Yes I am trying to bring up an SMP system while the IPI support is not yet in place, which will be enabled soon.
At the moment I am limited to use 2.7.0, which I agree is not ideal for bring up RISCV SMP. I hope we can move to a more decent release soon.

Cheers,
Justin
On Sep 9, 2022, 9:05 AM -0600, Andy Ross <andy@...>, wrote:

On 9/8/2022 7:29 PM, Justin Huang wrote:
> I think I am able to reproduce what I see with mainstream Zephyr, and below is what I do:
>
>     checkout HEAD of main (I was using dddb5dd6b0de9a8b8621b9ac695fd3fd980a33d6)
>     disable SCHED_IPI_SUPPORTED in the build (I just hacked arch/Kconfig and commented out “select SCHED_IPI_SUPPORTED if SMP”)
>     Run "west build -b qemu_riscv64_smp tests/kernel/smp && west build -t run"
>     Should see the ASSERT.
>
> It appears that the path of SMP test on RISCV without IPI support has not yet been tested, or maybe this configuration is invalid?
 
Ah, OK.  Indeed, that's a somewhat obscure feature, and it's not used in-tree currently I don't think (esp32 was for a long while, but they've moved off of SMP in the default configuration IIRC?).  The intent of that busy loop was to allow for bringup of SMP configurations before a working interprocessor interrupt was available.  Very few real/production systems can tolerate a spin loop in the idle thread.
 
But it looks like it's bitrotten and the default k_yield() path now doesn't work in idle?[1].  Can you submit a bug and assign it to me (@andyross on github)?
 
Also: I'm a little worried about your development setup.  To repeat: the circumstance where you'd want this feature corresponds to bringup of a new SMP platform where IPIs aren't ready.  If that's what you're doing, it would likely be better or everyone if you were working against the main branch and not a year-stale release.
 
Andy
 
[1] I'm going to place my bet that it was at or soon after this commit, which removed the last in-tree usage of k_yield() within the idle thread about a year ago: https://github.com/zephyrproject-rtos/zephyr/commit/851d14afc8941313a6f3faeb74f84ed73a33429a