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>
Even CONFIG_HW_STACK_PROTECTION is no here,
it is still yes as it will be re-selected by
CONFIG_TEST_HW_STACK_PROTECTION in tests/Kconfig.
So the correct setting here is:
CONFIG_TEST_HW_STACK_PROTECTION=n
This fixes#8092 (case1)
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The return value from k_fifo_get() might be NULL in some situations,
so protect against that.
Coverity-ID: 186190
Coverity-ID: 186058
Signed-off-by: Leandro Pereira <leandro.pereira@intel.com>
Fail in tests where we have an OOPS or a panic. Right now and in many
cases we continue and test case might be reported as PASS.
Cases that have the tag ignore_faults will ignore those faults (cases
that are testing faults for example).
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Since on ARM CONFIG_NUM_IRQS option has no prompt, it cannot be properly
overridden by a prj.conf fragment. Instead make it have a prompt for
this particular test to be able to override it properly.
Fixes#8200
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
`mmsg` should be fully initialized prior to calling k_mbox_get(). The
mailbox implementation (mainly, mbox_message_match()) will look inside
the second parameter passed to k_mbox_get() in order to determine if
which pending messages should be returned to the caller.
Fixes Valgrind warning listed in #7478.
Signed-off-by: Leandro Pereira <leandro.pereira@intel.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>
True stack sizes may be rounded up, instead of using a multiplier
just fetch the true stack size and add one to it, just one byte
over should produce an error.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Commit 4ef36a4b54 ("tests/kernel/mem_slab: Fix memory overcommit")
caught this error, but missed the fact that there are two slabs that
need to be resized. I also failed to properly explain (or, to be
honestly, fully understand) the deadlock condition, so add a nice big
comment explaining it.
Basically: you have a bunch of threads that can allocate all but one
of their blocks before trying to allocate their last one and pending.
There must be at least one block left so all the threads don't
symmetrically go to sleep waiting on each other.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Call k_thread_foreach only once from _sys_soc_suspend()
otherwise it will flood the console with stack dumps. As per
the test implementation, the one time call happens through
test_call_stacks_analyze_idle test case.
Also removed the the stack size comparision logic from
thread_callback() as the actual size allocated could be
different from what is requested based on the Kconfig option
CONFIG_MPU_REQUIRES_POWER_OF_TWO_ALIGNMENT
Fixes Issue #7858
Signed-off-by: Ramakrishna Pallala <ramakrishna.pallala@intel.com>
This test spawned 4 threads all of which try to allocate 3 blocks from
the same mem_slab before freeing any, leading to a maximum of 12
in-flight allocations. But the slab contained only 3 blocks!
Most of the time it passed, but CI caught it failing on occasion,
possibly more often now due to recent scheduler changes. Fixes#8069
(hopefully).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The idea behind this test is to race two CPUs against each other,
validating that each is truly running simultaneously. But it just
assumed that the other thread/cpu would start synchronously as soon as
k_thread_create() returned.
Normally, that works fine. But while debugging I added some code that
was slowing down entry to the other thread (or maybe the return from
k_thread_create() into the main thread) long enough to allow one
thread to get a significant head start. That breaks the logic in the
test and things were inexplicably "failing".
Put a spin loop around the count so that the main thread can start
counting to within the memory system's ability to inform it of the
change from the other thread.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
* because stack analysis is required, so STACK_CHECK must be
turned off. No HW_STACK_PROTECTION has no impact on current test
* If CONIFG_USERSPACE, the real stack size is bigger than the declared
stack size
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
In arc, privileged stack is merged into defined stack. So
the real stack size should add privileged stack size.
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
The test was using ztest incorrectly exposing everything as one single
test function. We now have multiple tests that can be tracked back to
features and requirements.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
We were referring to old function names and still using the task
terminology which can be confusing.
Signed-off-by: Anas Nashif <anas.nashif@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>
The generation of Stack Corruptions reports is, now, supported
in ARM SOCs with the ARM MPU (CONFIG_ARM_MPU). Therefore, this
commit removes the workaround for ARM architecture in
tests/kernel/fatal/ and keeps it only for SOCs with the NXP MPU
(CONFIG_MXU_MPU).
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Zephyr code routinely assumes conventional ILP32/LP64 integer
behavior, and occasionally relies on it to perform some nice tricks.
This is despite the fact that this behavior (while pervasively adopted
and in use on all architectures we care about supporting) isn't
actually guaranteed by the language standard which allows much looser
semantics than actual exist on hardware.
Put it into the intmath section of this test as a build time thing.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
An errant commit accidentally disabled all testing of
hardware-based stack protection. Restore it, and work
around a problem with how these kinds of exceptions are
reported on ARM until #7706 is fixed.
We need to globally disable user mode due to how the
select statements in Kconfig work, the stack sentinel
is incompatible with user mode.
Some build warnings when compiling as native_posix
fixed.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
A test was trying to add the maximum number of partitions,
but when the domain was initialized there was already one
added which needed to be accounted for to avoid an
assertion failing.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Add description to test cases in tests/kernel/mem_heap,
tests/kernel/mem_slab and tests/kernel/mem_pool
Signed-off-by: Spoorthi K <spoorthi.k@intel.com>
These tests had very small stacks, and the rbtree scheduler on
qemu_x86 (which does need a little extra stack room, though not much)
is bumping up against the limit. Increase by ~128 bytes in most
cases. In the case of the mbox_api test, there are other platforms
(which don't use the tree) which are right against the limit already
and will fail to link with a larger stack, so bump it for qemu_x86
only.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
