Post ABI 18 libevl would fail to detect incompatible core support by
receiving ENOTTY as a result of asking for the core information, due
to the change in size of the argument struct which was introduced to
support ABI ranges. Make sure to trap ENOTTY on this call as an ABI
mismatch too.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
uapi/evl should not directly depend on uapi/linux from the same kernel
release. The kernel definitions we need in uapi/evl should be limited
to linux/types.h, as available from a current toolchain. Revert the
uapi/linux export introduced by commit #5f68658b8.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
This set of changes makes libevl y2038-safe by switching to the ABI
revision 19 of the EVL core, which generalizes the use of a 64bit
timespec type. These changes also go a long way preparing for the
upcoming mixed 32/64 ABI support (aka compat mode).
The changes only affect the internal interface between libevl and the
kernel, not the API. Nevertheless, the API was bumped to revision 10
with the removal of the evl_adjust_clock() service, which neither had
proper specification nor defined use case currently, but would stand
in the way of the sanitization work for y2038. At any rate, any future
service implementing some sort of EVL clock adjustment should
definitely not depend on the legacy struct timex which is
y2038-unsafe.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Instead of matching whatever ABI we might be compiled against like
previously, define the kernel ABI we need as a prerequisite
(EVL_KABI_PREREQ), checking for sanity at build time and runtime.
This prerequisite is matched against the range of ABI revisions the
kernel supports (from EVL_ABI_BASE to EVL_ABI_CURRENT). In the
simplest case, the kernel implements a single ABI with no backward
compatibility mechanism (EVL_ABI_BASE == EVL_ABI_CURRENT).
This addresses two issues:
- the fact that libevl might build against a given set of uapi/ files
does not actually mean that the corresponding kernel ABI found there
is fully compatible with what libevl expects. Specifying a
compatible ABI prereq explicitly addresses this problem.
- we can obtain services from EVL cores supporting multiple ABI
revisions (i.e. providing backward compat feat).
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
This won't change anything EVL-wise, but this minimizes the risk of
conflicting thread priorities when running the in-band GPIO test over
a native preemption kernel.
Make sure we always drop the stax before exiting the test thread,
otherwise we might deadlock contenders. Replace the async cancellation
with a synchronous exit condition.
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Calling evl_read_clock() before the library is initialized should not
fault. Set arch_clock_gettime() to a valid fallback routine which
eventually hands over the request to clock_gettime().
Signed-off-by: Philippe Gerum <rpm@xenomai.org>
Since EVL-ABI rev. 17, the core sends an INBAND_TASK_RETUSER event to
force a user thread to call back, so that it can switch it to
out-of-band context. This mechanism does not require any support from
libevl. Drop SIGEVL_ACTION_HOME since it is now useless.
Crashes related to enabling precise unwind tables have been observed
in the implementation of the arm* unwinder upon receipt of SIGCANCEL,
triggered by a call to pthread_cancel(). Typically, the latmus program
might randomly crash or enter a runaway loop at exit on cancelling the
timer responder thread for no obvious reason, including anything
related to stack sanity (size or corruption).
This switch was originally turned on to help backtrace() in collecting
more accurate information when called from a SIGDEBUG
handler. Unfortunately, support for stack unwinding is tricky in
essence, and may be broken in specific toolchain releases, causing
segmentation violation on exit, e.g.:
With libevl built using
gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf:
warming up on CPU0 (not isolated)...
RTT| 00:00:01 (user, 1000 us period, priority 90, CPU0-noisol)
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD| 6.333| 6.874| 13.000| 0| 0| 6.333| 13.000
RTD| 6.333| 6.904| 19.666| 0| 0| 6.333| 19.666
^C
---|-----------|-----------|-----------|--------|------|-------------------------
RTS| 6.333| 6.889| 19.666| 0| 0| 00:00:02/00:00:02
Segmentation fault (core dumped)
(gdb) bt
regclass=regclass@entry=_UVRSC_CORE,
discriminator=discriminator@entry=16624,
representation=representation@entry=_UVRSD_UINT32)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/unwind-arm.c:240
uws=uws@entry=0xb6e35e64)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/pr-support.c:179
ucbp=0xb6e372a8, context=0xb6e36080, id=0)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/unwind-arm-common.inc:842
entry_vrs=<optimized out>, resuming=0)
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/unwind-arm-common.inc:349
at /home/tcwg-buildslave/workspace/tcwg-make-release_1/snapshots/gcc.git~linaro-7.5-2019.12/libgcc/config/arm/libunwind.S:359
---Type <return> to continue, or q <return> to quit---
ctx=<optimized out>) at nptl-init.c:216
from /lib/libc.so.6
Which in this particular case pointed at:
(gdb) x/20i $pc
=> 0xb6f4ca2c <_Unwind_VRS_Pop+244>: ldr r1, [r4, #0]
0xb6f4ca2e <_Unwind_VRS_Pop+246>: adds r4, #4
0xb6f4ca30 <_Unwind_VRS_Pop+248>: str.w r1, [r0, #-4]
0xb6f4ca34 <_Unwind_VRS_Pop+252>: cmp r3, #16
0xb6f4ca36 <_Unwind_VRS_Pop+254>:
(gdb) info reg
r0 0xb6e36098 3068354712
r1 0x10 16
r2 0x40f0 16624
r3 0x5 5
r4 0xf009e 983198
r5 0xb6e36080 3068354688
r6 0x1 1
r7 0x40f0 16624
r8 0x0 0
r9 0xb6e35e24 3068354084
r10 0x0 0
r11 0x1 1
r12 0xb6f5e0ac 3069567148
sp 0xb6e35cf0 0xb6e35cf0
lr 0xb6f4cf23 -1225470173
pc 0xb6f4ca2c 0xb6f4ca2c <_Unwind_VRS_Pop+244>
cpsr 0x40d1c30 67968048
Something definitely bad happened in the unwinder. Disable this option
by default, which works around the toolchain issue for the most common
use case.
This covers the uninit case (i.e. evl_init() did not run yet) and
whenever evl_vprint_proxy() is given an obviously invalid proxyfd
(i.e. negative), in which case we want the message to be sent out if
the caller runs in-band (not to induce any stage switch).
evl_udelay() was an annoying misnomer for people with kernel
development background, as this relates to a busy wait loop, not to a
sleeping call, which evl_udelay() actually was.
Rename this call to evl_usleep(), converging to the glibc signature
for usleep(3) in the same move.
Some tests might fail due to a lack of kernel support, such as a
missing driver which have to to be involved for running such
tests. Introduce the EXIT_NO_SUPPORT code for this case, to be
distinguished by the test runner from a functional failure.
Replace -a (abort-on-switch) with -K (keep-going upon
switch). Aborting becomes the default setting upon unexpected switch
to in-band mode of the responder thread, in order to prevent any
misinterpretation of broken results obtained from a broken set up.
Let the user generate any background noise as/if required. We simply
cannot approximate the typical load of the target system in a reliable
manner with a fixed dd-like loop.
Measure response time to GPIO events sent by a remote Zephyr-based
latency monitor (latmon). This monitor collects then sends the latency
data over a network connection to the latmus front-end which displays
the results received:
[Linux device under test running latmus] <--+
|
^ | (GPIO ack) |
| | | TCP/IP network connection
| | | (control & data samples)
| (GPIO pulse) v |
|
[Zephyr-based device running latmon] <--+
The generic latency monitor code running the measurement loop is
available from the zephyr/ directory. This support comes with a Zephyr
device tree patch for enabling this monitor on NXP's FRDM-K64F
development board.
Philippe Gerum