Skip to content

Conversation

@SiyuanCheng-CN
Copy link

Add arc XY mem configuration for nsim_em, em_starterkit, emsdp and iotdk.

Signed-off-by: Siyuan Cheng siyuanc@synopsys.com

Add arc XY mem configuration

Signed-off-by: Siyuan Cheng <siyuanc@synopsys.com>
@abrodkin
Copy link
Member

Looks good to me. Please file this PR in the upstream Zephyr sources here https://github.com/zephyrproject-rtos/zephyr

M-Moawad pushed a commit that referenced this pull request Oct 23, 2025
The "_too_small" test variants intentionally configure an isolated buffer
pool with only 2 buffers to validate proper error handling when the pool
is exhausted during notification of 16 msg_subscriber observers. These
tests are likely to fail on SMP systems due to a buffer recycling race
condition:

Expected behavior (uniprocessor):
  Publisher Thread:
    1. Allocate buf1 for bar_msg_sub1 ✓
    2. k_fifo_put(sub1_fifo, buf1)
    3. Allocate buf2 for bar_msg_sub2 ✓
    4. k_fifo_put(sub2_fifo, buf2)
    5. Try allocate buf3 for bar_msg_sub3 → FAIL -ENOMEM

  Subscriber threads process messages after notification completes,
  pool exhausts at subscriber #3 as expected.

SMP race condition:
  CPU 0 (Publisher):         CPU 1 (bar_msg_sub1):  CPU 2 (bar_msg_sub2):
  ------------------         ---------------------  ---------------------
  Alloc buf1 ✓
  k_fifo_put(sub1, buf1)
                             k_fifo_get() → buf1
                             zbus_sub_wait_msg()
                             net_buf_unref()
                             → buf1 FREED!
  Alloc buf2 ✓
  (reuses buf1!)
  k_fifo_put(sub2, buf2)
                                                    k_fifo_get() → buf2
                                                    net_buf_unref()
                                                    → buf2 FREED!
  Alloc buf3 ✓
  (reuses buf1 again!)
  ...continues...
  All 16 allocations succeed!

On SMP systems, subscriber threads on other CPUs may consume and free
buffers quickly enough that they are recycled back to the pool before the
publisher's notification loop can exhaust it. The test's assumption that
notification completes before subscribers run does not hold with parallel
execution.

Since this is a test design limitation (not a zbus bug), filter SMP
configurations from these specific test variants rather than attempt to
artificially slow down subscribers or change thread priorities.

Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants