On 01.03.21 18:31, Jan Kiszka wrote: > 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. >
I think we should kill that check and branching: https://source.denx.de/Xenomai/xenomai/-/blob/2cc2f54b98921cc8ae2990eb4e8abb3f10902230/kernel/cobalt/posix/syscall.c#L649 The only purpose this has is keeping a caller from RT in RT when invoking an invalid Linux syscall - plus noisily complaining on the kernel console. What would be the use case for that? Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux
