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

For an operating system that aims to support various functional safety certifications, asynchronous rendering of %s is a terrible idea. I think %s capability should be dropped from the logger’s format

You should be using the APIs in include/atomic.h On arches that don't natively support atomic operations, these get implemented in terms of irq_lock() Andrew

You need to call the API from user mode in order to exercise the handler functions. If you call the APIs from supervisor mode, the software interrupt and handler function are bypassed and control goes

Ø Should I submit this to Zephyr (as a PR)? Assuming this works in your testing, we would appreciate a patch. :) Andrew

Actually, I think I'm mistaken, the k_wakeup() calls will ensure that it doesn't sleep for the full amount each iteration. We're probably fine. It only wakes up on its own by default every 1000ms, not

Hi Krzystof, For some reason I did not get your email, Carles had to forward to me. Krch: Intention was to set it to the lowest possible value - K_LOWEST_APPLICATION_THREAD_PRIO. Now I've noticed that

Just to follow up after some further inspection: On further inspection, we don't even need a semaphore. It appears some wheels were re-invented, we can simply delete all the code subsys/logging/log_li