Increase thread counter before the assert, otherwise in case of fail
the output will give the impression that the same thread ran more than
once.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Adjusting the tick alignment of this test caused it to start breaking
on nRF5 platforms, which use a 32768 Hz clock that doesn't divide
evenly into the millisecond precision used by the test. The "half
slice" math ended up being wrong by a bit.
Convert to ticks first before computing the cycle delay needed.
Fixes#29705
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test is a little subtle: it wants to spawn three threads to run
and be switched out by a timeslice interrupt. And it wants to consume
half a time slice itself before it starts running. And, because
timeslicing runs out of the same tick framework in the timer driver,
it needs to align to the start of a tick before the process starts.
And further: it does its own time math not in ticks but in timer
cycles, so it's quite sensitive to slop.
But it's "synchronize to tick boundary" code was actually
synchronizing to a CYCLE boundary, which is just wrong. And it was
doing this in the wrong order. It was resetting the timeslice first
and then synchronizing to a tick by spinning, which means that the
test was always going to begin as much as a tick late. Do the tick
synchronization (via a sleep) first.
Finally, the manager thread that was spawning the new threads lives at
the same priority as the highest priority child threads, which means
it can potentitially wake up on the semaphores that they are giving in
the middle of the test and consume CPU unexpectedly. Make sure it's
sleeping for the duration.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
I reviewed that test to find a bug root cause, unfortunately,
bug dissapeared, so nothing to fix, but I noticed several
misprints and wrong comment styles. It's something at least.
Signed-off-by: Maksim Masalski <maksim.masalski@intel.com>
Add a test case of preemptive thread scheduling.
The scheduler will select the highest priority and
waiting longest thread to be the current thread.
Signed-off-by: Ying ming <mingx.ying@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>
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>
Mark the old time conversion APIs deprecated, leave compatibility
macros in place, and replace all usage with the new API.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There are two set of code supporting x86_64: x86_64 using x32 ABI,
and x86 long mode, and this consolidates both into one x86_64
architecture and SoC supporting truly 64-bit mode.
() Removes the x86_64:x32 architecture and SoC, and replaces
them with the existing x86 long mode arch and SoC.
() Replace qemu_x86_64 with qemu_x86_long as qemu_x86_64.
() Updates samples and tests to remove reference to
qemu_x86_long.
() Renames CONFIG_X86_LONGMODE to CONFIG_X86_64.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This test case is has a tolerance of 1ms, but systems with a tick slower
than 1000 ticks/sec may spil outside the 1ms tolerance.
Tolerance adapts to system's ticks/sec, e.g. QEMU targets have
100ticks/sec -> tolerance is 10ms.
Signed-off-by: Andrei Gansari <andrei.gansari@nxp.com>
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>
Use the int_literal_to_timeout Coccinelle script to convert literal
integer arguments for kernel API timeout parameters to the standard
timeout value representations.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
This test was testing for an undocumented and somewhat hyperspecific
behavior: when a process reaches a reschedule point and yields to a
higher priority thread, and there is another equal priority thread
active, which thread gets to run when the higher priority thread
finishes its work? The original scheduler (because it leaves the
older thread in place in the list) implements the preemption like an
interrupt and returns to the original thread, despite the fact that
this then resets is time slice quantum unfairly. In SMP mode, where
the current threads cannot live in the active list, the thread gets
added back to the end of the queue and the other thread runs. In
effect, in UP mode "yield" and "reschedule" mean very slightly
different things where in SMP they act the same.
We don't document either behavior, as it happens. Relax the test
constraints by adding a single deliberate k_yield() to unify behavior.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
We were testing the value of a volatile variable inside a zassert,
which static analysis doesn't like. In principle, it might be
volatile because it's an MMIO register or something and the read is a
side effect, and an assertion will be optionally compiled. (Except
here the value is just regular memory marked volatile for
threadsafety, and zassert will never be elided in a test, but the tool
doesn't know that).
Refactor a little so we always read the variable in a way the tool can
detect is consistent.
Fixes#18446
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This commit includes tweaks in several tests, so
that the tests can be passing on ARM QEMU targets,
mps2_an385 and mps2_an521 with Qemu 4.x release.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Add a new test for unlocking nested scheduler lock. Make sure that
k_sched_unlock() isn't unconditionally a preemption point.
Signed-off-by: Yasushi SHOJI <y-shoji@ispace-inc.com>
When ticks are sub-millisecond, the math produces minimum and maximum
values for the slice duration test that are equal. But because of
aliasing across tick boundaries, it's always possible (for any time
period, nothing specific to time slicing here) to measure one tick
more than an intended duration. So make sure there's always at least
a range of 1ms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This test case is so timing sensitive that gathering code
coverage data screws up the results.
Since this is an abnormal execution environment anyway,
just skip the assertions if CONFIG_COVERAGE=y.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
We didn't have any coverage of the system call handlers for
k_wakeup() and k_is_preempt().
Increase RAM requirements due to stack alignment constraints
on MPU platforms when user mode is enabled.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Fix how the tstacks array was declared extern so this
actually compiles on all platforms with user mode enabled.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
Using void pointers as universal arguments is widely used. However, when
compiling a 64-bit target, the compiler doesn't like when an int is
converted to a pointer and vice versa despite the presence of a cast.
This is due to a width mismatch between ints (32 bits) and pointers
(64 bits). The trick is to cast to a widening integer type such as
intptr_t and then cast to
void*.
When appropriate, the INT_TO_POINTER macro is used instead of this
double cast to make things clearer. The converse with POINTER_TO_INT
is also done which also serves as good code annotations.
While at it, remove unneeded casts to specific pointer types from void*
in the vicinity, and move to typed variable upon function entry to make
the code cleaner.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Per guidelines, all statements should have braces around them. We do not
have a CI check for this, so a few went in unnoticed.
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
The time measurement based on k_uptime_delta() might be not accurate
for some values of CONFIG_SYS_CLOCK_TICKS_PER_SEC. This commit
introduces measurement based on k_cycle_get_32(), which is more
precise.
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
Update reserved function names starting with one underscore, replacing
them as follows:
'_k_' with 'z_'
'_K_' with 'Z_'
'_handler_' with 'z_handl_'
'_Cstart' with 'z_cstart'
'_Swap' with 'z_swap'
This renaming is done on both global and those static function names
in kernel/include and include/. Other static function names in kernel/
are renamed by removing the leading underscore. Other function names
not starting with any prefix listed above are renamed starting with
a 'z_' or 'Z_' prefix.
Function names starting with two or three leading underscores are not
automatcally renamed since these names will collide with the variants
with two or three leading underscores.
Various generator scripts have also been updated as well as perf,
linker and usb files. These are
drivers/serial/uart_handlers.c
include/linker/kobject-text.ld
kernel/include/syscall_handler.h
scripts/gen_kobject_list.py
scripts/gen_syscall_header.py
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
Commit 0cc362f873 ("tests/kernel: Simplify timer spinning") was
added to work around a qemu bug with dropped interrupts on x86_64.
But it turns out that the tick alignment that the original
implementation provided (fundamentally, it spins waiting on the timer
driver to report tick changes) was needed for correct operation on
nRF52.
The effectively revert that commit (and refactors all the spinning
into a single utility) and replaces it with a workaround targeted to
qemu on x86_64 only. Fixes#11721
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
The new spinlock validation features combined with spinlockification
have increased stack usage a bit in CONFIG_ASSERT builds, but this is
a good feature we want to keep. This test was bumping into limits, so
increase the size from 512 to 640 bytes.
Unfortunately, this is also a huge test that creates a LOT of those
stacks across different test cases, so that minor bump blows us past
the 64k SRAM limit on a bunch of boards. So unify all those stacks
that are only ever used in one case at a time so the memory can be
shared. Now there's one fixed stack, named "tstack", and one array
"tstacks". Much smaller.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
These tests need to use stack size as a function of
CONFIG_TEST_EXTRA_STACKSIZE. These test will fail when
CONFIG_COVERAGE is enabled.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
There is actually nothing wrong with this test code idiom. But it's
tickling a qemu emulator bug with the hpet driver and x86_64[1]. The
rapidly spinning calls to k_uptime_get_32() need to disable
interrupts, read timer hardware state and enable them. Something goes
wrong in qemu with this process and the timer interrupt gets lost.
The counter blows right past the comparator without delivering its
interrupt, and thus the interrupt won't be delivered until the counter
is next reset in idle after exit from the busy loop, which is
obviously too late to interrupt the timeslicing thread.
Just replace the loops with a single call to k_busy_wait(). The
resulting code ends up being much simpler anyway. An added bonus is
that we can remove the special case handling for native_posix (which
was an entirely unrelated thing, but with a similar symptom).
[1] But oddly not the same emulated hardware running with the same
driver under the same qemu binary when used with a 32 bit kernel.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
In the POSIX architecture, with the inf_clock "SOC", time does
not pass while the CPU is running. Tests that require time to pass
while busy waiting should call k_busy_wait() or in some other way
set the CPU to idle. This test was setting the CPU to idle while
waiting for the next time slice. This is ok if the system tick
(timer) is active and awaking the CPU every system tick period.
But when configured in tickless mode that is not the case, and the
CPU was set to sleep for an indefinite amount of time.
This commit fixes it by using k_busy_wait(a few microseconds) inside
that busy wait loop instead.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
In the POSIX architecture, with the inf_clock "SOC", time does
not pass while the CPU is running. Tests that require time to pass
while busy waiting should call k_busy_wait() or in some other way
set the CPU to idle. This test was setting the CPU to idle while
waiting for the next time slice. This is ok if the system tick
(timer) is active and awaking the CPU every system tick period.
But when configured in tickless mode that is not the case, and the
CPU was set to sleep for an indefinite amount of time.
This commit fixes it by using k_busy_wait(a few microseconds) inside
that busy wait loop instead.
Signed-off-by: Alberto Escolar Piedras <alpi@oticon.com>
The stack size was way too less. Increasing the size to minimum
of 512 for all platforms.
Signed-off-by: Adithya Baglody <adithya.nagaraj.baglody@intel.com>
This commit replaces exact time compassion by a range check, allowing
the tests to pass on platforms which needs rounding in __ticks_to_ms()
and _ms_to_ticks().
Signed-off-by: Piotr Zięcik <piotr.ziecik@nordicsemi.no>
When adding the nRF52810, which has 24KB of RAM, some of the tests don't
compile anymore due to lack of SRAM. Address this by either filtering
the test out or reducing the amount of memory allocation.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Because the address and size alignment of MPUv2,
limite the thread numbers for emsk_em7d_v22.
If not, build will faill because of DCCM overflow
Signed-off-by: Wayne Ren <wei.ren@synopsys.com>
