Enable the null-pointer dereferencing detection by default
throughout the test-suite. Explicitly disable this for the
gen_isr_table test which needs to perform vector table reads.
Disable null-pointer exception detection on qemu_cortex_m3
board, as DWT it is not emulated by QEMU on this platform.
Additionally, disable null-pointer exception detection on
mps2_an521 (QEMU target), as DWT is not present and the MPU
based solution won't work, since the target does not have
the area 0x0 - 0x400 mapped, but the QEMU still permits
read access.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Add some testcases to tesing different condition of mailbox
API. Check API robust in different input parameters is handled.
such as invoke API to get data with NULL input.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
Add some testcases to test some unnormal branches,
for covering branches that not covered.Meanwhile,
Using the public fatal handler function to handle
fatal errors.
Signed-off-by: Ningx Zhao <ningx.zhao@intel.com>
Enable CONFIG_TEST in the message_capture test suite.
This allows certain Kconfig configurations, depending
on TEST, to be enabled.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Allow the test to run for non-secure firmware builds, by
removing the test-case for nonsense string, as this test-case
will likely produce a secure fault which will crash the kernel.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
tests/kernel/interrupt tests interrupt trigger functionality,
however, the Non-Secure Cortex-M mode does not have full control
of the interrupt handling, so this test cannot be guaranteed to
pass when executing in Non-Secure mode. Filter the test out for
Non-Secure Cortex-M builds.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
Exclude the test_null_dynamic_name test-suite from running the
test, in Non-Secure mode (Cortex-M), because passing a NULL
device name de-references memory at 0x0 which is likely to
cause a SecureFault and crash the kernel.
Signed-off-by: Ioannis Glaropoulos <Ioannis.Glaropoulos@nordicsemi.no>
The test_timeout_abs case had baked in similar mistakes to the
off-by-one in the absolute timer implementation. FOR THE RECORD:
If you have an absolute timeout expiration set for a tick value "N",
and the current time returned by k_uptime_ticks() is "T", then the
time returned (at the same moment) by any of the *_remaining_ticks()
APIs must ALWAYS AND FOREVER BE EXACTLY "N - T" (also: "N - T > 0"
always, until the moment the kernel ISR hands off control to the first
timeout handler expiring at that tick).
The tick math is exact. No slop is needed on any systems, no matter
whether their clocks divide by milliseconds or not.
The only gotcha is that we need to be sure that the calls don't
interleave with a real time tick advance, which we do here with a
simple retry loop.
But, about slop... This patch also includes a related fix for the
test_sleep_abs(). On an intel_adsp (which has 50 kHz ticks, a
comparatively slow idle resume and interrupt entry, and even has two
CPUs to mess with latency measurements) I would occasionally see the
k_sleep() take more than a tick to wake up from the interrupt handler
until the return to application code. Add some real time slop there
(just 100us) to handle systems like this.
Fixes#32572
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
THIS COMMIT DELIBERATELY BREAKS BISECTABILITY FOR EASE OF REVIEW.
SKIP IF YOU LAND HERE.
Remove the existing implementatoin of k_thread_abort(),
k_thread_join(), and the attendant facilities in the thread subsystem
and idle thread that support them.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
When the kernel is TICKLESS, timeouts are set as needed, and drivers
all have some minimum amount of time before which they can reliably
schedule an interrupt. When this happens, drivers will kick the
requested interrupt out by one tick. This means that it's not
reliably possible to get a timeout set for "one tick in the
future"[1].
And attempting to do that is dangerous anyway. If the driver will
delay a one-tick interrupt, then code that repeatedly tries to
schedule an imminent interrupt may end up in a state where it is
constantly pushing the interrupt out into the future, and timer
interrupts stop arriving! The timeout layer actually has protection
against this case.
Finally getting to the point: in recent changes, the timeslice layer
lost its integration with the "imminent" test in the timeout code, so
it's now able to run into this situation: very rapidly context
switching code (or rapidly arriving interrupts) will have the effect
of infinitely[2] delaying timeouts and stalling the whole timeout
subsystem.
Don't try to be fancy. Just clamp timeslice duration such that a
slice is 2 ticks at minimum and we'll never hit the problem. Adjust
the two tests that were explicitly requesting very short slice rates.
[1] Of course, the tradeoff is that the tick rate can be 100x higher
or more, so on balance tickless is a huge win.
[2] Actually it only lasts until a 31 bit signed rollover in the HPET
cycle count in practice.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
gen_isr_table uses 6 IRQs for testing. Originally, it uses IRQ 41-36.
However, the IRQ37 & 36 are enabled by other modules in NPCX chips.
Change TEST_NUM_IRQS to use 45-40 for the test.
Signed-off-by: Wealian Liao <WHLIAO@nuvoton.com>
When calculating the expected interval for threads other than
the first one, the test uses ms->ticks->cycles conversion to
figure out the bound of cycles permitted. Both lower and upper
bound conversions are using the k_*_to_*_floor32(). When
numbers involved are not wholly divisible, decimal points are
being truncated, resulting in incorrect intervals, and thus
failing tests. So change the calculation to appropriate
floor() or ceil() based on the boundary.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Absolute timeouts were covered, but nothing was testing their actual
expiration time and there was an off-by-one.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Besides implementing a customized pm_policy_next_state() in the
application layer, a customized device policy handler of power
management, pm_policy_low_power_devices(), is also needed if
CONFIG_PM_POLICY_APP is enabled. This CL adds this function to prevent
build errors.
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
This adds qemu_x86_lakemont to the platform allow list
for the FPU sharing tests. Since Lakemont supports SSE3
and SSSE3, it is better to test them also.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
Correct a bunch of precision/analysis errors in this test:
* Test items weren't consistent about tick alignment and resetting of
the timestamp, so put these steps into init_timer_data() and call
that immediately before k_timer_start().
* Many items would calculate the initial timestamp AFTER
k_timer_start(), leading to an extra (third!) point where the timer
computation could alias by an extra tick. Always do this
consistently before the timer is started (via init_timer-data()).
* Tickless systems with high tick rates can easily advance the system
uptime while the timer ISR is running, so the system can't expect
perfect accuracy even there (this test was originally written for
ticked systmes where the ISR was by definition happening "at the
same time").
(Unfortunately our most popular high tick rate tickless system,
nRF5, also has a clock that doesn't divide milliseconds exactly, so
it had a special path through all these precision comparisons and
avoided the bugs. We finally found it on a x86 HPET system with 10
kHz ticks.)
* The interval validation was placing a minimum bound on the interval
time but not a maximum (this mistake was what had hidden the failure
to reset the timestamp mentioned above).
Longer term, the millisecond precision math in these tests is at this
point an out of control complexity explosion. We should look at
reworking the core OS tests of k_timer to use tick precision (which is
by definition exact) pervasively and leave the millisecond stuff to a
separate layer testing the alternative/legacy APIs.
Fixes#31964 (probably -- that was reported against up_squared, on
which I had trouble reproducing, but it was a common failure on
ehl_crb).
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This adds X86 keyword to the kconfigs to indicate these are
for x86. The old options are still there marked as
deprecated.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
A fairly common idiom in our test code is to put test-local data
structures onto the stack, even when they are to be used from another
thread. But stacks are incoherent memory on some platforms, which
means that such things may not get a consistent view of memory between
threads.
Just make these things static. A few of these spots were causing test
failures on intel_adsp_cavs15. More were found by inspection while
hunting for mistakes.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
Thread stack memory on coherence platforms needs to be linked into a
special section (so it can be cached).
Also, the test_idle_stack case just can't work with coherence. It's
measuring the CPU's idle stack's unused data, which was initialized at
boot from CPU0, and not necessarily the CPU on which the test is
running. In practice on intel_adsp_cavs15, our CPU has stale zeroes
in the cache for its unused stack area (presumably from a firmware
memory clear at boot or something?). Making this work would require a
cache invalidate on all CPUs at boot time before the idle threads
start, we can't do it here in the test because we don't know where the
idle stack pointer is.
Too much work for an esoteric stack size test, basically. Just
disable on these platforms.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
It was discovered that TLS data/bss in stack need to be
aligned correctly or else incorrect variables would be
accessed. This makes tdata and tbss sections to have
odd sizes to make sure everything still works.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The deadline scheduler as of commit ef626571b2 ("kernel/sched:
Optimize deadline comparison") got an optimization that requires that
the the cycle difference of the deadline time of the "first" and
"last" runnable thread never be higher than 2^31.
The test code here was masking off the bottom 31 bits of the generated
deadlines, so it looked OK. But because the actual setting of the
deadline values takes time too, it was still possible to select values
that would roll over. The window was VERY small, but the RNG on one
platform (up_squared) hit it.
Shrink the selected deadlines to live in a 30 bit space for safety.
Fixes#31508
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
This reverts commit 79d73063af.
The issue #31333 is fixed so this can be reverted to
enable tests/kernel/context to run with demand paging enabled.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The inheritance test first creates a parent thread, and then
creates a child thread inside this parent thread. At the same
time inside the main thread, a resource pool is assigned to
the parent thread. However, when under SMP, it is possible
that the pool assignment is done between both parent/child
threads are getting pointers to the pool, due to multiple
threads are running. So when doing pool pointer comparison,
there is a mismatch between those pointers (like parent has
a null pool pointer while child is pointing to the actual
pool), and thus failing the test. So fix this by delaying
the parent from running under after pool assignment is done.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
When coverage is enabled on x86_64, GCC uses relative addressing
to increment the gcov counters. The generated code of the test
function assumes execution is in the same location where
the linker places the test function. This does not work with
the execution test as it copies the function into another part
of memory and tries to execute from there. When the copied
function starts to run, the instruction pointer is at the newly
copied function. So any relative addressing with regard to
the instruction pointer now is invalid. Instead of
<generated code RIP + offset> for gcov counter as it should be,
now the copied code is trying to access the counter at
<copied code RIP + offset>, which points to incorrect
memory location (and possibly invalid/non-mapped memory).
To fix this, we need to tell GCC not to use relative addressing.
This can be accomplished by telling GCC to use the large memory
model. This is only used for this test as this option increases
code size quite a bit, and should not be used in general.
Fixes#30434
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This puts the transplanted_function into its own section so that
z_phys_map() can correctly map the whole range of memory used
by the function, in case someone decides to expand the function
to be bigger than a MMU page.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The test_mem_domain_migration test creates a new thread with
different priority based on whether SMP is enabled. This causes
an issue where SMP=y and MP_NUM_CPUS=1 where the spin_entry()
would spin forever (with k_busy_wait()) and not yielding since
it has cooperative priority. Fix this by using MP_NUM_CPUS to
figure out which priority to use, as it is valid configuration
to have SMP=y and MP_NUM_CPUS=1.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
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>
the implementation of spinlock validation uses two LSB bits in the
bottom of a pointer union to store a CPU index, which only has space
for 4 CPUS. the MP_NUM_CPUS should be <= 4.
Signed-off-by: Watson Zeng <zhiwei@synopsys.com>
Clean up logging menuconfig by grouping configuration into
sections like: mode, processing configuration, backends.
Additionlly, removed LOG_ENABLE_FANCY_OUTPUT_FORMATTING which is no
longer in use.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
Add some error condition of testcases to verify whether the
robustness of API. Such as give a NULL to some API and check
the response if get result that we were expacted.
Signed-off-by: Jian Kang <jianx.kang@intel.com>
Some arches like x86 need all memory mapped so that they can
fetch information placed arbitrarily by firmware, like ACPI
tables.
Ensure that if this is the case, the kernel won't accidentally
clobber it by thinking the relevant virtual memory is unused.
Otherwise this has no effect on page frame management.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
