Say threadA holds a mutex and threadB tries
to lock it with a timeout, a race would occur
if threadA unlock that mutex after threadB
got unpended by sys_clock and before it gets
scheduled and calls k_spin_lock.
This patch supplies the test that can be used
to reproduce the problem and the fix that was
provided in #48056Fixes#48056
Signed-off-by: Christopher Friedt <cfriedt@fb.com>
In the default configuration of the test, with 10000 timer samples,
the `periodic_data` array is too big to fit in SRAM on many targets.
Use lower counts of samples for those, depending on their SRAM size,
leaving at least 8 kB for other variables, buffers, stacks etc.
Exclude the test for targets with less than 16 kB.
Signed-off-by: Andrzej Głąbek <andrzej.glabek@nordicsemi.no>
The SMP config for RISC-V on QEMU triggers this:
|START - test_sem_queue_mutual_exclusion
|
|Assertion failed at
| WEST_TOPDIR/zephyr/subsys/testsuite/ztest/src/ztest_new.c:155:
| cpu_hold: (dt < 3000 is false)
|1cpu test took too long (4090 ms)
|ERROR: cannot fail in test 'after()', bailing
Looping 10000 times is maybe a bit excessive.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
This reverts the commit 7d8a119213
because GCC is now configured to not emit ldp/stp Qn instructions for
consecutive 32-byte loads and stores, and the nested interrupt handling
failure due to the missing emulation of these instructions no longer
occurs.
For more details, refer to the GitHub issue #49491 and #49806.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Zephyr timer is based on system ticks, there usually exists some time drift
due to round up/down errors between cycles, ticks and time delay, we
need to add those expected time drift into the bound calculation for
running this test.
Add a new config TIMER_TEST_PERIOD_MAX_DRIFT_PERCENT for users to set
expected maximum drift percentage for the timer period.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
Tickless test enables PM which implies use of LPTIM as ticker on STM32
platforms.
Specifically on nucleo_l073rz, this configuration is fragile as only
LSI(37KHz) could be used as LPTIM tick source, whith a huge accuracy
tolerance (20%).
This works on most cases, when a specific tick freq (4000 ticks/sec),
but this tests explicitly requires tick frequency set to 100.
Excludes nucleo_l073rz for this test.
Signed-off-by: Erwan Gouriou <erwan.gouriou@linaro.org>
The test case was originally designed for the coverage of
nop()/arch_nop() function. It is not very meaningful for
testing something but causing lots of false alarms on the
kernel/common test so far. Suggest removing this test case.
Signed-off-by: Enjia Mai <enjia.mai@intel.com>
Make sure msg is initialized before being used, fixes compiler warning:
main.c:735:9: error: 'msg' may be used uninitialized
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
The k_sys_fatal_error_handler() function is declared in zephyr/fatal.h
with a name of "esf" for the second parameter, not "pEsf". For
unknown reasons, this is showing up in CI as a documentation
generation failure pointing at the (correct) header.
Still, no reason not to synchronize.
Signed-off-by: Andy Ross <andyross@google.com>
Obviously the test of the feature won't work if we don't have an IPI.
And there were two threads that spawned threads that enter busy loops,
expecting to be able to abort them from another CPU. That doesn't
work[1] without an IPI. Just skip these cases rather than trying to
kludge up some kind of abort signal.
[1] Rather, it does work, it just takes infinite time for these
particular test cases. Eventually the CPU would be expected to
receive some other interrupt like a timeout, which would work to
abort the running thread. But no such timer was registered.
Signed-off-by: Andy Ross <andyross@google.com>
This commit changes some tests from using zassert_equal to validate
the pointers to using the zassert_is_null and zassert_not_null.
Signed-off-by: Michał Barnaś <mb@semihalf.com>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit disables the RISC-V direct ISR test due to the broken
`vectors` section placement with the IRQ vector table enabled,
introduced by the commit d2f8ec70235208f4a70e371ccb1ed8dfe0f573c5.
For more details, refer to the GitHub issue #49903 tracking this bug.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
SYS_CLOCK_TICKS_PER_SEC of it8xxx2 is 4096 (244us).
Running test_sleep_abs item on it8xxx2 and we get
k_us_to_ticks_ceil32(250) = 2 and late = 2, so it failed.
After we enable the CONFIG_PM, it needs more time to resume
from low power mode, so I modify the logic to <= for passing
the test.
fixes#49605
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
The test will always fail on emulated/simulated environments. Exclude
this one which was failing.
Signed-off-by: Tom Burdick <thomas.burdick@intel.com>
NSEC_PER_MSEC should be defined along with the rest of the
per-sec macros in sys_clock.h. Currently, it's defined
multiply in a few separate locations.
Signed-off-by: Christopher Friedt <cfriedt@fb.com>
Inside test_get_cpu, the current CPU ID is stored in the test
thread's stack. Another thread is spawned with a pointer to
the variable holding this CPU ID, where this thread is supposed
to run on another CPU. On a cache incoherent platform, this
value of this variable may not have been updated on other CPU's
internal cache. Therefore when checking CPU IDs inside the newly
spawned thread, it is not checking the passed in CPU ID, but
actually whatever is on the another CPU's cache. This results in
random failure on the test_get_cpu test. Since for cache
incoherence architectures, CONFIG_KERNEL_COHERENCE is enabled by
default on SMP where shared data is placed in multiprocessor
coherent (generally "uncached") memory. The fix to this is to
simply make this variable as a global variable, as global
variable are consided shared data and will be placed in
multiprocessor coherent memory, and thus the correct value will
be referenced inside the newly spawned thread.
Fixes#49442
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
