There are known issues with SMP and Zephyr's scheduler: https://github.com/zephyrproject-rtos/zephyr/issues/28105 Andrew

Hi Katsuhiro, That is actually a pretty good question. The Risc-V arch port is currently in an "orphaned" state, as noted in MAINTAINERS.yaml. The original contributors have not been heard from for so

That PR looks fine. But you definitely will have some work to do to get SMP working on Risc-V, starting with changing the arch to select CONFIG_SWITCH, and then implement arch_start_cpu(), arch_curr_c

Hi Krzysztof, I'm assuming that you're referring to ARM Cortex-A? A patch recently landed to implement switch instead of swap: https://github.com/zephyrproject-rtos/zephyr/pull/27766. There is a GitHu

Hi Keith, Sorry, just saw this. There are some k_mem_partitions defined which can help with this, z_malloc_partition and z_libc_partition. z_malloc_partition is for the malloc() arena, which is global

Hi George, In Zephyr scheduling, after an ISR is done, can a preemptible thread be swapped out, and a higher priority thread, if ready, is allowed to run? Yes this is guaranteed. There should always b

Hi Jett, It should certainly be possible to do this, where you implement driver logic as just code which makes other system calls at a lower-level bus abstraction to interact with the hardware. It wou

#driver

In v2.3 when building with CONFIG_USERSPACE enabled, I see that we do not do a context switch a short time after POR. I've chased this back and found the the cpus[0].nested has incremented to 6, so th

Hi All, I think we need to re-examine the current policy of auto-closing bugs after 60 days of no activity. I understand the intent, we don't want stale bugs lying around, but I think what we have now

Tommy, when reporting issues, either here or in GitHub, can you copy/paste your terminal output instead of posting screen shots? Andrew

Try this instead, this is what I do every day, I never use west as it doesn’t properly support emulators. For x86-64 the host GDB works great: . zephyr-env.sh cd samples/hello_world mkdir out cd out c

This is a bug. I’ll spend some time on this today and get a GH issue opened. Andrew

The qemu_x86_64 target is configured to use two cores and SMP by default. Regards, Andrew

Hi there, Race conditions for SMP are still under investigation. We found one today where the same thread object was being scheduled on two cores. Additional eyes on this (or patches) are greatly valu

See the section on “CPU Mask” for directions on how to constrain threads to run on a particular set of CPUs. https://docs.zephyrproject.org/latest/reference/kernel/smp/smp.html Regards, Andrew

Phil, I sent a PR which adds a test for this: https://github.com/zephyrproject-rtos/zephyr/pull/21920 It passes on all the emulated targets we have (including Cortex-M), but if this is broken for your

Interrupts should be unlocked when handling system calls, and indeed a thread in a system call can sleep or be preempted. Sounds like you have found a bug. And a gap in testing, we ought to have a tes

No it is not currently compatible. -Andrew

There’s an open bug for this: https://github.com/zephyrproject-rtos/zephyr/issues/6157 Andrew

Why must we support high-speed deferred logging of C strings? Really what is this use-case so compelling that we have to leave sharp edges to developers like this? Is there precedent for this in other