On 27.02.21 07:21, Greg Gallagher via Xenomai wrote: > On Thu, Feb 25, 2021 at 3:06 PM Greg Gallagher <[email protected]> > wrote: > >> >> >> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <[email protected]> wrote: >> >>> >>> >>> On 2/24/2021 2:52 PM, Greg Gallagher wrote: >>> >>> >>> >>> On Wed, Feb 24, 2021 at 3:45 PM steve freyder via Xenomai < >>> [email protected]> wrote: >>> >>>> Greetings Xenomai list, >>>> >>>> >>>> I have a Linux OE 4.14.85 build with Xenomai 3.1 -next branch, and am >>>> seeing this: >>>> >>>> root@ICB-G3L:~ # uname -a >>>> Linux ICB-G3L 4.14.85_C01571-15S01A01.000.zimg+35a84af5b7 #1 SMP Mon Feb >>>> 22 20:57:38 UTC 2021 armv7l GN >>>> U/Linux >>>> root@ICB-G3L:~ # smokey --run=posix_mutex >>>> [ 694.433129] [Xenomai] bad syscall <0x197> >>>> posix_mutex OK >>>> >>>> I found this thread: >>>> >>>> https://www.mail-archive.com/[email protected]/msg17931.html >>>> >>>> But I can't get a clear picture on the proper resolution of this issue, >>>> other than it's related to a non-existent syscall, perhaps glibc >>>> version, and/or __real_usleep(). I'd like to get this working on either >>>> 4.14 or 4.19, is there a simple workaround for this? >>>> >>>> Thanks in advance, >>>> >>>> Steve >>>> >>>> >>>> >>>> >>>> I forgot all about this, I'll take a look tonight and see what's >>> involved. What gcc version are you using? >>> >>> Thanks >>> >>> Greg >>> >>> >>> >>> Greg, >>> >>> The compiler is gcc 9.3.0 using Yocto Dunfell. glibc 2.31... >>> >>> I'm able to reproduce this with gcc 10, I'll hopefully have a fix or >> solution shortly. >> >> -Greg >> > > I had some time to look into this. The issue seems to be coming from a > newer version of glibc being used with an older kernel. The usleep system > call has been updated in the newer glibc and is outside the range that > cobalt thinks is valid. Cobalt gets the valid range from the kernel, so > modifying it to accept this system call doesn't make much sense. I looked > at the newer 4.19 kernels and the system call range doesn't change. So I > think the better solution is to use an older toolchain, I had the test pass > with gcc 7.3. The newer 5.4 kernel does not hit this issue, using that > kernel may be an option. I'll do a 4.19 update once we sort out the CI > failures.
Seems like userspace is probing for the existence of that newer syscall, and that probing triggers the Cobalt warning. I thought we got rid of any warnings that are not related to RT? If not, it's time to do that now. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
