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

Greg Gallagher greg at embeddedgreg.com
Thu Jul 9 05:55:32 CEST 2020


On Wed, Jul 8, 2020 at 5:19 PM Robert Berger <xenomai.list at gmail.com> wrote:
> Hi,
> My comments are in-line.
> On 08/07/2020 15:41, Greg Gallagher wrote:
> > I'm using glibc 2.25.  The other thing to keep in mind is that the
> > message isn't coming from the Linux kernel, it's coming from Cobalt.
> > So it's possible cobalt is having some issues with a newer libc.  I'll
> > have time tonight to sit down with ftrace and see if I can get a
> > better idea of what's going on.
> >
> I traced the issue a bit more down.
> The problematic testcase is protect_trylock (posix-mutex.c:1063) since
> it calls __real_usleep()(lib/cobalt/wrappers.c:553); which causes
> [Xenomai] bad syscall <0x197>
> So yes, it looks like it's a combination of Cobalt and a new glibc.
> I am really surprised that no one else stumbled across this issue, since
> I can't even remember which Yocto Version used 4.19 or older kernel headers.
> My hack to use 4.19 kernel headers didn't help, since, as you say, it
> does not seem to be related to this issue.
> So I guess the ball is in Xenomai land ;)
> Having said that I am happy to test whatever you come up with and I
> guess I could also provide some remote test setup where you can play and
> see the issue.
> Regards,
> Robert

I tested the latest ipipe-arm 4.19.y-cip branch using the latest gcc
from Linaro (7.5) and I can't reproduce the error.  I'm assuming it's
because it's still using a 2.25 libc.  To investigate further I'll
have to build a newer tool chain and try the test again.  I'll have
time later this week to continue the investigation.  For now it seems
using libc 2.25 avoids the error.



More information about the Xenomai mailing list