Add a bunch of missing "zephyr/" prefixes to #include statements in
various test and test framework files.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
In order to bring consistency in-tree, migrate all tests to the new
prefix <zephyr/...>. Note that the conversion has been scripted, refer
to #45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The test_queue_multithread_competition case wants to be sure that an
inserted item is recevied by the highest priority thread of several
waiting, but that only works if the threads aren't racing against each
other on different CPUs.
Also, the test_queue_loop case would produce a LOT of console output
very quickly. On a few occasions, I saw this overflow the 8k output
buffer of the intel_adsp devices at exactly the wrong time (with
respect to the polling loop in the host python script), cause a flush
of the stream, and then miss the SUCCESSFUL message. Quiet things
down a bit, there's not a lot of value of verbosity in a CI test.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When CONFIG_KERNEL_COHERENCE=y, it's not legal to place shared data
(like the queue elements in this test case) on the stack, because that
memory is incoherent with respect to other CPUs in the system.
Make them static (another option would have been to mark the test case
1cpu).
Fixes#41860
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
In test_queue_append_list_error function, try to append an unnormal
list to check if the data is successful to append, and improve the
coverage for queue.c
Signed-off-by: NingX Zhao <ningx.zhao@intel.com>
Move to CMake 3.20.0.
At the Toolchain WG it was decided to move to CMake 3.20.0.
The main reason for increasing CMake version is better toolchain
support.
Better toolchain support is added in the following CMake versions:
- armclang, CMake 3.15
- Intel oneAPI, CMake 3.20
- IAR, CMake 3.15 and 3.20
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
Test point:
1. Any number of threads may wait on an empty FIFO simultaneously.
2. When a data item is added, it is given to the highest priority
thread that has waited longest.
Signed-off-by: Ningx Zhao <ningx.zhao@intel.com>
Replace *_thread_resource_pool_assign() in the reference with the new
k_thread_heap_assign() since both k_thread_resource_pool_assign() and
z_thread_resource_pool_assign() has been removed prio to v2.5 (by the
commit c770cab1a3 and 3c2c1d85b0 respectively) along with the
k_mem_pool API removal.
For the resource pool inheritance test, the variables with "res_pool"
string has been replaced by "heap_mem" to align with the documentation
fix. No functionality has been changed.
Signed-off-by: Yasushi SHOJI <yashi@spacecubics.com>
These tests would pass pointers to data on their own stacks to other
threads, which is forbidden when CONFIG_KERNEL_COHERENCE (because
stack memory isn't cache-coherent). Make the variables static.
Also, queue had two sleeps of 2 ticks (having been written in an era
where that meant "20-30ms"), and on a device with a 50 kHz tick rate
that's not very much time at all. It would sometimes fail spuriously
because the spawned threads didn't consume the queue entries in time.
How about 10ms of real time instead?
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A fairly common idiom in our test code is to put test-local data
structures onto the stack, even when they are to be used from another
thread. But stacks are incoherent memory on some platforms, which
means that such things may not get a consistent view of memory between
threads.
Just make these things static. A few of these spots were causing test
failures on intel_adsp_cavs15. More were found by inspection while
hunting for mistakes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add some testcases to test some failure scenario
to enhance the coverage of queue's source code.
And add the fatal error function to handler the
fatal error by ourself.
Signed-off-by: Ningx Zhao <ningx.zhao@intel.com>
Use the core k_heap API pervasively within our tree instead of the
z_mem_pool wrapper that provided compatibility with the older mempool
implementation.
Almost all of this is straightforward swapping of one alloc/free call
for another. In a few cases where code was holding onto an old-style
"mem_block" a local compatibility struct with a single field has been
swapped in to keep the invasiveness of the changes down.
Note that not all the relevant changes in this patch have in-tree test
coverage, though I validated that it all builds.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The kernel resource pool is now a k_heap. There is a compatibility
API still, but this is a core test that should be exercising the core
API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The k_mem_pool allocator is no more, and the z_mem_pool compatibility
API is going away. The internal allocator should be a k_heap always.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Mark all k_mem_pool APIs deprecated for future code. Remaining
internal usage now uses equivalent "z_mem_pool" symbols instead.
Fixes#24358
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When defining system calls, it is very important to ensure that
access to the API’s private data is done exclusively through system
call interfaces. Private kernel data should never be made available
to user mode threads directly. For example, the k_queue APIs were
intentionally not made available as they store bookkeeping
information about the queue directly in the queue buffers which are
visible from user mode.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
These test variants were there to test an older backend to the kernel
queue utility that used k_poll() as the blocking mechanism. That code
got removed a while back, so these tests were just dupicates of the
main cases now. Remove.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The k_poll implementation places a struct _poller on the stack and
shares it with other threads, which is incompatible with the
KERNEL_COHERENCE model of cached stacks.
Make this a hard build failure instead of a kconfig dependency for
clarity. The failures if a user actually enables both are subtle and
difficult to debug.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
