This test is triggering some kind of bug that will reliably cause a
full host crash/hang of the x86 host environment on TGL/cAVS 2.5.
It's interfering with CI testing, so filter it out for now while we
figure it out.
Interestingly it doesn't have any trouble on older cavs15. And even
more so, it seems to be some kind of build interaction. If I disable
LOG=y, it passes. But when it fails, it actually fails BEFORE the boot
entry and core 0 initialization code is reached (i.e. LONG before any
logging initialization). Something is wrong with the generated file;
maybe a linker or rimage bug? The signature is reported OK by the
ROM, but that's the last we hear from the device before it blows up.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
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>
These two cases use a k_pipe to transfer data, and do it (as is
customary) by copying into or out of buffers on the stack. But that
doesn't work when KERNEL_COHERENCE=y, because the pipe code has a
possibly-too-sophisticated zero copy implementation, and will do the
copy into the destination thread synchronously with the k_put_put()
call from the other CPU.
Normally the fix is to use a static buffer instead, but in this case
the buffers are shared between multiple simultaneous threads, so can't
be shared.
Just skip the tests, pending some rework to how they communicate.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This is test assumes that shared static/global variables are coherent
between the CPUs. That's true on incoherent platforms only when
CONFIG_KERNEL_COHERENCE=y. Normally that gets turned on along with
SMP, but this is using the lower level mp API directly and didn't have
that.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The irq_lock() API is a legacy API not to be used for synchronization
by new code, and in any case is only being used in cargo-cult fashion
here. These test cases all do synchronous exceptions, there's
literally nothing to synchronize against.
(And in this case they're exposing a legacy wart. On platforms where:
1. SMP=y, which causes irq_lock() to be implemented as a somewhat
complicated global lock
2. No ARCH_EXCEPT() macro is defined, which causes the kernel to
use a fallback that simply aborts the current thread.
...this test will then abort a thread holding the lock, which will
cause it to be orphaned (if it weren't a legacy API, the kernel
should probably attempt to clean it up in k_thread_abort(), but it
is, and it doesn't), so the next attempt to lock it will hang.
And it's even worse, because this test builds with SMP=y and
MP_NUM_CPUS=1, so the hand will happen with interrupts masked on a
system with only one CPU, and everything will lock up solid.)
Fixes#41877
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We don't use TLB at the moment. Jumping to address 0 (USEG)
leads to TLB exception (instruction fetch).
Division by zero leads to TRAP exception.
Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
When CONFIG_KERNEL_COHERENCE=y, the k_event struct objects
cannot be declared on stacks since they are incoherent among
CPUs in the system.
So mark them as static to place them in global data section
and thus are coherence between CPUs.
Signed-off-by: Daniel Leung <daniel.leung@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>
This PR include 2 changes to refine the testcases:
1. Now we using IPI to trigger interrupt in testing instead of INT
instruction, this means we don't need to hardcode the vector
number. That can avoid some problem.
Fixes: #40374
2. Refined the test cases. Tigger interrupt by INT instruction and
IPI cannot be masked by irq_disabled(). Unless it's a external
interrupt, such as a timer. Now remove those incorrect part of
these testcases.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
Because k_thread size in RISCV64 is near 512 bytes, (num_of_thread *
256) bytes heap size is not enough. Enlarge heap size in RISCV64
to the (num_of_thread * 1024) bytes like x86_64 and ARM64.
Signed-off-by: Jim Shu <cwshu09@gmail.com>
Doxygen treats "/**" as documentation even if the comment block
is inside the function. So remove the extra asterisk for those
"TESTPOINT" comments.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
For functions returning nothing, there is no need to document
with @return, as Doxgen complains about "documented empty
return type of ...".
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Return a constant reference to the next state instead of a copy of
struct pm_state_info. When the next state should be active, just return
NULL. Struct copying should be in general avoided, specially in code
paths executed frequently as is this one.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Validate k_work_queue_start() API with null name config, this should
not affect the name of queue's thread.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
Validate unplug a already unplugged queue, this should not
affect the status of queue and return expected value.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
Add test for cancelling unqueued(idle) work items, this should not
affect the work item and return value as expected.
Signed-off-by: Lixin Guo <lixinx.guo@intel.com>
test_kernel_cpu_idle assumes that CPU's next timer wakeup will be
1 millisecond in the future based on kernel timer it sets. Move tick
synchronization delay into test loop so this will always be the case.
Fixes#41347
Signed-off-by: Daniel DeGrasse <daniel.degrasse@nxp.com>
When the case machine timer clock uses the divided system clock,
k_cycle_get_32() can't measure accurately how many cycles elapsed.
For example, use the value as timer clock obtained by dividing
the system clock by 4.
In this case, measuring a duration with k_cycle_get32() has up to 3
(4-1) cycles systematic error.
To run this test, we need to insert an appropriate of nops
with consideration for the errors.
'nop' can not repeat with for loop.
Must insert as separated statement.
But we don't have a convenient function such as
BOOST_PP_REPEAT in C++.
At this time, Implementing a generic test is a bit difficult.
Skipping this test in the case.
Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>
Various obsolote and misnamed platfomrs in test filters theat went
undetected for a while.
Fixes#41222
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
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>
