Hello,

I'm continuing to try and fix bugs of SMP support for RISC-V.
My first target is my patches pass the 'sanitycheck' and 'buildkite'
tests.

I'm facing strange behavior of sanitycheck currently:

- Sometimes success/fault on my RISC-V SMP environment
At first, I think it's bug of my patches, but...
- Also same tests sometimes success/fault on qemu_x86_64

For example this is result of tests/kernel/mem_protect/sys_sem/
(Using SDK-0.11.4)

----------------------------------------
$ cmake -G Ninja -DBOARD=qemu_x86_64 ../tests/kernel/mem_protect/sys_sem/

$ ninja run
[3/4] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: qemu64,+x2apic
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:EC
X.x2apic [bit 21]
qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
SeaBIOS (version rel-1.12.1-0-ga5cab58-dirty-20200625_115407-9426dddc0a1f-zephyr
)
Booting from ROM..*** Booting Zephyr OS build zephyr-v2.4.0-1318-g73e8cadbb398 ***
Running test suite test_sys_sem
===================================================================
START - test_basic_sem_test
PASS - test_basic_sem_test
===================================================================
START - test_simple_sem_from_isr
PASS - test_simple_sem_from_isr
===================================================================
START - test_sem_take_timeout_isr
PASS - test_sem_take_timeout_isr
===================================================================
START - test_sem_give_take_from_isr
PASS - test_sem_give_take_from_isr
===================================================================
START - test_simple_sem_from_task
PASS - test_simple_sem_from_task
===================================================================
START - test_sem_take_no_wait
PASS - test_sem_take_no_wait
===================================================================
START - test_sem_take_no_wait_fails
PASS - test_sem_take_no_wait_fails
===================================================================
START - test_sem_take_timeout_fails
PASS - test_sem_take_timeout_fails
===================================================================
START - test_sem_take_timeout

Assertion failed at ZEPHYR_BASE/tests/kernel/mem_protect/sys_sem/src/main.c:277: test_sem_take_timeout: (ret_value == 0 is false)
sys_sem_take failed when its shouldn't have
FAIL - test_sem_take_timeout
===================================================================
START - test_sem_take_timeout_forever
PASS - test_sem_take_timeout_forever
===================================================================
START - test_sem_take_multiple
PASS - test_sem_take_multiple
===================================================================
START - test_sem_give_limit
PASS - test_sem_give_limit
===================================================================
START - test_sem_multiple_threads_wait
PASS - test_sem_multiple_threads_wait
===================================================================
Test suite test_sys_sem failed.
----------------------------------------

Current test set and results are correct? Or is there any bugs or
limitations of current sanitycheck? I'm not sure. If you have any
ideas or reasons, please tell me.

Best Regards,
Katsuhiro Suzuki

- Sometimes success/fault on my RISC-V SMP environment
At first, I think it's bug of my patches, but...
- Also same tests sometimes success/fault on qemu_x86_64

There are known issues with SMP and Zephyr's scheduler:

https://github.com/zephyrproject-rtos/zephyr/issues/28105

Andrew

Hello Andrew,

Thanks for comments.

On 2020/11/09 16:08, Boie, Andrew P wrote:

- Sometimes success/fault on my RISC-V SMP environment
At first, I think it's bug of my patches, but...
- Also same tests sometimes success/fault on qemu_x86_64

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

I understand you are fixing the problem.

Currently we cannot trust sanitycheck results for SMP.
And in last month, you told me there are no active maintainer
in RISC-V area.

So I wonder how to proceed merging SMP support for RISC-V...

Best Regards,
Katsuhiro Suzuki