[Xenomai] bad syscall <0x197>

[Xenomai] bad syscall <0x197>

[steve freyder]

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/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

Re: [Xenomai] bad syscall <0x197>

[Greg Gallagher]

On Wed, Feb 24, 2021 at 3:45 PM steve freyder via Xenomai <
xenomai@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@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/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

Re: [Xenomai] bad syscall <0x197>

[steve freyder]

On 2/24/2021 2:52 PM, Greg Gallagher wrote:
>
>
> On Wed, Feb 24, 2021 at 3:45 PM steve freyder via Xenomai 
> <xenomai@xenomai.org <mailto:xenomai@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@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/xenomai@xenomai.org/msg17931.html
>     <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...

Re: [Xenomai] bad syscall <0x197>

[Greg Gallagher]

On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve@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@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@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/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

Re: [Xenomai] bad syscall <0x197>

[Greg Gallagher]

On Thu, Feb 25, 2021 at 3:06 PM Greg Gallagher <greg@embeddedgreg.com>
wrote:

>
>
> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve@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@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@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/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.

Thanks

Greg

Re: [Xenomai] bad syscall <0x197>

[Jan Kiszka]

On 27.02.21 07:21, Greg Gallagher via Xenomai wrote:
> On Thu, Feb 25, 2021 at 3:06 PM Greg Gallagher <greg@embeddedgreg.com>
> wrote:
> 
>>
>>
>> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve@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@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@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/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.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [Xenomai] bad syscall <0x197>

[Jan Kiszka]

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@embeddedgreg.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve@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@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@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/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.
> 

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

Re: [Xenomai] bad syscall <0x197>

[Greg Gallagher]

On Mon, Mar 1, 2021 at 12:53 PM Jan Kiszka <jan.kiszka@siemens.com> wrote:

> 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@embeddedgreg.com>
> >> wrote:
> >>
> >>>
> >>>
> >>> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve@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@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@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/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.
> >
>
> 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
>

I don't see an obvious use case, I can put a patch together for it's
removal and do some testing.

-Greg

Re: [Xenomai] bad syscall <0x197>

[Philippe Gerum]

Jan Kiszka <jan.kiszka@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@embeddedgreg.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 24, 2021 at 6:16 PM steve freyder <steve@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@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@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/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.