xenomai.list at gmail.com
Wed Jul 8 23:19:50 CEST 2020
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.
More information about the Xenomai