This test was written to idle for exactly 1ms and wake up with zero
error, which is just too tight for some platforms (and worked on
emulators where the tick rate is 10x coarser only because 0 == 0!).
And it's not clear that it's testing anything we promise in
documentation, regardless. Early wakeups are not an error and
absolutely not disallowed, yet the test is treating the wakeup like a
sleep.
Clean it up a bit and relax the tolerance to what we can compute
reliably: do all the math in ticks, idle for 10ms (i.e. longer than a
host quantum for emulators), and allow 1 tick of slop on either side to
permit slightly early wakeups while still verifying that "yes, the idle
did idle".
Fixes#46641
Signed-off-by: Andy Ross <andyross@google.com>
Now that picolibc's malloc arena configuration always allocates
some space, we don't need explicit allocations for tests.
Signed-off-by: Keith Packard <keithp@keithp.com>
When running with picolibc, we need more MPU resources for these
tests. Get rid of picolibc malloc arena too.
Signed-off-by: Keith Packard <keithp@keithp.com>
As with previous commit, make the timer irq a simple integer variable
exported by the timer driver for the benefit of this one test
(tests/kernel/context).
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
This test has gotten out of control. It has a giant #if cascade
enumerating every timer driver in the Zephyr tree and extracting its
interrupt number. Which means that every driver needs to somehow
expose that interrupt in its platform headers or some other API.
Make it a simple integer variable exported by the timer driver for the
benefit of this one test.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Picolibc has subtly different output from the minimal libc as a result
of different handling for code built without real long long support.
Signed-off-by: Keith Packard <keithp@keithp.com>
This runs the existing kernel common tests using picolibc as some of those
depend on libc functionality.
Signed-off-by: Keith Packard <keithp@keithp.com>
change the test interrupt line number to a bigger one, because
the low number usually will be used by other devices.
Signed-off-by: Chen Peng1 <peng1.chen@intel.com>
When SMP feature is enabled on board, this test suite will skip.
Enable the test suite by removing the filter.
Note that these testings only run SMP platform on single core
which are handled by setting MP_NUM_CPUS=1 in prj.conf.
Signed-off-by: Yinfang Wang <yinfang.wang@intel.com>
This commit updates all deprecated `K_THREAD_STACK_ARRAY_EXTERN` macro
usages to use the `K_THREAD_STACK_ARRAY_DECLARE` macro instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates all deprecated `K_THREAD_STACK_EXTERN` macro usages
to use the `K_THREAD_STACK_DECLARE` macro instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates all deprecated `K_THREAD_STACK_EXTERN` macro usages
to use the `K_THREAD_STACK_DECLARE` macro instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit updates all deprecated `K_THREAD_STACK_EXTERN` macro usages
to use the `K_THREAD_STACK_DECLARE` macro instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit selectively disables the dangling pointer warning
(`-Wdangling-pointer`) for the compilation of the `alternate_thread`
function because it deliberately makes use of a dangling pointer in
order to test stack randomisation.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
Currently the device MMIO APIs is only able to map single DT-defined
regions and also the _NAMED variant is assuming that each DT-defined
device has only one single region to map.
This is a limitation and a problem when in the DT are defined devices
with multiple regions that need to be mapped.
This patch is trying to overcome this limitation by introducing the
DEVICE_MMIO_NAMED_ROM_INIT_BY_NAME macro that leveraged the 'reg-names'
DT property to map multiple regions defined by a single device.
So for example in the DT we can have a device like:
driver@c4000000 {
reg = <0xc4000000 0x1000>, <0xc4001000 0x1000>;
reg-names = "region0", "region1";
};
and then we can use DEVICE_MMIO_NAMED_ROM_INIT_BY_NAME doing:
struct driver_config config = {
DEVICE_MMIO_NAMED_ROM_INIT_BY_NAME(region0, DT_DRV_INST(0)),
DEVICE_MMIO_NAMED_ROM_INIT_BY_NAME(region1, DT_DRV_INST(0)),
};
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Avoid potentially calling __builtin_clz() twice with non-constant
values. Also add a test for it.
Clang produces false positive vla warnings so disable them. GCC will
spot real vla's already.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Files including <zephyr/kernel.h> do not have to include
<zephyr/zephyr.h>, a shim to <zephyr/kernel.h>.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
This commit relaxes the precision requirements for idle event statistic
test when RISC-V machine timer driver is used. This is needed for some
platforms (e.g. hifive1), for which the cycle count is too low to pass
the checks where a percent deviation of peak cycles count is allowed.
Signed-off-by: Filip Kokosinski <fkokosinski@antmicro.com>
Subtracting with a uint64_t operand yields a uint64_t result, for which
the absolute value is not terribly interesting. Cast the operand to
int64_t.
Use llabs instead of abs as abs takes an int parameter and not an
int64_t. This appears to work even with the minimal C library.
Signed-off-by: Keith Packard <keithp@keithp.com>
Due to qemu_x86_tiny having very small defined SRAM area,
enabling userspace results in not having enough free physical
pages to run the tests. So make the memory a bit larger so
we can actually test memory mapping with userspace.
Fixes#46398
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
As the type of A(n) is integer, and A3 and A5 are close to
each other. Sometimes A3 is equal to A5. So change the ">" to
">="
Signed-off-by: Hu Zhenyu <zhenyu.hu@intel.com>
The tests is currently testing all the memory mapping parameters but
K_MEM_PERM_USER. Add a test case to test that as well.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
ehl_crb supports HPET timer by default. Add test suite to test APIC
timer's TSC deadline mode on ehl_crb.
Signed-off-by: Yinfang Wang <yinfang.wang@intel.com>
When test tests/kernel/sched/schedule_api, it shows "ASSERTION FAIL:
timeslice in ticks much be divisible by two", then break and fail
the test.
Fixes#44887.
On board it8xxx2_evb, it can pass schedule_api test without
the assertion, so I add the floating part back to half_slice_cyc
when the timeslice in ticks can't be divisible by two.
After change, the time slice will be:
1.slice_ticks = (200x8192+999)/1000 = 1639 (not changed)
2.before add the deviation (not handle the floating part):
half_slice_cyc = (1639/2) * (32768/8192) = (819) * (32768/8192) = 3276,
after add the deviation:
half_slice_cyc = 3276 + (32768/8192/2) = 3278,
and it's equal (1639/2) * (32768/8192) = 3278.
Verified by test pattern:
west build -p always -b it8xxx2_evb tests/kernel/sched/schedule_api
Signed-off-by: Ruibin Chang <Ruibin.Chang@ite.com.tw>
Bug #45779 discovered an edge case with nested interrupts on Xtensa
where they might select an incorrect thread context to return to
instead of the (mandatory!) return to the outer interrupt context.
Cleverly adjust the nested_irq_offload to exercise this. It now
creates a thread that it knows it will interrupt, then suspends that
thread from within the inner/nested interrupt. This guarantees that
_current will be different on exit from the second interrupt, which is
the case that tripped up Xtensa.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Test was setting up timer for 1 system tick and then work was
cancelled. It was assumed that work will be cancelled before
timer expires. This is the case for low frequency system clock
(e.g. qemu targets using 100Hz) but there are cases when system
clock has higher frequency (32kHz on nRF). In that case, timer
was occasionally expiring before cancellation and test was
randomly failing.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
This test was written to do a k_oops() in the main thread. That's an
essential thread, and aborting it is actually a system panic now. The
test was written contra the docs on this, but it worked fine for
years.
Just reflag the thread as a simple workaround rather than trying
anything fancy. This is a very simple test.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Documentation specifies that aborting/terminating/exiting essential
threads is a system panic condition, but we didn't actually implement
that and allowed it as for other threads. At least one app wants to
exploit this documented behavior as a "watchdog" kind of condition,
and that seems reasonable. Do what we say we're supposed to do.
This also includes a small fix to a test, which seemed like it was
written to exercise exactly this condition. Except that it failed to
detect whether or not a system fatal error was actually signaled and
was (incorrectly) indicating "success". Check that we actually enter
the handler.
Fixes#45545
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
A separate privileged stack is used when CONFIG_GEN_PRIV_STACKS=y. The
main stack guard area is no longer needed and can be made available to
the application upon transitioning to user mode. And that's actually
required if we want a naturally aligned power-of-two buffer to let the
PMP map a NAPOT entry on it which is the whole point of having this
CONFIG_PMP_POWER_OF_TWO_ALIGNMENT option in the first place.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
The StackGuard area is used to save the esf and run the exception code
resulting from a StackGuard trap. Size it appropriately.
Remove redundancy, clarify documentation, etc.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
Some test suites have different test case lists in test_main(), that
conforms to different test scenarios defined in testcase.yaml. We
use if statement to decide which test case list should run under
specific config.
But for thoses boards who do not support those configs, we will run test
cases on the other side of the if statement even if it has deviated from
the original test scenario.
So add filter to avoid test scenario running under mismatch config.
Signed-off-by: Guo Lixin <lixinx.guo@intel.com>
Mutual exclusion test assume that the excution order of two threads like
this:
mutual_exclusion1 -> mutual_exclusion2 -> mutual_exclusion1 ...
but some times the excution order of two threads would be this:
mutual_exclusion1 -> mutual_exclusion2 -> mutual_exclusion2 ...
This patch increase the loop cycle, add a variable 'tmp' to store the
value of 'critical_var' before operating it.
Signed-off-by: Huifeng Zhang <Huifeng.Zhang@arm.com>
The issue is caused by multiple threads which have taken the semaphore
to increase or decrease the normal count variable. Change its type with
atomic_t.
Signed-off-by: Jaxson Han <jaxson.han@arm.com>
