This test was written to assume that the only IPI handled would be the
one generated by the test, but the scheduler also generates an IPI any
time a thread becomes runnable, and there's no way to lock that out in
an SMP system where the other CPU is going to be doing its own thing
(we can't use "1cpu" because that locks interrupts on the other CPU
and obviously this is a test of an interrupt).
Change the logic to detect that "at least one IPI was received", which
is fine for coverage. Really a better place for a test like this
would have been tests/kernel/mp, which is a test of the lower level
APIs and runs the other CPU deterministically (i.e. not under the
control of the Zephyr scheduler).
Also some misc fixes:
* Don't busy wait at the start, that's needless.
* Sleep instead of busywaiting after sending the IPI, spinning isn't
needed here and acts to increase CI load needlessly.
* Declare the cross thread signal variable volatile for correctness
(though this error seems to have been benign in practice).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Add one another test case for testing both arch_curr_cpu() and
arch_sched_ipi() architecture layer interface.
Signed-off-by: Enjia Mai <enjiax.mai@intel.com>
Sleeping for a full second at startup is needless. The currently
enabled subsystems on platforms that run this test don't even have any
other threads running at startup, so we're guaranteed the other core
is in idle before we even reach main(). Just a few ms is plenty.
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>
This test was whiteboxing the _current_cpu pointer to extract the CPU
ID. That's actually racy: the thread can be preempted and migrated to
another CPU between the _current_cpu expression and the read of the ID
field. Do it right.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Promote the private z_arch_* namespace, which specifies
the interface between the core kernel and the
architecture code, to a new top-level namespace named
arch_*.
This allows our documentation generation to create
online documentation for this set of interfaces,
and this set of interfaces is worth treating in a
more formal way anyway.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
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>
Just housekeeping around the casting between void * arguments to
thread functions and integer types.
Signed-off-by: Charles E. Youse <charles.youse@intel.com>
For obvious performance reasons, scheduler state changes (other than
aborting a thread) do not cause synchronous interrupts on the other
CPU. Doing a k_thread_wakeup() means that the current CPU will run it
synchronously if it's high priority, but if you want to see it run on
the other cores you need to wait for them to reach a scheduling point
on their own.
The test was written to assume that k_thread_wakeup() is synchronous,
but that's not right, and it needs to spin a bit. This bug was always
present in the test, but masked by a bug in the way that k_sleep() was
handled on SMP. See #9506.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was a missing 'z_' renaming to
z_is_thread_prevented_from_running which would have caused
sanitycheck to fail but it is not being built at the moment.
Fix this first.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The various tests would all do a "wait for threads to exit" step
before checking the results, but this was implemented with a simple
busy wait that turns out to need careful tuning (because there was
busy waiting in the threads).
Rather than try to synchronize this, white box the issue (it's a low
level SMP test, after all) by spinning on the thread states directly
watching for the kernel to flag them dead. The downside here is that
if the process fails for some reason we'll get a hang and a timeout
reported from sanitycheck and not a synchronous ztest assertion. But
in return, successful tests run much faster and I don't need to worry
about how to tune them for IPI latency on different platforms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This case was predicated on a mistake. The behavior of k_wakeup() has
always been NOT to wake up threads that are "pending" on a wait queue,
only ones blocked on a timeout in k_sleep(). As written, this test
case could never pass.
(Really there's no good reason for that. It seems reasonable to me to
expect wakeup to work symmetrically, and the docs are sort of
ambiguous on the subject. But the code in k_wakeup() is clear:
threads flagged pending get an early exit and the call becomes a
noop.)
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
There was a test-created thread that wasn't including this. It's a
huge stack and doesn't overflow (though I thought briefly that it
was), but it's a rule that we need to have that buffer and I'm trying
to fix these as I find them.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
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>
The idea behind this test is to race two CPUs against each other,
validating that each is truly running simultaneously. But it just
assumed that the other thread/cpu would start synchronously as soon as
k_thread_create() returned.
Normally, that works fine. But while debugging I added some code that
was slowing down entry to the other thread (or maybe the return from
k_thread_create() into the main thread) long enough to allow one
thread to get a significant head start. That breaks the logic in the
test and things were inexplicably "failing".
Put a spin loop around the count so that the main thread can start
counting to within the memory system's ability to inform it of the
change from the other thread.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Simple SMP test to validate the two threads can be simultaneously
scheduled. Arranges things such that both threads are at different
priorities and never yield the CPU, so on a uniprocessor build they
cannot be fairly scheduled. Checks that both are nonetheless making
progress.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
