When CONFIG_TRACING_OBJECT_TRACKING is enabled, the kernel will keep
lists of some objects (detailed below), so that debuggers or other tools
can keep track of them.
The lists of objects are:
struct k_timer *_track_list_k_timer;
struct k_mem_slab *_track_list_k_mem_slab;
struct k_sem *_track_list_k_sem;
struct k_mutex *_track_list_k_mutex;
struct k_stack *_track_list_k_stack;
struct k_msgq *_track_list_k_msgq;
struct k_mbox *_track_list_k_mbox;
struct k_pipe *_track_list_k_pipe;
struct k_queue *_track_list_k_queue;
Note that while CONFIG_TRACING is needed, one can always use
CONFIG_TRACE_NONE=y. Also, tracking will only be done for objects that
are also being traced (so, to prevent tracking of some type of object,
such as k_timer, just make CONFIG_TRACING_TIMER=n).
Some simple "sanity checking" tests are also added in this patch.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
Exclude hifive1 board from tests/kernel/workq/work/kernel.work,
this board has a issue with this test suite and block all related
CI.
Signed-off-by: Lixin Guo <lixinx.guo@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>
Thread APIs test for k_busy_wait incorrectly asserted that a delay of
100 us should produce a delay in cycles less than or equal to to 100 cycles
of the hardware clock. Since most hardware clocks are fast, this assertion
was valid, but it does not test for the actual delay.
Fix the assertion to verify that a delay of 100 us produces a delay in
cycles less than or equal to 100 us worth of hardware clock cycles.
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
The warning below appears once -Waddress-of-packed-mem is enabled:
/__w/zephyr/zephyr/tests/kernel/mem_protect/userspace/src/main.c: In
function 'test_main':
/__w/zephyr/zephyr/tests/kernel/mem_protect/userspace/src/main.c:1024:17:
error: converting a packed 'k_thread_stack_t' {aka 'struct
z_thread_stack_element'} pointer (alignment 1) to a 'struct
z_x86_thread_stack_header' pointer (alignment 4096) may result in an
unaligned pointer value [-Werror=address-of-packed-member]
1024 | hdr = ((struct z_x86_thread_stack_header *)ztest_thread_stack);
To avoid the warning, use an intermediate void * variable.
More info in #16587.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Failed to build tests/kernel/mem_protect/syscalls on fvp_baser_aemv8r_smp
because the default value of CONFIG_MAX_THREAD_BYTES is too low.
So manually set the value to 5 in test case's prj.conf file.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
Clang 12.0.0 complains about
"cast to smaller integer type 'enum control_method' from 'void *'
[-Werror,-Wvoid-pointer-to-enum-cast]".
Cast it to intptr_t type first.
Signed-off-by: Johann Fischer <johann.fischer@nordicsemi.no>
The PM subsystem is tested in tests/subsys/pm, the removed tests were
not relevant for devices. The test_build_suspend_device_list test has
been renamed to test_device_list since the API is not strictly related
to PM (and does not depend on it).
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
The test is wrongly assuming that all the archs have #address-cells =
<1> and #size-cells = <1> at the DT root. This is not always true, and
it makes the test failing for AArch64. Fix the wrong assumption.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
These two test cases both are fault injection test cases,
and there are designed for testing some negative branches
to improve code coverage. But I find that this branch
shouldn't be tested, because the spinlock will be locked
before a procedure performs here, and then it will trigger
an assert error and the process will be rescheduled to the
handler function, and terminated the current test case,
so spinlock will never be unlocked. And it will impact
the next test case in the same test suite(the next testcase
will be never get spinlock).
Signed-off-by: NingX Zhao <ningx.zhao@intel.com>
Previously cycle64 was under `samples/`. It's been moved to
`tests/` and has been marked with `slow: True` so that it
will not disrupt CI by adding excessive delays.
Fixes#40367
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
Since drivers implement a callback based on action and not the state,
we should be using the API based on the action instead of the one based
on the state.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
This feature is in tree and used by the SOF app, but we don't have a
local test for it. Add one, including a case to track regressions in
a known failure mode (where the second CPU wouldn't get its IDC
interrupts set up correctly if spawned at runtime).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This changes both k_mem_domain_add_partition() and
k_mem_domain_remove_partition() to return errors instead of
asserting when errors are encountered. This gives the application
chance to recover.
The arch_mem_domain_parition_add()/_remove() will be modified
later together with all the other arch_mem_domain_*() changes
since the architecture code for partition addition and removal
functions usually cannot be separately changed.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This changes k_mem_domain_init() to return error values
instead of asserting when errors are encountered.
This gives applications a chance to recover if needed.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For qemu_cortex_a53 on the mem_protect test, the test
test_mem_domain_init_fail() fails due to not having enough
translation tables. However, since ARM64 MMU asserts on such
condition, and k_mem_domain_init() also asserts when fails,
there is no way to distinguish these two assertions at runtime,
thus the test was considered passing. Fix this by allocating
a few more tables so the test will actually fail on
k_mem_domain_init().
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This change updates the atomic tests to validate 32-bits on
32-bit architectures and 64-bits on 64-bit architectures.
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
The test identifier of timer error case in testcase.yaml is
exactly the same as timer api's test identifier.
So I fix this.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
The thread_apis tests of the RUNTIME_STATS feature weren't really
testing the right behavior.
+ It assumed that accounting would only happen at context switch time
and required that the returned values not change for running threads
(even CLEARLY running threads like _current!). But that's not a
documented feature! It's actually sort of a wart that we'd like to
be able to fix (and have fixed, the new backend returns realtime
values so you can track CPU-bound processes on another CPU).
+ It assumed that k_thread_runtime_stats_all_get() would return time
that includes idle time (or conversely it forgot that
k_thread_foreach enumerates over idle threads). This was sort of a
bug in the original (because it means that the result is always the
system uptime multiplied by the number of CPUs)
Broadly, instead of testing the result of a "time" function for
equality (never a good idea) test it via appropriate bounds given the
usage.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The PM callback is no longer referenced as "pm_control" but
"pm_action_cb", so reflect this new naming on the callbacks.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Because there are two testcases be the same name
in directory tests/kernel/sched/, so change one of
them to avoid confusion.
Signed-off-by: Ying ming <mingx.ying@intel.com>
Move all PM device runtime API calls from pm_device* to the
pm_device_runtime* namespace.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Modified test to exit early when multithreading is disabled to
fix linking errors.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Currently a test is failing.
```
twister -i -p qemu_cortex_a9 \
-s tests/kernel/fatal/exception/kernel.common.stack_sentinel
```
Disable those temporarily until a fix is in place.
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
Add consideration of aarch32 Cortex-A CPUs to a test case in which
architecture-specific assembly instructions are used in order to
explicitly trigger an exception. This test case already considers
aarch32 Cortex-R CPUs, the same instruction will be used by
Cortex-A CPUs.
Signed-off-by: Immo Birnbaum <Immo.Birnbaum@Weidmueller.com>
The test identifier of mutex error case in testcase.yaml is
exactly the same as mutex api's test identifier.
So I fix this.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
Add the pm_control fn to the dummy_driver so the full PM API is tested.
This change also bypasses all PM APIs if the device driver doesn't
support PM.
Signed-off-by: Keith Short <keithshort@google.com>
The shared multi-heap memory pool manager uses the multi-heap allocator
to manage a set of reserved memory regions with different capabilities /
attributes (cacheable, non-cacheable, etc...) defined in the DT.
The user can request allocation from the shared pool specifying the
capability / attribute of interest for the memory (cacheable /
non-cacheable memory, etc...)
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
The test is using device and device runtime power management. Just
including them to the test build.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
When CONFIG_KERNEL_COHERENCE=y (e.g on the various intel_adsp
platforms under SMP) it's not legal to share stack memory between
CPUs, because the stack is cached, and the L1 cache is incoherent.
The kernel will automatically detect the mistake when the memory
contains a kernel object (spinlock, IPC object, etc...). But here the
test was just passing async buffers into the msgq layer, and nothing
watches that.
The fix is simple: make them static.
Fixes#35857
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add a simple coverage test for the multi_heap utility, validating all
cases with a simple configuration value that specifies an index in an
array of heaps.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add testing for the PIN_ONLY API variant (which has a separate run
queue per CPU). Predicate on SMP systems only, to keep needless
duplicate testing to a minimum.
Note that one of the cases in this test exercises an "all cpus" option
for the cpu mask, which is illegal when CONFIG_SCHED_CPU_MASK_PIN_ONLY
is set. Skip.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
