Hi,
I just took the latest and greatest stuff and built it with some Yocto
dunfell/3.1.1 SDK for some 32 bit ARM i.mx6.
Xenomai/cobalt v3.1 -- #5714ceede (2020-02-04 16:06:11 +0100)
When I run xeno-test I get this:
./xeno-test
++ echo 0
++ testdir=/usr/local/xenomai/bin
++ /usr/local/xenomai/bin/smokey --run random_alloc_rounds=64
pattern_check_rounds=64
arith OK
...
posix_clock OK
posix_cond OK
posix_fork OK
[ 466.998532] [Xenomai] bad syscall <0x197>
posix_mutex OK
posix_select OK
...
0x197 (407) is not avail in 4.19[1], but in 5.4[2]
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/tools/syscall.tbl?h=v4.19.131#n416
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/tools/syscall.tbl?h=v5.4.50#n424
The SDK was built against 5.4 kernel headers (which is the default for
Yocto dunfell/3.1.1).
If I run a small C app (without xenomai) which calls this:
static void xeno_sleep_ms(unsigned int ms)
{ /* < 1000 */
struct timespec ts;
ts.tv_sec = 0;
ts.tv_nsec = ms * 1000000;
clock_nanosleep(CLOCK_MONOTONIC, 0, &ts, NULL);
}
all is good both with 4.19.x and 4.5.kernel.
Can someone tell me tell me please where the bad syscall comes from?
It looks like someone calls clock_nanosleep_time64, but xenomai is
developed against 4.19.x where this sycall does not exist, so my first
idea would be that it comes from the glibc which was built against 5.4
kernel headers. But the xenomai test case triggers it! I suspect some
sleep_ms(1) in some weird combination with something but I am not sure
about it.
[ 251.080655] [Xenomai] bad syscall <0x197>
407 common clock_nanosleep_time64 sys_clock_nanosleep
Please point me towards where to search further.
Regards,
Robert
