This sets CONFIG_MAX_THREAD_BYTES to 3 as the tests need a few
more bits to build for board intel_adsp/ace30_ptl.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
With picolibc being the default C library, we need to explicitly include
testing against the minimal C library for kernel components.
Signed-off-by: Keith Packard <keithp@keithp.com>
Twister now supports using YAML lists for all fields that were written
as space-separated lists. Used twister_to_list.py script. Some artifacts
on string length are due to how ruamel dumps content.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
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>
1.Add a new testcase to verify multiple queues can be defined
2.Add some code comments to describe function performance.
Signed-off-by: Ningx Zhao <ningx.zhao@intel.com>
When CONFIG_POLL was set, it was historically true that the queue
could (if a higher priority thread "stole" an insert) return a
spurious NULL instead of continuing to wait on a timeout.
This deliberately exercises that race.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
... because it is (required).
This makes a difference when building with CMake and forgetting
ZEPHYR_BASE or not registering Zephyr in the CMake package registry.
In this particular case, REQUIRED turns this harmless looking log
statement:
-- Could NOT find Zephyr (missing: Zephyr_DIR)
-- The C compiler identification is GNU 9.3.0
-- The CXX compiler identification is GNU 9.3.0
-- Check for working C compiler: /usr/bin/cc
-- ...
-- ...
-- ...
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at CMakeLists.txt:8 (target_sources):
Cannot specify sources for target "app" which is not built by
this project.
... into this louder, clearer, faster and (last but not least) final
error:
CMake Error at CMakeLists.txt:5 (find_package):
Could not find a package configuration file provided by "Zephyr" with
any of the following names:
ZephyrConfig.cmake
zephyr-config.cmake
Add the installation prefix of "Zephyr" to CMAKE_PREFIX_PATH or set
"Zephyr_DIR" to a directory containing one of the above files. If
"Zephyr" provides a separate development package or SDK, be sure it
has been installed.
-- Configuring incomplete, errors occurred!
Signed-off-by: Marc Herbert <marc.herbert@intel.com>
These five tests (mbox_api, mheap_api_concept, msgq_api, pipe_api and
queue) all had test cases where they needed a mem_pool allocation to
FAIL. And they are all written to assume the behavior of the original
allocator and not the more general k_heap code, which actually
succeeds in a bunch of these cases.
* Even a very small heap saves enough metadata memory for the very
small minimum block size, and this can be re-used as an allocation.
So you can't assume a small heap is full.
* Calculating the number of blocks based on "num_blocks * max size /
minimum size" and allocating them does not fill the heap, because
the conservative metadata reservation leaves some space left over.
So these have all been modified to "fill" a heap by iteratively
allocating until failure.
Also, this fixes a benign overrun bug in mbox. The test code would
insert a "big" message by reading past the end of the small message
buffer. This didn't fail because it happened to be part of an array
of messages and the other ones defined contained the memory read. But
still.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Kernel timeouts have always been a 32 bit integer despite the
existence of generation macros, and existing code has been
inconsistent about using them. Upcoming commits are going to make the
timeout arguments opaque, so fix things up to be rigorously correct.
Changes include:
+ Adding a K_TIMEOUT_EQ() macro for code that needs to compare timeout
values for equality (e.g. with K_FOREVER or K_NO_WAIT).
+ Adding a k_msleep() synonym for k_sleep() which can continue to take
integral arguments as k_sleep() moves away to timeout arguments.
+ Pervasively using the K_MSEC(), K_SECONDS(), et. al. macros to
generate timeout arguments.
+ Removing the usage of K_NO_WAIT as the final argument to
K_THREAD_DEFINE(). This is just a count of milliseconds and we need
to use a zero.
This patch include no logic changes and should not affect generated
code at all.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Using find_package to locate Zephyr.
Old behavior was to use $ENV{ZEPHYR_BASE} for inclusion of boiler plate
code.
Whenever an automatic run of CMake happend by the build system / IDE
then it was required that ZEPHYR_BASE was defined.
Using ZEPHYR_BASE only to locate the Zephyr package allows CMake to
cache the base variable and thus allowing subsequent invocation even
if ZEPHYR_BASE is not set in the environment.
It also removes the risk of strange build results if a user switchs
between different Zephyr based project folders and forgetting to reset
ZEPHYR_BASE before running ninja / make.
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
test_queue_supv_to_user() invokes a child thread which does some
work which must take place before the call to k_queue_cancel_wait()
is called by the parent.
However, with SMP enabled, the child thread will just run on another
CPU and we have a race between when child_thread_get() calls
k_queue_get(q, K_FOREVER) and the parent calls k_queue_cancel_wait().
If the parent thread gets there first, the whole test hangs as
the call to k_queue_get(q, K_FOREVER) sits forever.
The fix is to have test_queue_supv_to_user() be a 1cpu test, which
ensures that only one CPU is used.
It's not clear to me why this wasn't causing CI failures on other
SMP targets, but I am able to reproduce reliably on qemu_x86_64
with my user mode patches applied.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
The requests are somewhat larger on 64-bit since we
are allocating structs with pointer members. Increase
these to a larger multiple of the minimum block size.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Remove leading/trailing blank lines in .c, .h, .py, .rst, .yml, and
.yaml files.
Will avoid failures with the new CI test in
https://github.com/zephyrproject-rtos/ci-tools/pull/112, though it only
checks changed files.
Move the 'target-notes' target in boards/xtensa/odroid_go/doc/index.rst
to get rid of the trailing blank line there. It was probably misplaced.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
Re-run with updated script to convert integer literal delay arguments
to k_thread_create and K_THREAD_DEFINE to use the standard timeout
macros.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Re-run with updated script to convert integer literal delay arguments to
k_sleep to use the standard timeout macros.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Disabling SMP mode for certain tests was a one-release thing, done to
avoid having to triage every test independently (MANY are not
SMP-safe), and with the knowledge that it was probably hiding bugs in
the kernel.
Turn it on pervasively. Tests are treated with a combination of
flagging specific cases as "1cpu" where we have short-running tests
that can be independently run in an otherwise SMP environment, and via
setting CONFIG_MP_NUM_CPUS=1 where that's not possible (which still
runs the full SMP kernel config, but with only one CPU available).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
If maxsize is smaller than _MPOOL_MINBLK, then Z_MPOOL_LVLS() will be 0.
That means the loop in z_sys_mem_pool_base_init() that initializes the
block free list for the nonexistent level 0 will corrupt whatever memory
at the location the zero-sized struct sys_mem_pool_lvl array was
located. And the corruption happens to be done with a perfectly legit
memory pool block address which makes for really nasty bugs to solve.
This is more likely on 64-bit systems due to _MPOOL_MINBLK being twice
the size of 32-bit systems.
Let's prevent that with a build-time assertion on maxsize when defining
a memory pool, and adjust the affected test accordingly.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
These were never getting called anywhere from user mode,
except for k_queue_alloc_append(), but only by virtue of
some workqueue tests.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Update the files which contain no license information with the
'Apache-2.0' SPDX license identifier. Many source files in the tree are
missing licensing information, which makes it harder for compliance
tools to determine the correct license.
By default all files without license information are under the default
license of Zephyr, which is Apache version 2.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Unlike CONFIG_HW_STACK_PROTECTION, which greatly helps
expose stack overflows in test code, activating
userspace without putting threads in user mode is of
very limited value.
Now CONFIG_TEST_USERSPACE is off by default. Any test
which puts threads in user mode will need to set
CONFIG_TEST_USERSPACE.
This should greatly increase sanitycheck build times
as there is non-trivial build time overhead to
enabling this feature. This also allows some tests
which failed the build on RAM-constrained platforms
to compile properly.
tests/drivers/build_all is a special case; it doesn't
put threads in user mode, but we want to ensure all
the syscall handlers compile properly.
Fixes: #15103 (and probably others)
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This lets us quickly filter tests that exercise userspace
when developing it.
Some tests had a whitelist with qemu_cortex_m3; change
this to mps2_an385, which is the QEMU target with an
MPU enabled.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
(Chunk 3 of 3 - this patch was split across pull requests to address
CI build time limitations)
Zephyr has always been a uniprocessor system, and its kernel tests are
rife with assumptions and outright dependence on single-CPU operation
(for example: "low priority threads will never run until this high
priority thread blocks" -- not true if there's another processor to
run it!)
About 1/3 of our tests fail right now on x86_64 when dual processor
operation is made default. Most of those can probably be recovered on
a case-by-case basis with simple changes (and a few of them might
represent real bugs in SMP!), but for now let's make sure the full
test suite passes by turning the second CPU off. There's still plenty
of SMP coverage in the remaining cases.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This was never a long-term solution, more of a gross hack
to get test cases working until we could figure out a good
end-to-end solution for memory domains that generated
appropriate linker sections. Now that we have this with
the app shared memory feature, and have converted all tests
to remove it, delete this feature.
To date all userspace APIs have been tagged as 'experimental'
which sidesteps deprecation policies.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
