Re: [Xenomai-core] Analogy DIO speed

[Stefan Schaal]

Hi Alexis,

  thanks a lot or the reply. Just to check: is it possible to use commands with 
digital subdevices at all? I am not sure whether I understood your comment 
below correctly. Are your *currently* working to enable commands for DIO 
subdevices?

Thanks a lot!

-Stefan


On Mar 3, 2010, at 15:58, Alexis Berlemont wrote:

> Hi Stefan,
> 
> Sorry for the late reply, I was unavailable yesterday.
> 
> Stefan Schaal wrote:
>> Hi Alexis,
>> we pulled your analogy branch, and now cmd_write works. Great, and thanks a 
>> lot! Next, I tried to use commands with the digital IO subdevice on our 
>> board (subdevice #2), but the get an error message:
>> [ 2482.771913] Analogy: a4l_check_cmddesc: scan_begin_src, trigger 
>> unsupported
> Unfortunately, cmd_write was not designed to work with digital
> subdevices; the command's fields are not appropriate, I am trying to
> make it work quite quickly.
> 
>> Is there just missing support for the DIO subdevices using commands?
>> Best wishes,
>> -Stefan
>> ps.: feel free to use our machine for debugging -- it now has the latest 
>> version of your software installed with linux kernel 2.6.29.5.
>> On Feb 28, 2010, at 16:24, Alexis Berlemont wrote:
>>> Alexis Berlemont wrote:
 Hi,
 Stefan Schaal wrote:
> Hi Alexis,
> 
> On Feb 18, 2010, at 14:34, Alexis Berlemont wrote:
> 
>> I have some problems with
>>> implementing commands on my NI6259 so far.
>> Could you remind me what was the problem ?
> See the print-outs below for the problem we have.
> 
> Thanks so much for looking into this!
> 
> -Stefan
> 
> 
> 
> 
> Using the cmd_write() function that you provide in analogy, we get the 
> following problem:
> 
 I am currently trying to fix this bug, which is not that easy. I just
 have one question (that I remember I have already asked you in some way,
 but I just want to be sure):
 Does this bug occur the very first time you launched cmd_write (I mean
 after a reboot) ?
 
>>> I managed at last to fix the bug you were facing (at least I hope so).
>>> The problem was located in the trigger callback which waited for a
>>> bit-status (fifo half full) before going further; however, sometimes the
>>> DMA interrupt already occurred and cleaned everything behind your back.
>>> 
>>> I have not made a pull request because the current implementation is not
>>> perfect.
>>> 
>>> If you have some time, could you clone my git repository (branch:
>>> analogy) and check that a simple call to cmd_write does not trigger the
>>> bug anymore ?
>>> 
>>> Many thanks.
> r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v
> cmd_write: device analogy0 opened (fd=0)
> cmd_write: basic descriptor retrieved
>   subdevices count = 14
>   read subdevice index = 0
>   write subdevice index = 1
> cmd_write: complex descriptor retrieved
> cmd_write: channel 0
>   ranges count = 3
>   range's size = 16 (bits)
> cmd_write: channel 1
>   ranges count = 3
>   range's size = 16 (bits)
> cmd_write: scan size = 4
> cmd_write: size to write  = 400
> cmd_write: command successfully sent
> cmd_write: triggering failed (ret=-32)
> 
> r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c
> [133345.213865] Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: 
> b_status=0002 m1_status=80a8
> [133345.332719] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: 
> timed out waiting for dma load<3>Analogy: a4l_do_special_insn: execution 
> of the instruction failed (err=-32)
> 
> 
> Another problem we have is with the --mmap option:
> 
> r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v --mmap
> cmd_write: device analogy0 opened (fd=0)
> cmd_write: basic descriptor retrieved
>   subdevices count = 14
>   read subdevice index = 0
>   write subdevice index = 1
> cmd_write: complex descriptor retrieved
> cmd_write: channel 0
>   ranges count = 3
>   range's size = 16 (bits)
> cmd_write: channel 1
>   ranges count = 3
>   range's size = 16 (bits)
> cmd_write: scan size = 4
> cmd_write: size to write  = 400
> cmd_write: buffer size = 65536 bytes
> cmd_write: a4l_mmap() failed (ret=-22)
> 
> 
> r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c
> [133408.942998] Analogy: a4l_ioctl_mmap: mmap not allowed on this 
> subdevice
> 
> 
 Alexis.
>>> Alexis.
>>> 
> Alexis.
> 


___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Analogy DIO speed

[Alexis Berlemont]

Hi Stefan,

Sorry for the late reply, I was unavailable yesterday.

Stefan Schaal wrote:
> Hi Alexis,
> 
>  we pulled your analogy branch, and now cmd_write works. Great, and thanks a 
> lot! Next, I tried to use commands with the digital IO subdevice on our board 
> (subdevice #2), but the get an error message:
> 
> 
> [ 2482.771913] Analogy: a4l_check_cmddesc: scan_begin_src, trigger unsupported
Unfortunately, cmd_write was not designed to work with digital
subdevices; the command's fields are not appropriate, I am trying to
make it work quite quickly.

> 
> 
> Is there just missing support for the DIO subdevices using commands?
> 
> Best wishes,
> 
> -Stefan
> 
> 
> ps.: feel free to use our machine for debugging -- it now has the latest 
> version of your software installed with linux kernel 2.6.29.5.
> 
> 
> 
> 
> 
> On Feb 28, 2010, at 16:24, Alexis Berlemont wrote:
> 
>> Alexis Berlemont wrote:
>>> Hi,
>>> Stefan Schaal wrote:
 Hi Alexis,

 On Feb 18, 2010, at 14:34, Alexis Berlemont wrote:

> I have some problems with
>> implementing commands on my NI6259 so far.
> Could you remind me what was the problem ?
 See the print-outs below for the problem we have.

 Thanks so much for looking into this!

 -Stefan




 Using the cmd_write() function that you provide in analogy, we get the 
 following problem:

>>> I am currently trying to fix this bug, which is not that easy. I just
>>> have one question (that I remember I have already asked you in some way,
>>> but I just want to be sure):
>>> Does this bug occur the very first time you launched cmd_write (I mean
>>> after a reboot) ?
>>>
>> I managed at last to fix the bug you were facing (at least I hope so).
>> The problem was located in the trigger callback which waited for a
>> bit-status (fifo half full) before going further; however, sometimes the
>> DMA interrupt already occurred and cleaned everything behind your back.
>>
>> I have not made a pull request because the current implementation is not
>> perfect.
>>
>> If you have some time, could you clone my git repository (branch:
>> analogy) and check that a simple call to cmd_write does not trigger the
>> bug anymore ?
>>
>> Many thanks.
 r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v
 cmd_write: device analogy0 opened (fd=0)
 cmd_write: basic descriptor retrieved
subdevices count = 14
read subdevice index = 0
write subdevice index = 1
 cmd_write: complex descriptor retrieved
 cmd_write: channel 0
ranges count = 3
range's size = 16 (bits)
 cmd_write: channel 1
ranges count = 3
range's size = 16 (bits)
 cmd_write: scan size = 4
 cmd_write: size to write  = 400
 cmd_write: command successfully sent
 cmd_write: triggering failed (ret=-32)

 r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c
 [133345.213865] Analogy: analogy_ni_pcimio: ni_mio_common: interrupt: 
 b_status=0002 m1_status=80a8
 [133345.332719] Analogy: analogy_ni_pcimio: ni_ao_wait_for_dma_load: timed 
 out waiting for dma load<3>Analogy: a4l_do_special_insn: execution of the 
 instruction failed (err=-32)


 Another problem we have is with the --mmap option:

 r...@xenomai:/usr/src/xenomai/src/utils/analogy# ./cmd_write -v --mmap
 cmd_write: device analogy0 opened (fd=0)
 cmd_write: basic descriptor retrieved
subdevices count = 14
read subdevice index = 0
write subdevice index = 1
 cmd_write: complex descriptor retrieved
 cmd_write: channel 0
ranges count = 3
range's size = 16 (bits)
 cmd_write: channel 1
ranges count = 3
range's size = 16 (bits)
 cmd_write: scan size = 4
 cmd_write: size to write  = 400
 cmd_write: buffer size = 65536 bytes
 cmd_write: a4l_mmap() failed (ret=-22)


 r...@xenomai:/usr/src/xenomai/src/utils/analogy# dmesg -c
 [133408.942998] Analogy: a4l_ioctl_mmap: mmap not allowed on this subdevice


>>> Alexis.
>> Alexis.
>>
> 
> 
Alexis.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Xenomai in Debian

[Philippe Gerum]

On Wed, 2010-03-03 at 17:54 +0100, Stefan Kisdaroczi wrote:
> Am 26.02.2010 15:07, schrieb Philippe Gerum:
> > On Fri, 2010-02-26 at 14:48 +0100, Stefan Kisdaroczi wrote:
> >> Am 26.02.2010 14:28, schrieb Philippe Gerum:
> >>> On Fri, 2010-02-26 at 14:13 +0100, Stefan Kisdaroczi wrote:
>  Am 24.02.2010 14:13, schrieb Philippe Gerum:
> > On Wed, 2010-02-24 at 14:11 +0100, Philippe Gerum wrote:
> >> On Wed, 2010-02-24 at 14:06 +0100, Stefan Kisdaroczi wrote:
> >>> Hi Philippe,
> >>>
> >>> Am 23.02.2010 18:46, schrieb Philippe Gerum:
>  On Tue, 2010-02-23 at 17:52 +0100, Stefan Kisdaroczi wrote:
> > Hi,
> >
> > Am 14.02.2010 10:38, schrieb Philippe Gerum:
> >>
> >> 
> >> In the future, maybe we could simply provide a wrapper script 
> >> accepting
> >> sub-commands, such as "xeno latency, xeno sigtest" etc, to be put
> >> into /usr/bin by distros, which would hide the actual location of 
> >> those
> >> binaries?
> >>
> >> In any case, thanks for your work so far. We probably need to 
> >> discuss
> >> the packaging issues on this list, so that we get both consistency 
> >> and
> >> usability in the future.
> >>
> >> Gilles and Roland, if this is fine with you, I'll handle the 
> >> liaison
> >> role with upstream packagers, so please CC me explicitly on those 
> >> mails.
> >> We'll sort out this issue, it doesn't look that bad anyway.
> >
> > Roland added a xeno wrapper to the debian.org xenomai package 
> > 2.5.1-3.
> >
> > I synced now the debian/ directories from debian.org and 
> > xenomai.org:
> >  - For debian.org I sent patches to the Debian bugtracker [1] [2].
> >Another patch for dpkg-cross support [3] I sent to Roland 
> > privately.
> >  - For xenomai.org I attached patches to this mail (against 
> > -2.5.git).
> >
> > If both parties apply the patches the debian directories are in 
> > sync,
> > except some minor differences in the debian/control file, see patch
> > do-not-commit-please.patch. I would like to keep these changes out 
> > so
> > that the xenomai.org packages are compatible with Debian 5.0 Lenny.
> > The debian.org packages are for Debian 6.0 Squeeze.
> >
> 
>  Merged into my queue (except the last one as mentioned). This will be
>  pushed upstream to Gilles for 2.5.2. Thanks.
> >>>
> >>> I took a look at your branch for-upstream. Your commit
> >>>   scripts: add wrapper script to run standard Xenomai commands
> >>>   6e0574791f48cbf8b3421a68c5789254e7d084b7
> >>> adds the same wrapper as my patch 
> >>> 0005-debian-wrapper-script-usr-bin-xeno-to-call-executa.patch
> >>>   debian: wrapper script /usr/bin/xeno to call executables in 
> >>> /usr/lib/xenomai/
> >>>   fbe86cc50d3a65cd23e93d43adba4ed369fe70b1
> >>> Please revert the commit of my patch, we need another fix for 
> >>> debian/rules for "your" wrapper.
> >>>
> >>
> >> Ok, I thought your patch set was based on my tree, so I did not check
> >> thoroughly. I did not send any pull request to Gilles, so no harm done.
> >>
> >>> How do I call configure to install the wrapper in /usr/bin and
> >>> the programs like latency, switchtest etc. to /usr/lib/xenomai ?
> >>>
> >>
> >> We need some fixage in scripts/wrappers/Makefile.am to do that. I'll
> >> prepare this asap.
> >
> > scripts/Makefile.am...
> 
>  Hi Philippe,
> 
>  I just tried the --with-testdir switch. It worked, but i'm not really 
>  sure if
>  this is the right track.
> 
>  Roland's packages install all binaries to /usr/lib/xenomai, except xeno 
>  and
>  xeno-config. You state in your commit message more or less the same goal:
>  "At some point, all remaining executables or scripts left under 
>  $prefix/bin should match
>  xeno*, to further reduce the odds of causing name collisions."
> 
>  Using --with-testdir all tests (latency,switchtest,...) are now in 
>  /usr/lib/xenomai.
>  To install the "utils" (rtcansend,insn_write,insn_write,cmd_read,...) to 
>  the same
>  directory using --with-testdir sounds not obviously. You could add a 
>  second switch
>  --with-utildir, but a second dir will not work for the 
>  xeno-wrapper-script.
> 
> >>>
> >>> CAN and other utilities should definitely remain in $bindir. The fact
> >>> that they are not prefixed by xeno* is another thing; CAN utilities are
> >>> already prefixed, maybe Analogy ones should be named in a bit less
> >>> generic way, although they are not raising any conflict today. I wrote
> >>> that what's under $bindir "should" mat

Re: [Xenomai-core] Xenomai in Debian

[Stefan Kisdaroczi]

Am 26.02.2010 15:07, schrieb Philippe Gerum:
> On Fri, 2010-02-26 at 14:48 +0100, Stefan Kisdaroczi wrote:
>> Am 26.02.2010 14:28, schrieb Philippe Gerum:
>>> On Fri, 2010-02-26 at 14:13 +0100, Stefan Kisdaroczi wrote:
 Am 24.02.2010 14:13, schrieb Philippe Gerum:
> On Wed, 2010-02-24 at 14:11 +0100, Philippe Gerum wrote:
>> On Wed, 2010-02-24 at 14:06 +0100, Stefan Kisdaroczi wrote:
>>> Hi Philippe,
>>>
>>> Am 23.02.2010 18:46, schrieb Philippe Gerum:
 On Tue, 2010-02-23 at 17:52 +0100, Stefan Kisdaroczi wrote:
> Hi,
>
> Am 14.02.2010 10:38, schrieb Philippe Gerum:
>>
>> 
>> In the future, maybe we could simply provide a wrapper script 
>> accepting
>> sub-commands, such as "xeno latency, xeno sigtest" etc, to be put
>> into /usr/bin by distros, which would hide the actual location of 
>> those
>> binaries?
>>
>> In any case, thanks for your work so far. We probably need to discuss
>> the packaging issues on this list, so that we get both consistency 
>> and
>> usability in the future.
>>
>> Gilles and Roland, if this is fine with you, I'll handle the liaison
>> role with upstream packagers, so please CC me explicitly on those 
>> mails.
>> We'll sort out this issue, it doesn't look that bad anyway.
>
> Roland added a xeno wrapper to the debian.org xenomai package 2.5.1-3.
>
> I synced now the debian/ directories from debian.org and xenomai.org:
>  - For debian.org I sent patches to the Debian bugtracker [1] [2].
>Another patch for dpkg-cross support [3] I sent to Roland 
> privately.
>  - For xenomai.org I attached patches to this mail (against -2.5.git).
>
> If both parties apply the patches the debian directories are in sync,
> except some minor differences in the debian/control file, see patch
> do-not-commit-please.patch. I would like to keep these changes out so
> that the xenomai.org packages are compatible with Debian 5.0 Lenny.
> The debian.org packages are for Debian 6.0 Squeeze.
>

 Merged into my queue (except the last one as mentioned). This will be
 pushed upstream to Gilles for 2.5.2. Thanks.
>>>
>>> I took a look at your branch for-upstream. Your commit
>>>   scripts: add wrapper script to run standard Xenomai commands
>>>   6e0574791f48cbf8b3421a68c5789254e7d084b7
>>> adds the same wrapper as my patch 
>>> 0005-debian-wrapper-script-usr-bin-xeno-to-call-executa.patch
>>>   debian: wrapper script /usr/bin/xeno to call executables in 
>>> /usr/lib/xenomai/
>>>   fbe86cc50d3a65cd23e93d43adba4ed369fe70b1
>>> Please revert the commit of my patch, we need another fix for 
>>> debian/rules for "your" wrapper.
>>>
>>
>> Ok, I thought your patch set was based on my tree, so I did not check
>> thoroughly. I did not send any pull request to Gilles, so no harm done.
>>
>>> How do I call configure to install the wrapper in /usr/bin and
>>> the programs like latency, switchtest etc. to /usr/lib/xenomai ?
>>>
>>
>> We need some fixage in scripts/wrappers/Makefile.am to do that. I'll
>> prepare this asap.
>
> scripts/Makefile.am...

 Hi Philippe,

 I just tried the --with-testdir switch. It worked, but i'm not really sure 
 if
 this is the right track.

 Roland's packages install all binaries to /usr/lib/xenomai, except xeno and
 xeno-config. You state in your commit message more or less the same goal:
 "At some point, all remaining executables or scripts left under 
 $prefix/bin should match
 xeno*, to further reduce the odds of causing name collisions."

 Using --with-testdir all tests (latency,switchtest,...) are now in 
 /usr/lib/xenomai.
 To install the "utils" (rtcansend,insn_write,insn_write,cmd_read,...) to 
 the same
 directory using --with-testdir sounds not obviously. You could add a 
 second switch
 --with-utildir, but a second dir will not work for the xeno-wrapper-script.

>>>
>>> CAN and other utilities should definitely remain in $bindir. The fact
>>> that they are not prefixed by xeno* is another thing; CAN utilities are
>>> already prefixed, maybe Analogy ones should be named in a bit less
>>> generic way, although they are not raising any conflict today. I wrote
>>> that what's under $bindir "should" match xeno* when a risk of collision
>>> exists, but there is no point in enforcing a stricter rule at this
>>> point. In any case, I don't want to enforce a never-in-bindir rule for
>>> all Xenomai binaries, we can still pick their names in a way that avoids
>>> obvious issues.
>>>
>>> The real problem was about tests, for which using rather generic names
>>> made sense.

Re: [Xenomai-core] Potential heap corruption on thread cleanup

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Hi Gilles,
>>>
>>> I'm pushing your findings to the list, also as my colleagues showed
>>> strong interest - this thing may explain rare corruptions for us as well.
>>>
>>> I thought a bit about that likely u_mode-related crash in your test case
>>> and have the following theory so far: If the xeno_current_mode storage
>>> is allocated on the application heap (!HAVE_THREAD, that's also what we
>>> are forced to use), it is automatically freed on thread termination in
>>> the context of the dying thread. If the thread is already migrated to
>>> secondary or if that happens while it is cleaned up (i.e. before calling
>>> for exit into the kernel), there is no problem, Xenomai will not touch
>>> the mode storage anymore. But if the thread happens to delete the
>>> storage "silently", without any migration, the final exit will trigger
>>> one further access. And that takes place against an invalid head area at
>>> this point.
>>>
>>> Does this make sense?
>> Yes, it is the issue we observed.
>>
>>> If that is true, all we need to do is to force a migration before
>>> releasing the mode storage. Could you check this?
>> No, that does not fly. Calling, for instance, __wrap_pthread_mutex_lock
>> in another TSD cleanup function is which could be called after the
>> current_mode TSD cleanup is allowed and could trigger a switch to
>> primary mode and a write to the u_mode.
>>
> 
> Good point. Mmh. Another, but ABI-breaking, way would be to add a
> syscall for deregistering the u_mode pointer...

That is the thing we did to verify that we had this bug. But this
syscall would be also called too soon, and suffers from the TSD cleanup
functions order again.

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Potential heap corruption on thread cleanup

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Hi Gilles,
>>
>> I'm pushing your findings to the list, also as my colleagues showed
>> strong interest - this thing may explain rare corruptions for us as well.
>>
>> I thought a bit about that likely u_mode-related crash in your test case
>> and have the following theory so far: If the xeno_current_mode storage
>> is allocated on the application heap (!HAVE_THREAD, that's also what we
>> are forced to use), it is automatically freed on thread termination in
>> the context of the dying thread. If the thread is already migrated to
>> secondary or if that happens while it is cleaned up (i.e. before calling
>> for exit into the kernel), there is no problem, Xenomai will not touch
>> the mode storage anymore. But if the thread happens to delete the
>> storage "silently", without any migration, the final exit will trigger
>> one further access. And that takes place against an invalid head area at
>> this point.
>>
>> Does this make sense?
> 
> Yes, it is the issue we observed.
> 
>> If that is true, all we need to do is to force a migration before
>> releasing the mode storage. Could you check this?
> 
> No, that does not fly. Calling, for instance, __wrap_pthread_mutex_lock
> in another TSD cleanup function is which could be called after the
> current_mode TSD cleanup is allowed and could trigger a switch to
> primary mode and a write to the u_mode.
> 

Good point. Mmh. Another, but ABI-breaking, way would be to add a
syscall for deregistering the u_mode pointer...

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] Potential heap corruption on thread cleanup

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Hi Gilles,
> 
> I'm pushing your findings to the list, also as my colleagues showed
> strong interest - this thing may explain rare corruptions for us as well.
> 
> I thought a bit about that likely u_mode-related crash in your test case
> and have the following theory so far: If the xeno_current_mode storage
> is allocated on the application heap (!HAVE_THREAD, that's also what we
> are forced to use), it is automatically freed on thread termination in
> the context of the dying thread. If the thread is already migrated to
> secondary or if that happens while it is cleaned up (i.e. before calling
> for exit into the kernel), there is no problem, Xenomai will not touch
> the mode storage anymore. But if the thread happens to delete the
> storage "silently", without any migration, the final exit will trigger
> one further access. And that takes place against an invalid head area at
> this point.
> 
> Does this make sense?

Yes, it is the issue we observed.

> 
> If that is true, all we need to do is to force a migration before
> releasing the mode storage. Could you check this?

No, that does not fly. Calling, for instance, __wrap_pthread_mutex_lock
in another TSD cleanup function is which could be called after the
current_mode TSD cleanup is allowed and could trigger a switch to
primary mode and a write to the u_mode.

-- 
Gilles.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] Potential heap corruption on thread cleanup

[Jan Kiszka]

Hi Gilles,

I'm pushing your findings to the list, also as my colleagues showed
strong interest - this thing may explain rare corruptions for us as well.

I thought a bit about that likely u_mode-related crash in your test case
and have the following theory so far: If the xeno_current_mode storage
is allocated on the application heap (!HAVE_THREAD, that's also what we
are forced to use), it is automatically freed on thread termination in
the context of the dying thread. If the thread is already migrated to
secondary or if that happens while it is cleaned up (i.e. before calling
for exit into the kernel), there is no problem, Xenomai will not touch
the mode storage anymore. But if the thread happens to delete the
storage "silently", without any migration, the final exit will trigger
one further access. And that takes place against an invalid head area at
this point.

Does this make sense?

If that is true, all we need to do is to force a migration before
releasing the mode storage. Could you check this?

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core