[Xenomai] bad syscall <0x197>

Philippe Gerum rpm at xenomai.org
Tue Mar 2 14:58:44 CET 2021


Jan Kiszka <jan.kiszka at siemens.com> 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 <greg at embeddedgreg.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve at freyder.net> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 2/24/2021 2:52 PM, Greg Gallagher wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 24, 2021 at 3:45 PM steve freyder via Xenomai <
>>>>> xenomai at xenomai.org> wrote:
>>>>>
>>>>>> Greetings Xenomai list,
>>>>>>
>>>>>>
>>>>>> I have a Linux OE 4.14.85 build with Xenomai 3.1 -next branch, and am
>>>>>> seeing this:
>>>>>>
>>>>>> root at 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 at ICB-G3L:~ # smokey --run=posix_mutex
>>>>>> [  694.433129] [Xenomai] bad syscall <0x197>
>>>>>> posix_mutex OK
>>>>>>
>>>>>> I found this thread:
>>>>>>
>>>>>> https://www.mail-archive.com/xenomai@xenomai.org/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.



More information about the Xenomai mailing list