These two tests ask for lots of priority levels, more than the 32
maximum allowed by SCHED_MULTIQ (which is by design: if you have
requirements like that DUMB or SCALABLE are better choices due to the
RAM overhead of MULTIQ), so the build will fail on boards that defined
MULTIQ as default.
Don't let the platform choose the scheduler backend, ask for SCALABLE
explicitly.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When adding the nRF52810, which has 24KB of RAM, some of the tests don't
compile anymore due to lack of SRAM. Address this by either filtering
the test out or reducing the amount of memory allocation.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
The test kernel.sched.preempt was hanging in the posix arch,
due to a busy wait loop in wakeup_src_thread() added in
a803af2fa7.
We fix it by halting the cpu to let time pass in the posix
arch.
Reenabling the testcase in this board by reverting
e8a906c29c
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
The native_posix board does model irq_offload properly now
and therefore this test can be executed without problems.
So let's enable it.
Related to commit:
86b5364335
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
Because the address and size alignment of MPUv2,
limite the thread numbers for emsk_em7d_v22.
If not, build will faill because of DCCM overflow
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
Scheduler choice is subtle across yield and k_sleep(), add calls to
those to the state table and validate that we're making the right
decisions.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test exaustively tests preemption points between threads of all
priority classes (cooperative, preemptible, and metairq), done both
from a synchronous reschedule (via k_sem_give() and from interrupt
context (via irq_offload()), and with and without the sched_lock()
held. It then detects the next thread that runs and validates vs. the
documented priority rules.
Note that there is a whitelisted case on ARM, where irq_offload()
seems not to be working like a true interrupt (it always returns to
the interrupted context and doesn't seem to hit the normal exception
return path which can context switch). And native_posix is excluded
because of failures and the fact that it's actually never possible to
truly preempt a thread there (they run to completion inside _Swap()
et. al. and then block themselves). Both of these should be fixable
in the future but don't (seem to) directly relate to this test.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
