Jan Kiszka <[email protected]> writes:
> 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. >> We did, but only for valid syscalls. What is going now is the glibc issuing unknown syscalls from the kernel standpoint. > > 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? > That was probably done in accordance with (very) antiquated pipelines which might have prevented the common syscall path from checking for syscall validity, as a result of routing it to the real-time core first. Hence the reason for offloading such a check to the head syscall handler in that core. It should be safe to drop this. At any rate, we won't need this when running on top of Dovetail. -- Philippe.
