Re: xenomai 3.1/ipipe-core-4.19.128-cip28-arm-10.patch

[Robert Berger <xenomai.list@gmail.com>]

Hi,

My comments are in-line.

On 13/07/2020 20:08, Jan Kiszka wrote:
> On 08.07.20 01:04, Robert Berger via Xenomai wrote:
>> It looks like either we hit a glibc issue, or something is not clear 
>> to me in the xenomai test case.
>>
>> The glibc has a fallback for the unknown syscall. clock_nanosleep_time64
>>
>> Is this what the xenomai testcase tries to tell us?
>>
>> Than that is not an error, but fine;)
>>
> 
> If glibc is probing the existence of the new syscall by calling it, we 
> may silence the warning path. To my current reading, it must have been 
> triggered from a Xenomai thread in primary domain - are we sure that 
> this is correct behavior? Could you set a breakpoint on glibc call and 
> provide a backtrace?

When clock_nanosleep() is called from Linux the glibc first calls the 
clock_nanosleep_time64() syscall (which fails on a 4.19 kernel and 
succeeds on a 5.4 kernel). In case it fails glibc calls the old 
clock_nanosleep() syscall and all is good.

The problem here is that the testcase protect_trylock 
(posix-mutex.c:1063) calls __real_usleep()(lib/cobalt/wrappers.c:553); 
which causes [Xenomai] bad syscall <0x197>.

I guess __real_usleep should call the real POSIX implementation.

__weak
int __real_usleep(useconds_t usec)
{
         return usleep(usec);
}

usleep calls __nanosleep and this seems to cause the bad syscall.

Thread 1 "smokey" hit Breakpoint 3, usleep (useconds=useconds@entry=1) 
at ../sysdeps/posix/usleep.c:26
26        struct timespec ts = { .tv_sec = (long int) (useconds / 1000000),
(gdb) bt
#0  usleep (useconds=useconds@entry=1) at ../sysdeps/posix/usleep.c:26
#1  0xb6f81140 in __real_usleep (usec=usec@entry=1) at wrappers.c:555
#2  0x00418bf8 in protect_trylock () at posix-mutex.c:933
#3  run_posix_mutex (t=<optimized out>, argc=<optimized out>, 
argv=<optimized out>) at posix-mutex.c:1063
#4  run_posix_mutex (t=<optimized out>, argc=<optimized out>, 
argv=<optimized out>) at posix-mutex.c:1027
#5  0x004041c4 in main (argc=1, argv=0x438750) at main.c:34
(gdb) l
21      #include <unistd.h>
22
23      int
24      usleep (useconds_t useconds)
25      {
26        struct timespec ts = { .tv_sec = (long int) (useconds / 1000000),
27                               .tv_nsec = (long int) (useconds % 
1000000) * 1000ul };
28
29        /* Note the usleep() is a cancellation point.  But since we call
30           nanosleep() which itself is a cancellation point we do not have
(gdb) n
32        return __nanosleep (&ts, NULL);
(gdb) n
[ 2168.741990] [Xenomai] bad syscall <0x197>
protect_trylock () at posix-mutex.c:935
935             if (!__T(ret, pthread_mutex_trylock(&mutex)))
(gdb)

Just FYI this code with usleep() seems to work without xenomai:

int my_usleep(unsigned int millisec)
{
         int rc;
         rc = usleep(millisec);
         if (rc < 0) {
                 perror("my_usleep: ");
         }
         return rc;
}

int main(int argc, char *argv[])
{
         argc = argc;
         argv = argv;

         unsigned int millisec = 1;
         int rc;

         rc = my_usleep(millisec);

         exit(rc);
}


> 
> Jan
> 

Regards,

Robert