There are tests failing due to timeout for a few seconds in simulators,
slightly increase the timeout for these cases.
Signed-off-by: Guo Lixin <lixinx.guo@intel.com>
When threads are in more than one state at a time, k_thread_state_str()
returns a string that lists each of its states delimited by a '+'.
This in turn necessitates a change to the API that includes both a
pointer to the buffer to use for the string and the size of the buffer.
Signed-off-by: Peter Mitsis <peter.mitsis@intel.com>
This commit excludes the kernel monotonic timer test for the
`qemu_arc_hs` platform because this test may fail with the ARC QEMU
6.2 on certain host systems.
Refer to the following issues for more details:
* foss-for-synopsys-dwc-arc-processors/qemu#67
* zephyrproject-rtos/zephyr#44862
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit excludes the kernel syscall test for the `qemu_arc_em`
platform because this test may fail with the ARC QEMU 6.2 on certain
host systems.
Refer to the following issues for more details:
* foss-for-synopsys-dwc-arc-processors/qemu#66
* zephyrproject-rtos/zephyr#44862
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The autoconf.h header is not required because the definitions present in
the file are exposed using the compiler `-imacros` flag.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Some names of the test cases are duplicated within the project.
This commit contains the proposed names of the test scenarios.
Signed-off-by: Katarzyna Giadla <katarzyna.giadla@nordicsemi.no>
There are tests failing sometimes due timeouts in simulators, slightly
increase the default timeout for these cases.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
The residency policy, is in reality, influences by other parameters for
example constraints. It has been renamed to "DEFAULT" policy to make it
more general. The "APP" policy has been renamed to "CUSTOM" to better
represent its purpose.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This test was working by accident onarm64 and riscv64. Those
architectures have large register files, even more so considering
their 64-bit nature.
This test works by calling k_object_alloc(K_OBJ_THREAD) until thread
index exhaustion. However here it exhausted heap memory before running
out of thread indexes. There was a test to make sure that wasn't the
case by attempting a k_malloc(256). But here that succeeded just
because 256 is far smaller than a struct k_thread on the above
architectures.
Fix this by:
- attempting an additional allocation with the actual object size
instead of an arbitrary 256 bites
- increasing the heap size as 8192 was clearly insufficient for the
above platforms.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
When operating on different kinds of heaps sometimes there's a need to
perform special operations on heap, poweroff memory bank when releasing
memory etc. Therefore some additional data may be required.
Metadata is a point to keep such data.
Signed-off-by: Marcin Szkudlinski <marcin.szkudlinski@intel.com>
Simple coverage exerciser for the per-thread timeslice feature. Added
as a(nother) new variant of the schedule_api test.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test uses k_yield() to "sync" between threads, so it's implicitly
supposed to run on a single CPU. Make it explicit, to avoid issues on
platforms with more cores.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
FIXKFLOATDISABLE
The thread context test has insufficient checkings for failing
so add them:
() The variable rv for pass/fail is set but never checked. So
add a check to fail the test if such indicated.
() Each thread's pass variable is set to TC_FAIL (== 1) and
the check for successful thread execution simply checks
if pass variable is not zero, which is always true. So
change it so the check for failing condition is reasonable.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Change the CPU_CORTEX_R kconfig option to CPU_AARCH32_CORTEX_R to
distinguish the armv7 version from the armv8 version of Cortex-R.
Signed-off-by: Bradley Bolen <bbolen@lexmark.com>
Fix priorities for the test threads to allow execution when test thread
yields.
Also cleanup some strings.
Fixes#42723
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Skip kernel_timer_interrupts when CONFIG_TICKLESS_KERNEL
is disabled, because timer won't generate interrupts
anymore after invoking irq_disable and irq_enable
to enable timer interrupt again in TICK mode.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
Add a very simple test of the CONFIG_IRQ_OFFSET_NESTED feature that
exercises nested interrupts in a portable way. It calls irq_offset()
from within a k_timer callback and validates that the return lands
back in the original interrupt successfully.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
No reason to exclude this platform, we only have been using wrong
logging defaults (which was set in the soc) and not printing log
messages which is required by the test.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
ARM does not guarantee the timing effects of NOP
instruction. Hence skip the test_nop test.
Fix for Issue#42666
Signed-off-by: Mahesh Mahadevan <mahesh.mahadevan@nxp.com>
K_OBJ_MSGQ, K_OBJ_PIPE, and K_OBJ_STACK objects have pointers
to additional memory that can be allocated. The k_obj_alloc()
returns these objects as uninitialized so when they are freed
there are random opportunities for freeing invalid memory
and causing random faults.
Signed-off-by: David Leach <david.leach@nxp.com>
The K_OBJ_MSGQ object is unitialized so when the thread cleanup occurs
after an expected fault for invalid access the test case can randomly
fault again because the cleanup of the thread will sometimes attempt
to free invalid buffer_start pointer in the msgq object.
Fixes#42705
Signed-off-by: David Leach <david.leach@nxp.com>
On SMP, and especially using qemu on a busy system, it is possible for
a thread with a later timeout to get ahead of another one with an
earlier timeout. The tight timeout value difference (10ms) makes it
possible albeit difficult to reproduce. The result is something like:
|START - test_timeout_threads_pend_on_lifo
| thread (q order: 2, t/o: 0, lifo 0x4001d350)
|
| Assertion failed at main.c:140:
|test_multiple_threads_pending: (data->timeout_order not equal to ii)
| *** thread 2 woke up, expected 1
Let's make timeout values 10 times larger to make this unlikely race
even less likely.
While at it... The timeout field in struct timeout_order_data is some ms
value and not a number of ticks, so change the type accordingly.
And leverage k_cyc_to_ms_floor32() to simplify computation in
is_timeout_in_range().
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Both alloc_pending tests requires the main thread to utilize
the heap so that child threads must pend on memory allocations.
However, the previous implementation was not SMP friendly where
the child threads could run and succeeded in memory allocation
on other CPUs while the main thread continued to allocate
memory. The main thread would fail to allocate memory if
the child thread (on other CPU) has not freed the memory yet.
Not to mention that, in this scenario, the child thread was not
pending on memory allocation which defeated the purpose of
the test. So to fix this, make sure the main thread allocates
enough memory so future allocations must go into pending.
Also, check that the child thread cannot allocation memory
when first entered so it is actually going into pending.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This test is already running with CONFIG_MP_NUM_CPUS=1. All those
1cpu declarations are needless. And some of them (like the init
tests) have side effects that make it difficult to do things like
"filter for only MP cases".
(Indeed, this is a heavily MP-unsafe test; almost all cases written to
rely on ordering between a parent thread and its child. And that's
doubly so for COHERENE platforms because lots and lots of the test
objects are on stacks. MP_NUM_CPUS=1 is definitely the right thing
here.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There's no reason to wait a whole second here just to know if a tick
should have fired (though, yes, on some older/legacy/non-tickless
configurations, 128 ticks is actually more than a second).
Some simulators are very slow; busy waiting is expensive.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This reverts commit ae8745df6f.
Patch "kernel/init.c: Initialise logging subsystem after arch" should
fix this, so no more need to filter this test out.
Signed-off-by: Ederson de Souza <ederson.desouza@intel.com>
When building with XCC, k_therad_access_grant() expands to
a loop but does nothing if no building for userspace. XCC
does not like this and emits error:
main.s: Assembler messages:
main.s:4563: Error: invalid empty loop
So add #ifdef to only enable the loop if userspace is enabled.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
When building with XCC, the for loop to call k_therad_access_grant()
is an empty loop because k_thread_access_grant() does nothing
if no building for userspace. XCC does not like this and emits
error:
main.s: Assembler messages:
main.s:1951: Error: invalid empty loop
So add #ifdef to only enable the loop if userspace is enabled.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
