Re: [Xenomai] xenomai cyclictest negative Max value

2017-12-19 Thread Peng Fan 
On Wed, Dec 20, 2017 at 02:49:53PM +0800, Peng Fan wrote:
>On Mon, Dec 18, 2017 at 10:26:28AM +0800, Peng Fan wrote:
>>Hi All,
>>
>>I compiled xenomai-next on my ARM64 platform, but met Max and Avg not correct.
>>See below:
>>
>>./cyclictest -a -t10 -n -p99 -c 0
>># /dev/cpu_dma_latency set to 0us
>>policy: fifo: loadavg: 0.97 0.51 0.21 1/135 3018
>>policy: fifo: loadavg: 1.00 0.76 0.38 1/128 3018
>>T:[  200.650323] random: crng init done  0 Act:0 Avg:443149053456561 
>>Max:  -1
>>T: 0 ( 3002) P:99 I:1000 C: 373066 Min:  0 Act:0 Avg:395570629834068 
>>Max:  -11
>>T: 1 ( 3003) P:99 I:1500 C: 248710 Min:  0 Act:0 Avg:148339383810136 
>>Max:  -111
>>T: 2 ( 3004) P:99 I:2000 C: 186532 Min:  0 Act:0 Avg:593359125738518 
>>Max:  -1
>>T: 3 ( 3005) P:99 I:2500 C: 149359 Min:  0 Act:0 Avg:123506076458128 
>>Max:  -11
>>T: 4 ( 3006) P:99 I:3000 C: 124465 Min:  0 Act:0 Avg:592833136181562 
>>Max:  -1
>>T: 5 ( 3007) P:99 I:3500 C: 106684 Min:  0 Act:0 Avg:172910127795260 
>>Max:  -111
>>T: 6 ( 3008) P:99 I:4000 C:  93349 Min:  0 Act:0 Avg:1383273613171719 
>>Max:  -1
>>T: 7 ( 3009) P:99 I:4500 C:  82977 Min:  0 Act:0 Avg:666934598998863 
>>Max:  -1
>>T: 8 ( 3010) P:99 I:5000 C:  74679 Min:  0 Act:0 Avg:988055226969271 
>>Max:  -11
>>
>>Seems xenomai cyclictest and rt-tests cyclictest is not sync, or there are
>>some differecense. Could you please help me clarify what's the difference
>>between xenomai cyclictest and rt-tests cyclictest?  I did not find out which
>>exact commit number when importing rt-tests cyclictest to xenomai.
>
>I add a debug info in cyclictest.c, see below:
>
>diff --git a/demo/posix/cyclictest/cyclictest.c 
>b/demo/posix/cyclictest/cyclictest.c
>index 31d9e5d0b..b16321cd9 100644
>--- a/demo/posix/cyclictest/cyclictest.c
>+++ b/demo/posix/cyclictest/cyclictest.c
>@@ -920,6 +920,11 @@ void *timerthread(void *param)
>diff = calcdiff_ns(now, next);
>else
>diff = calcdiff(now, next);
>+
>+   if (diff == -1) {
>+   printf(" %ld %ld %ld %ld\n", now.tv_sec, 
>now.tv_nsec, next.tv_sec, next.tv_nsec);
>+   exit(0);
>+   }
>if (diff < stat->min)
>stat->min = diff;
>if (diff > stat->max) {
>
>And I encounter the case that diff is -1,
>" 16124 21743627 16124 21744638"
>only 1ns difference between now and next.

Typo: it is 1011 ns.

The arch timer freq is 8MHz, resolution is 125ns.

>This means clock_nanosleep wakeup earlier than expected?
>I am using 4.9.51 kernel, and xenomai-next on ARM64. I am tracking
>the hrtimer things, but no good progress. Please advise, if you any ideas.
>
>Thanks,
>Peng.
>
>>
>>Thanks,
>>Peng.
>>
>>-- 
>
>-- 

-- 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] xenomai cyclictest negative Max value

2017-12-19 Thread Peng Fan 
On Mon, Dec 18, 2017 at 10:26:28AM +0800, Peng Fan wrote:
>Hi All,
>
>I compiled xenomai-next on my ARM64 platform, but met Max and Avg not correct.
>See below:
>
>./cyclictest -a -t10 -n -p99 -c 0
># /dev/cpu_dma_latency set to 0us
>policy: fifo: loadavg: 0.97 0.51 0.21 1/135 3018
>policy: fifo: loadavg: 1.00 0.76 0.38 1/128 3018
>T:[  200.650323] random: crng init done  0 Act:0 Avg:443149053456561 
>Max:  -1
>T: 0 ( 3002) P:99 I:1000 C: 373066 Min:  0 Act:0 Avg:395570629834068 
>Max:  -11
>T: 1 ( 3003) P:99 I:1500 C: 248710 Min:  0 Act:0 Avg:148339383810136 
>Max:  -111
>T: 2 ( 3004) P:99 I:2000 C: 186532 Min:  0 Act:0 Avg:593359125738518 
>Max:  -1
>T: 3 ( 3005) P:99 I:2500 C: 149359 Min:  0 Act:0 Avg:123506076458128 
>Max:  -11
>T: 4 ( 3006) P:99 I:3000 C: 124465 Min:  0 Act:0 Avg:592833136181562 
>Max:  -1
>T: 5 ( 3007) P:99 I:3500 C: 106684 Min:  0 Act:0 Avg:172910127795260 
>Max:  -111
>T: 6 ( 3008) P:99 I:4000 C:  93349 Min:  0 Act:0 Avg:1383273613171719 
>Max:  -1
>T: 7 ( 3009) P:99 I:4500 C:  82977 Min:  0 Act:0 Avg:666934598998863 
>Max:  -1
>T: 8 ( 3010) P:99 I:5000 C:  74679 Min:  0 Act:0 Avg:988055226969271 
>Max:  -11
>
>Seems xenomai cyclictest and rt-tests cyclictest is not sync, or there are
>some differecense. Could you please help me clarify what's the difference
>between xenomai cyclictest and rt-tests cyclictest?  I did not find out which
>exact commit number when importing rt-tests cyclictest to xenomai.

I add a debug info in cyclictest.c, see below:

diff --git a/demo/posix/cyclictest/cyclictest.c 
b/demo/posix/cyclictest/cyclictest.c
index 31d9e5d0b..b16321cd9 100644
--- a/demo/posix/cyclictest/cyclictest.c
+++ b/demo/posix/cyclictest/cyclictest.c
@@ -920,6 +920,11 @@ void *timerthread(void *param)
diff = calcdiff_ns(now, next);
else
diff = calcdiff(now, next);
+
+   if (diff == -1) {
+   printf(" %ld %ld %ld %ld\n", now.tv_sec, 
now.tv_nsec, next.tv_sec, next.tv_nsec);
+   exit(0);
+   }
if (diff < stat->min)
stat->min = diff;
if (diff > stat->max) {

And I encounter the case that diff is -1,
" 16124 21743627 16124 21744638"
only 1ns difference between now and next.
This means clock_nanosleep wakeup earlier than expected?
I am using 4.9.51 kernel, and xenomai-next on ARM64. I am tracking
the hrtimer things, but no good progress. Please advise, if you any ideas.

Thanks,
Peng.

>
>Thanks,
>Peng.
>
>-- 

-- 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Lowell Gilbert 
Steve Pavao  writes:

> Thanks for that tip.  That’s what I was thinking I might need to do.
>
> I guess the solution in Yocto terms is to rework my I-PIPE patch
> recipe to not directly apply the I-PIPE patch, but rather to call
> prepare-kernel.sh and allow it to apply the patch, plus do the other
> things it needs to do.  I guess that should happen in a do_configure()
> {} block.

That's very much the sort of workflow towards which I was planning to move. 

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Jeff Melvile 
Hi Steve,

On Tue, 19 Dec 2017, Steve Pavao wrote:

> Hi Jan,
> 
> > On Dec 19, 2017, at 2:24 PM, Jan Kiszka  wrote:
> > 
> > On 2017-12-19 19:49, Steve Pavao wrote:
> >> Hi Lowell,
> >> 
> >> Thanks for that tip.  That’s what I was thinking I might need to do.
> >> 
> >> I guess the solution in Yocto terms is to rework my I-PIPE patch recipe to 
> >> not directly apply the I-PIPE patch, but rather to call prepare-kernel.sh 
> >> and allow it to apply the patch, plus do the other things it needs to do.  
> >> I guess that should happen in a do_configure() {} block.
> > 
> > Actually, I would move the kernel patching out of the xenomai recipe and
> > rather have one recipe for the userspace packages and a
> > xenomai-kernel.inc which appends the kernel preparation task with the
> > prepare-kernel.sh invocation. It would also bring in (once again) the
> > xenomai sources so that its kernel elements get pulled into the kernel
> > build. In your kernel recipe, you would simply include that file.
> > 
> > This way, the kernel could come from various sources, including
> > git.xenomai.org/ipipe.git, and just needs to have the I-pipe patch
> > already applied, either in it git source or by adding a corresponding
> > patch to the custom kernel recipe.
> > 
> > This seems similar to how ELDK modeled this:
> > http://git.denx.de/?p=eldk.git;a=tree;f=meta-eldk/recipes-kernel/xenomai;h=bf965c6d2fa5132413b498161c90f337be8fb174;hb=refs/heads/5.8-eldk
> >  
> > 
> 
> Thanks for your advice, Jan.  I was hoping to keep things as simple as 
> possible, though.  The ELDK example has a highly-customized bb recipe.
> 
> Could I achieve my ends If I use my initial idea, which is to call the 
> prepare-kernel.sh from a do_configure block, rather than directly applying 
> the I-PIPE patch?  It seems like it won’t succeed, based on what you have 
> said, perhaps because the recipe that calls prepare-kernel.sh is going to 
> need to be more complex than simply calling that script.  (You mentioned 
> about needing to pull in the xenomai sources once again).

Back on Xenomai 2.6, I created a bbappend for the kernel recipes that 
pulls in the Xenomai source in addition to the kernel source. It added a 
'prepare_xenomai_kernel_ task in between do_patch and do_kernel_configme. 
The extra task ran the prepare-kernel.sh script and some other cleanup. In 
our case we were actually appending the linux-xlnx recipes from 
meta-xilinx for their Zynq kernel fork. The task had to support pre/post 
versions of the I-pipe patch as well. The userspace libraries were a 
separate recipe. One of my colleagues has been working on transitioning 
our flow to Xenomai 3 for the Zynq UltraScale+ but other priorities keep 
popping up. 

> 
> I think I need to hand this task off to a colleague who has some more Linux 
> internals experience.
> 
> > That is outdated now, unfortunately. Do you plan to publish your layer
> > afterwards? I suppose some people would be happy about a meta-xenomai
> > with support for Xenomai 3.
> 
> I’d have to check with my organization.  Personally, I’d like to see anyone 
> publish one, including us.  Anything that allows folks to start using Xenomai 
> 3 more easily from within their highly-customized Poky environments would be 
> helpful.

+1. I'll check in on the status of our Xenomai 3 work and what it would 
take to share what we have. I'd certainly like to see something reusable 
arise and would be willing to help.
> 
> - Steve Pavao
> Korg R
> 
> 
> 
> 
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Jeff
 
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Steve Pavao 
Hi Jan,

> On Dec 19, 2017, at 2:24 PM, Jan Kiszka  wrote:
> 
> On 2017-12-19 19:49, Steve Pavao wrote:
>> Hi Lowell,
>> 
>> Thanks for that tip.  That’s what I was thinking I might need to do.
>> 
>> I guess the solution in Yocto terms is to rework my I-PIPE patch recipe to 
>> not directly apply the I-PIPE patch, but rather to call prepare-kernel.sh 
>> and allow it to apply the patch, plus do the other things it needs to do.  I 
>> guess that should happen in a do_configure() {} block.
> 
> Actually, I would move the kernel patching out of the xenomai recipe and
> rather have one recipe for the userspace packages and a
> xenomai-kernel.inc which appends the kernel preparation task with the
> prepare-kernel.sh invocation. It would also bring in (once again) the
> xenomai sources so that its kernel elements get pulled into the kernel
> build. In your kernel recipe, you would simply include that file.
> 
> This way, the kernel could come from various sources, including
> git.xenomai.org/ipipe.git, and just needs to have the I-pipe patch
> already applied, either in it git source or by adding a corresponding
> patch to the custom kernel recipe.
> 
> This seems similar to how ELDK modeled this:
> http://git.denx.de/?p=eldk.git;a=tree;f=meta-eldk/recipes-kernel/xenomai;h=bf965c6d2fa5132413b498161c90f337be8fb174;hb=refs/heads/5.8-eldk
>  
> 

Thanks for your advice, Jan.  I was hoping to keep things as simple as 
possible, though.  The ELDK example has a highly-customized bb recipe.

Could I achieve my ends If I use my initial idea, which is to call the 
prepare-kernel.sh from a do_configure block, rather than directly applying the 
I-PIPE patch?  It seems like it won’t succeed, based on what you have said, 
perhaps because the recipe that calls prepare-kernel.sh is going to need to be 
more complex than simply calling that script.  (You mentioned about needing to 
pull in the xenomai sources once again).

I think I need to hand this task off to a colleague who has some more Linux 
internals experience.

> That is outdated now, unfortunately. Do you plan to publish your layer
> afterwards? I suppose some people would be happy about a meta-xenomai
> with support for Xenomai 3.

I’d have to check with my organization.  Personally, I’d like to see anyone 
publish one, including us.  Anything that allows folks to start using Xenomai 3 
more easily from within their highly-customized Poky environments would be 
helpful.

- Steve Pavao
Korg R




___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Jan Kiszka 
On 2017-12-19 19:49, Steve Pavao wrote:
> Hi Lowell,
> 
> Thanks for that tip.  That’s what I was thinking I might need to do.
> 
> I guess the solution in Yocto terms is to rework my I-PIPE patch recipe to 
> not directly apply the I-PIPE patch, but rather to call prepare-kernel.sh and 
> allow it to apply the patch, plus do the other things it needs to do.  I 
> guess that should happen in a do_configure() {} block.

Actually, I would move the kernel patching out of the xenomai recipe and
rather have one recipe for the userspace packages and a
xenomai-kernel.inc which appends the kernel preparation task with the
prepare-kernel.sh invocation. It would also bring in (once again) the
xenomai sources so that its kernel elements get pulled into the kernel
build. In your kernel recipe, you would simply include that file.

This way, the kernel could come from various sources, including
git.xenomai.org/ipipe.git, and just needs to have the I-pipe patch
already applied, either in it git source or by adding a corresponding
patch to the custom kernel recipe.

This seems similar to how ELDK modeled this:
http://git.denx.de/?p=eldk.git;a=tree;f=meta-eldk/recipes-kernel/xenomai;h=bf965c6d2fa5132413b498161c90f337be8fb174;hb=refs/heads/5.8-eldk

That is outdated now, unfortunately. Do you plan to publish your layer
afterwards? I suppose some people would be happy about a meta-xenomai
with support for Xenomai 3.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Weird behavior during debug

2017-12-19 Thread Jan Kiszka 
On 2017-12-19 14:44, Lange Norbert wrote:
> 
> Problem persists in ipipe-core-4.9.51-x86-4, ipipe-4.4 kernel crashes at boot 
> (likely no good support for this SOC).
> Used program is attached, it is being executed twice, once directly via 
> serial or ssh, once via gdbserver or gdb (tested various combinations).
> 
> The directly executed program will stop (supposedly at read), as soon as the 
> debugged program is halted.

OK, now I get the point: You need
http://git.xenomai.org/xenomai-3.git/commit/?id=0d653e6db75f01287f83ddc3a4ba8189f0bd0366,
but that is only in next so far.

What happens in stable (and also in older versions) is that all Xenomai
timers in the system are stopped once one Xenomai application enters a
ptrace state. That is going to vanish in the next version, and we may
consider taking it to stable as well. What do you think, Philippe?

Jan

> 
> Norbert
> 
>  >-Original Message-
>  >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>  >Sent: Dienstag, 19. Dezember 2017 10:35
>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>  >Subject: Re: Weird behavior during debug
>  >
>  >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
>  >caution with email content and any links or attachments.
>  >
>  >
>  >On 2017-12-19 09:56, Lange Norbert wrote:
>  >> Hello Jan,
>  >>
>  >> My follow-up post was done after running the latest ipipe-4.9.y patch, 
> with
>  >your fix added on top.
>  >>
>  >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>  >> index 834e6117f5f8..b9f6121c8530 100644
>  >> --- a/arch/x86/Kconfig
>  >> +++ b/arch/x86/Kconfig
>  >> @@ -83,7 +83,7 @@ config X86
>  >> select HAVE_AOUTif X86_32
>  >> select HAVE_ARCH_AUDITSYSCALL
>  >> select HAVE_ARCH_HUGE_VMAP  if X86_64 || X86_PAE
>  >> -   select HAVE_ARCH_JUMP_LABEL
>  >> +   select HAVE_ARCH_JUMP_LABEL if !IPIPE
>  >> select HAVE_ARCH_KASAN  if X86_64 &&
>  >SPARSEMEM_VMEMMAP
>  >> select HAVE_ARCH_KGDB
>  >> select HAVE_ARCH_KMEMCHECK
>  >>
>  >
>  >Does the problem persist with
>  >- ipipe-core-4.9.51-x86-4
>  >- ipipe-4.4
>  >?
>  >
>  >Jan
>  >
>  >> Norbert
>  >>
>  >>  >-Original Message-
>  >>  >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>  >>  >Sent: Dienstag, 19. Dezember 2017 08:16
>  >>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>  >>  >Subject: Re: Weird behavior during debug
>  >>  >
>  >>  >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please
>  >exercise
>  >>  >caution with email content and any links or attachments.
>  >>  >
>  >>  >
>  >>  >On 2017-12-18 15:49, Lange Norbert wrote:
>  >>  >> Same issue with latest ipipe. Threads look like this (when the 
> instance is
>  >>  >halted in the debugger).
>  >>  >> Somehow, atleast the RT Tasks will block waiting on a timerfd when one
>  >task
>  >>  >is in state XT (whatever that means)
>  >>  >>
>  >>  >> # cat /proc/xenomai/sched/threads
>  >>  >> CPU  PIDCLASS  TYPE  PRI   TIMEOUT   STAT   NAME
>  >>  >>   0  0  idle   core   -1   - R  [ROOT/0]
>  >>  >>   1  0  idle   core   -1   - R  [ROOT/1]
>  >>  >>   2  0  idle   core   -1   - R  [ROOT/2]
>  >>  >>   3  0  idle   core   -1   - R  [ROOT/3]
>  >>  >>   2  264rt cobalt 20   - XT 
> packetfilter
>  >>  >>   1  279rt cobalt 20   - W  
> packetfilter
>  >>  >>
>  >>  >
>  >>  >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
>  >>  >Please retry either with the latest version or the last release
>  >>  >(ipipe-core-4.9.51-x86-4).
>  >>  >
>  >>  >Jan
>  >>  >
>  >>  >>  >-Original Message-
>  >>  >>  >From: Lange Norbert
>  >>  >>  >Sent: Montag, 18. Dezember 2017 14:43
>  >>  >>  >To: Xenomai (xenomai@xenomai.org)
>  >>  >>  >Subject: Weird behavior during debug
>  >>  >>  >
>  >>  >>  >Hello,
>  >>  >>  >
>  >>  >>  >I tried debugging a cobalt application, and when I hit a breakpoint 
> most
>  >of
>  >>  >the
>  >>  >>  >system freezes.
>  >>  >>  >If I run for example top over Serial or SSH, then the display won`t 
> be
>  >>  >refreshed
>  >>  >>  >anymore,
>  >>  >>  >A separate program running as RT Task, waiting for an timer-event
>  >>  >(occurring
>  >>  >>  >10 times a second) will block aswell.
>  >>  >>  >
>  >>  >>  >So the debug session seems to block a rather big amount of events.
>  >>  >>  >
>  >>  >>  >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of
>  >unhandled
>  >>  >>  >faults over the head domain".
>  >>  >>  >Looking at the logs and other threads there seems to be a bigger 
> rework
>  >in
>  >>  >>  >progress?
>  >>  >>  >I will retry with master, and report back.
>  >>  >>  >
>  >>  >>  >Kind regards
>  >>  >>  >
>  >>  >>  >Norbert Lange
>  >>  >>
>  >>  >>

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Steve Pavao 
Hi Lowell,

Thanks for that tip.  That’s what I was thinking I might need to do.

I guess the solution in Yocto terms is to rework my I-PIPE patch recipe to not 
directly apply the I-PIPE patch, but rather to call prepare-kernel.sh and allow 
it to apply the patch, plus do the other things it needs to do.  I guess that 
should happen in a do_configure() {} block.

- Steve

> On Dec 19, 2017, at 1:27 PM, Lowell Gilbert  wrote:
> 
> Steve Pavao  writes:
> 
>> Here are my recipes, which work fine, but Cobalt core does not boot.  I must 
>> need something else in my recipe(s).
>> 
>> For I-PIPE Patch, my recipe file is linux-intel_4.9.bbappend:
>> 
>> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>> SRC_URI += "file://ipipe-core-4.9.51-x86-4.patch"
> 
> This gets you the interrupt pipeline, but not Xenomai itself.
> That's the prepare-kernel.sh script, typically.
> 
> Be well.


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Lowell Gilbert 
Steve Pavao  writes:

> Here are my recipes, which work fine, but Cobalt core does not boot.  I must 
> need something else in my recipe(s).
>
> For I-PIPE Patch, my recipe file is linux-intel_4.9.bbappend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://ipipe-core-4.9.51-x86-4.patch"

This gets you the interrupt pipeline, but not Xenomai itself.
That's the prepare-kernel.sh script, typically.

Be well.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Cobalt core and Yocto

2017-12-19 Thread Greg Gallagher 
Others might be able to give a more concrete answer, but usually I
check for the existence of /proc/xenomai as a very quick test.   You
can also run the autotune script and check that there are no errors in
the output.  If this is meant to be a smoke test it may worth while to
run the autotune script to calibrate the core clock timers and then
run the latency script to verify the latency on the system.  This will
also give you some feedback on if cobalt is up and running.

On Tue, Dec 19, 2017 at 11:51 AM, Steve Pavao  wrote:
> Hello -
>
> How should I adapt my Yocto poky recipes to make sure that Cobalt core boots? 
>  Right now, the only relevant information that appears on dmesg is:
>
> "Interrupt pipeline (release #4)”
>
> Here are my recipes, which work fine, but Cobalt core does not boot.  I must 
> need something else in my recipe(s).
>
> For I-PIPE Patch, my recipe file is linux-intel_4.9.bbappend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> SRC_URI += "file://ipipe-core-4.9.51-x86-4.patch"
>
>
> For Xenomai 3 user libs, my recipe file is xenomai_3.0.6.bb:
>
> DESCRIPTION = "Provides userspace xenomai support and libraries needed to for 
> \
> real-time applications using the xenomai RTOS implementation (v3)"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = 
> "file://include/COPYING;md5=79ed705ccb9481bf9e7026b99f4e2b0e"
> SECTION = "xenomai"
> HOMEPAGE = "http://www.xenomai.org/;
> PR = "r0"
>
> SRC_URI = 
> "http://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.6.tar.bz2;
>
> S = "${WORKDIR}/xenomai-${PV}"
>
> inherit autotools pkgconfig
>
> includedir = "/usr/include/xenomai"
>
> #Fixes QA Issues: non debug package contains .debug directory
> #FILES_${PN}-dbg += "/usr/bin/regression/posix/.debug"
> #FILES_${PN}-dbg += "/usr/bin/regression/native/.debug"
> #FILES_${PN}-dbg += "/usr/bin/regression/native+posix/.debug"
> #FILES_${PN}-dbg += "/usr/demo/.debug/*"
>
> #Fixes QA Error - Non-dev package contains symlink .so
> FILES_${PN}-dev += "/usr/lib/*.se"
>
> #Add directories to package for shipping
> FILES_${PN} += "/dev"
> FILES_${PN} += "/dev/*"
> FILES_${PN} += "/usr/bin/*"
> FILES_${PN} += "/usr/lib/*"
> FILES_${PN} += "/usr/sbin/*"
> FILES_${PN} += "/usr/include/*"
> FILES_${PN} += "/usr/lib/*"
> FILES_${PN} += "/usr/share/doc/*"
> FILES_${PN} += "/usr/share/man/*"
> FILES_${PN} += "/usr/demo/*"
>
> SRC_URI[md5sum] = "6017203d0992bb5334498c196bf6f25d"
> SRC_URI[sha256sum] = 
> "2c0dd3f0e36e4a10f97e0028989bb873e80f4d1ce212ac55fd3b28857c464f94"
>
> TARGET_CC_ARCH += "${LDFLAGS}”
>
>
> Thanks for any ideas.  Hopefully, I am pretty close with these recipes.
>
> - Steve Pavao
> Korg R
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] Cobalt core and Yocto

2017-12-19 Thread Steve Pavao 
Hello -

How should I adapt my Yocto poky recipes to make sure that Cobalt core boots?  
Right now, the only relevant information that appears on dmesg is:

"Interrupt pipeline (release #4)”

Here are my recipes, which work fine, but Cobalt core does not boot.  I must 
need something else in my recipe(s).

For I-PIPE Patch, my recipe file is linux-intel_4.9.bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI += "file://ipipe-core-4.9.51-x86-4.patch"


For Xenomai 3 user libs, my recipe file is xenomai_3.0.6.bb:

DESCRIPTION = "Provides userspace xenomai support and libraries needed to for \
real-time applications using the xenomai RTOS implementation (v3)"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://include/COPYING;md5=79ed705ccb9481bf9e7026b99f4e2b0e"
SECTION = "xenomai"
HOMEPAGE = "http://www.xenomai.org/;
PR = "r0"

SRC_URI = 
"http://xenomai.org/downloads/xenomai/stable/latest/xenomai-3.0.6.tar.bz2;

S = "${WORKDIR}/xenomai-${PV}"

inherit autotools pkgconfig

includedir = "/usr/include/xenomai"

#Fixes QA Issues: non debug package contains .debug directory
#FILES_${PN}-dbg += "/usr/bin/regression/posix/.debug"
#FILES_${PN}-dbg += "/usr/bin/regression/native/.debug"
#FILES_${PN}-dbg += "/usr/bin/regression/native+posix/.debug"
#FILES_${PN}-dbg += "/usr/demo/.debug/*"

#Fixes QA Error - Non-dev package contains symlink .so
FILES_${PN}-dev += "/usr/lib/*.se"

#Add directories to package for shipping
FILES_${PN} += "/dev"
FILES_${PN} += "/dev/*"
FILES_${PN} += "/usr/bin/*"
FILES_${PN} += "/usr/lib/*"
FILES_${PN} += "/usr/sbin/*"
FILES_${PN} += "/usr/include/*"
FILES_${PN} += "/usr/lib/*"
FILES_${PN} += "/usr/share/doc/*"
FILES_${PN} += "/usr/share/man/*"
FILES_${PN} += "/usr/demo/*"

SRC_URI[md5sum] = "6017203d0992bb5334498c196bf6f25d"
SRC_URI[sha256sum] = 
"2c0dd3f0e36e4a10f97e0028989bb873e80f4d1ce212ac55fd3b28857c464f94"

TARGET_CC_ARCH += "${LDFLAGS}” 


Thanks for any ideas.  Hopefully, I am pretty close with these recipes.

- Steve Pavao
Korg R
















___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai] xenomai / realtime robotics job opening at Max Planck

2017-12-19 Thread Vincent Berenz 
A position for a roboticist / software-engineer is available at the Max 
Planck Institute for Intelligent Systems in Tuebingen (Germany).


The selected candidate will work on improving our software architecture 
for the realtime control of our humanoid robots (which uses xenomai).


Details on the position (and how to apply) can be found here:
https://am.is.tuebingen.mpg.de/jobs/robotics-software-engineer

Some videos of our work and robots in action:
https://youtu.be/71gciiVrOsY
https://youtu.be/OdE_Kj1aPkY
https://youtu.be/jMj3Uv2Q8Xg
https://youtu.be/VgKoX3RuvB0

Vincent Berenz

ps: this is posted with the exceptional agreement of the moderator of 
the list, because the job is tightly related to xenomai usage. Note that 
job posting on the list should be rare and only with the authorization 
to do so.




___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai-git] Marek Vasut : utils/can: Fix Makefile.am

2017-12-19 Thread git repository hosting 
Module: xenomai-3
Branch: stable-3.0.x
Commit: cbc6b87bed0fe7d6d932d943fc8ca0fb49bb5b71
URL:
http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=cbc6b87bed0fe7d6d932d943fc8ca0fb49bb5b71

Author: Marek Vasut 
Date:   Tue Dec 19 13:43:15 2017 +0100

utils/can: Fix Makefile.am

Prefix CPPFLAGS and LDFLAGS with AM_ to make automake actually
use those and propagate external CPPFLAGS and LDFLAGS settings
into the build.

Signed-off-by: Marek Vasut 

---

 utils/can/Makefile.am |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/utils/can/Makefile.am b/utils/can/Makefile.am
index 570758d..561dc71 100644
--- a/utils/can/Makefile.am
+++ b/utils/can/Makefile.am
@@ -4,11 +4,11 @@ bin_PROGRAMS = rtcanrecv rtcansend
 
 CCLD = $(top_srcdir)/scripts/wrap-link.sh $(CC)
 
-CPPFLAGS = \
+AM_CPPFLAGS =  \
@XENO_USER_CFLAGS@  \
-I$(top_srcdir)/include
 
-LDFLAGS = @XENO_AUTOINIT_LDFLAGS@ $(XENO_POSIX_WRAPPERS)
+AM_LDFLAGS = @XENO_AUTOINIT_LDFLAGS@ $(XENO_POSIX_WRAPPERS)
 
 rtcanconfig_SOURCES = rtcanconfig.c
 


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai-git

Re: [Xenomai] Weird behavior during debug

2017-12-19 Thread Lange Norbert 
 >>  >progress?
 >>  >>  >I will retry with master, and report back.
 >>  >>  >
 >>  >>  >Kind regards
 >>  >>  >
 >>  >>  >Norbert Lange
 >>  >>
 >>  >> 
 >>  >>
 >>  >> This message and any attachments are solely for the use of the intended
 >>  >recipients. They may contain privileged and/or confidential information or
 >>  >other information protected from disclosure. If you are not an intended
 >>  >recipient, you are hereby notified that you received this email in error 
 >> and
 >that
 >>  >any review, dissemination, distribution or copying of this email and any
 >>  >attachment is strictly prohibited. If you have received this email in 
 >> error,
 >please
 >>  >contact the sender and delete the message and any attachment from your
 >>  >system.
 >>  >>
 >>  >> ANDRITZ HYDRO GmbH
 >>  >>
 >>  >>
 >>  >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung /
 >Corporation
 >>  >>
 >>  >> Firmensitz/ Registered seat: Wien
 >>  >>
 >>  >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
 >>  >>
 >>  >> Firmenbuchnummer/ Company registration: FN 61833 g
 >>  >>
 >>  >> DVR: 0605077
 >>  >>
 >>  >> UID-Nr.: ATU14756806
 >>  >>
 >>  >>
 >>  >> Thank You
 >>  >> 
 >>  >>
 >>  >> ___
 >>  >> Xenomai mailing list
 >>  >> Xenomai@xenomai.org
 >>  >> https://xenomai.org/mailman/listinfo/xenomai
 >>  >>
 >>  >
 >>  >--
 >>  >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
 >>  >Corporate Competence Center Embedded Linux
 >> 
 >>
 >> This message and any attachments are solely for the use of the intended
 >recipients. They may contain privileged and/or confidential information or
 >other information protected from disclosure. If you are not an intended
 >recipient, you are hereby notified that you received this email in error and 
 >that
 >any review, dissemination, distribution or copying of this email and any
 >attachment is strictly prohibited. If you have received this email in error, 
 >please
 >contact the sender and delete the message and any attachment from your
 >system.
 >>
 >> ANDRITZ HYDRO GmbH
 >>
 >>
 >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation
 >>
 >> Firmensitz/ Registered seat: Wien
 >>
 >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
 >>
 >> Firmenbuchnummer/ Company registration: FN 61833 g
 >>
 >> DVR: 0605077
 >>
 >> UID-Nr.: ATU14756806
 >>
 >>
 >> Thank You
 >> 
 >>
 >
 >
 >--
 >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
 >Corporate Competence Center Embedded Linux


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

-- next part --
An embedded and charset-unspecified text was scrubbed...
Name: timerfd.c
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20171219/ec797aab/attachment.c>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Xenomai: halcmd[1311] cannot map MAYDAY page

2017-12-19 Thread Philippe Gerum 
On 12/14/2017 06:07 PM, John Allwine wrote:
> I'm using the latest machinekit image for the 3.8 kernel on the Beaglebone
> Black (
> https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/machinekit/bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img.xz).
> It's using xenomai 2.6.3. I follow the steps in this document to set up
> machinekit as a systemd service:
> https://github.com/PocketNC/pocketnc/blob/master/README.md
>

2.6.3 is fairly outdated, but I guess you have no choice with machinekit
at the moment.

> When I start machinekit manually after bootup, it seems to work fine. When
> the services are started during boot up as a systemd service, I get the
> following error (I can provide the full stack trace if that would help):
> [ 19.501859] Xenomai: halcmd[1311] cannot map MAYDAY page
> [ 19.956681] Unable to handle kernel NULL pointer dereference at virtual
> address 0004
> [ 19.965136] pgd = de414000, hw pgd = de414000
> [ 19.969675] [0004] *pgd=9e7c4831, *pte=, *ppte=
> [ 19.976229] Internal error: Oops: 817 [#1
> ] THUMB2
> [ 19.981128] Modules linked in: g_ether libcomposite cpufreq_userspace
> 
> I filed this issue on machinekit's github repo as well:
> https://github.com/machinekit/machinekit/issues/1332
> 
> Any thoughts on what the problem could be? Or how to debug this further?

Assuming the crash is an unexpected side-effect of not being able to map
the mayday page, the latter would be the issue to chase. Mapping the
mayday page to a userland app requires to have access to a chrdev named
/dev/rtheap, created by the Xenomai core, and later exposed by udev.
This mapping fails.

Since systemd is involved, I suspect that a real-time application
(halcmd?) is started by some unit before the Xenomai core has fully
initialized.

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

[Xenomai-git] Philippe Gerum : boilerplate/bootstrap: dual-license the bootstrap source code

2017-12-19 Thread git repository hosting 
Module: xenomai-3
Branch: stable-3.0.x
Commit: f18416cd11628c37aef8b2c564f8174dfd3e80bf
URL:
http://git.xenomai.org/?p=xenomai-3.git;a=commit;h=f18416cd11628c37aef8b2c564f8174dfd3e80bf

Author: Philippe Gerum 
Date:   Tue Dec 19 11:18:26 2017 +0100

boilerplate/bootstrap: dual-license the bootstrap source code

lib/boilerplate/bootstrap.c is meant to be glued to the application
executable for bootstrapping the Cobalt services automatically at load
up.

>From the standpoint of its sole author (i.e. me), doing so adds no
requirement with respect to the licensing terms of the containing
application.

Allow lib/boilerplate/bootstrap.c to be distributed under the terms of
the MIT license to reflect this fact.

---

 lib/boilerplate/init/bootstrap.c |   29 +
 1 file changed, 29 insertions(+)

diff --git a/lib/boilerplate/init/bootstrap.c b/lib/boilerplate/init/bootstrap.c
index e72a7b8..64a11c2 100644
--- a/lib/boilerplate/init/bootstrap.c
+++ b/lib/boilerplate/init/bootstrap.c
@@ -1,4 +1,33 @@
 /*
+ * The source code in this particular file is released using a dual
+ * license scheme.  You can choose the licence that better fits your
+ * requirements.
+ *
+ * ---
+ *
+ * Copyright (C) 2017 Philippe Gerum 
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included
+ * in all copies or substantial portions of the Software.
+ *  
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+ * IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+ * CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+ * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+ * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * ---
+ *
  * Copyright (C) 2013 Philippe Gerum .
  *
  * This library is free software; you can redistribute it and/or


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai-git

Re: [Xenomai] RTnet fixes - testers needed

2017-12-19 Thread Andreas Glatz 
>>>
>>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from 
>>> Sun
>>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>>
>>> I have created the packages and new kernel with the same configuration that 
>>> I had.
>>>
>>> I run my application, that it's a POSIX application Wrapped and I still 
>>> have the
>>> same error when I activate SMAP:
>>
>> I see that the page fault occurs in rt_packet_ioctl()... by the looks
>> of this bug it might be similar to the one I found in udp.c (see my
>> post from Sunday)... basically the ioctl still tries to access user
>> memory, which causes that stack trace. I'm currently a bit busy - I
>> hope I can continue debugging this by the end of this week.
>
> I should be able to squeeze this debug task in the coming 48 hours, I
> have your latest patched queued already. Let me know if you want to keep
> on addressing this issue, otherwise I'll tackle this stuff.
>

I think you'll be at it before me then :) I already made some more
progress in the UDP case. I can send you my latest patch tonight. I'm
also happy to keep testing + fixing when I find time for it! I can use
the RTnet UDP app from the company that I ported from kernel 3.0 to
4.9 to test the RTnet UDP stack.

Best,

A.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] RTnet fixes - testers needed

2017-12-19 Thread Philippe Gerum 

Hi Andreas,

On 12/19/2017 11:17 AM, Andreas Glatz wrote:
>>
>> I have pulled wip/rtnet-fixes branch with the last commit of Philippe from 
>> Sun
>> Dec 17 15:27:04 2017 +0100: net/udp: ioctl: fix temp arg buffer type
>>
>> I have created the packages and new kernel with the same configuration that 
>> I had.
>>
>> I run my application, that it's a POSIX application Wrapped and I still have 
>> the
>> same error when I activate SMAP:
> 
> I see that the page fault occurs in rt_packet_ioctl()... by the looks
> of this bug it might be similar to the one I found in udp.c (see my
> post from Sunday)... basically the ioctl still tries to access user
> memory, which causes that stack trace. I'm currently a bit busy - I
> hope I can continue debugging this by the end of this week. 

I should be able to squeeze this debug task in the coming 48 hours, I
have your latest patched queued already. Let me know if you want to keep
on addressing this issue, otherwise I'll tackle this stuff.

Thanks,

-- 
Philippe.

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Weird behavior during debug

2017-12-19 Thread Jan Kiszka 
On 2017-12-19 09:56, Lange Norbert wrote:
> Hello Jan,
> 
> My follow-up post was done after running the latest ipipe-4.9.y patch, with 
> your fix added on top.
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 834e6117f5f8..b9f6121c8530 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -83,7 +83,7 @@ config X86
> select HAVE_AOUTif X86_32
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_HUGE_VMAP  if X86_64 || X86_PAE
> -   select HAVE_ARCH_JUMP_LABEL
> +   select HAVE_ARCH_JUMP_LABEL if !IPIPE
> select HAVE_ARCH_KASAN  if X86_64 && SPARSEMEM_VMEMMAP
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_KMEMCHECK
> 

Does the problem persist with
- ipipe-core-4.9.51-x86-4
- ipipe-4.4
?

Jan

> Norbert
> 
>  >-Original Message-
>  >From: Jan Kiszka [mailto:jan.kis...@siemens.com]
>  >Sent: Dienstag, 19. Dezember 2017 08:16
>  >To: Lange Norbert; Xenomai (xenomai@xenomai.org)
>  >Subject: Re: Weird behavior during debug
>  >
>  >EMAIL from a NON-ANDRITZ SOURCE: as a security measure, please exercise
>  >caution with email content and any links or attachments.
>  >
>  >
>  >On 2017-12-18 15:49, Lange Norbert wrote:
>  >> Same issue with latest ipipe. Threads look like this (when the instance is
>  >halted in the debugger).
>  >> Somehow, atleast the RT Tasks will block waiting on a timerfd when one 
> task
>  >is in state XT (whatever that means)
>  >>
>  >> # cat /proc/xenomai/sched/threads
>  >> CPU  PIDCLASS  TYPE  PRI   TIMEOUT   STAT   NAME
>  >>   0  0  idle   core   -1   - R  [ROOT/0]
>  >>   1  0  idle   core   -1   - R  [ROOT/1]
>  >>   2  0  idle   core   -1   - R  [ROOT/2]
>  >>   3  0  idle   core   -1   - R  [ROOT/3]
>  >>   2  264rt cobalt 20   - XT packetfilter
>  >>   1  279rt cobalt 20   - W  packetfilter
>  >>
>  >
>  >Philippe reverted a number of commits in ipipe-4.9.y some days ago.
>  >Please retry either with the latest version or the last release
>  >(ipipe-core-4.9.51-x86-4).
>  >
>  >Jan
>  >
>  >>  >-Original Message-
>  >>  >From: Lange Norbert
>  >>  >Sent: Montag, 18. Dezember 2017 14:43
>  >>  >To: Xenomai (xenomai@xenomai.org)
>  >>  >Subject: Weird behavior during debug
>  >>  >
>  >>  >Hello,
>  >>  >
>  >>  >I tried debugging a cobalt application, and when I hit a breakpoint 
> most of
>  >the
>  >>  >system freezes.
>  >>  >If I run for example top over Serial or SSH, then the display won`t be
>  >refreshed
>  >>  >anymore,
>  >>  >A separate program running as RT Task, waiting for an timer-event
>  >(occurring
>  >>  >10 times a second) will block aswell.
>  >>  >
>  >>  >So the debug session seems to block a rather big amount of events.
>  >>  >
>  >>  >I am using a 4.9 kernel with ipipe at "x86/ipipe: fix detection of 
> unhandled
>  >>  >faults over the head domain".
>  >>  >Looking at the logs and other threads there seems to be a bigger rework 
> in
>  >>  >progress?
>  >>  >I will retry with master, and report back.
>  >>  >
>  >>  >Kind regards
>  >>  >
>  >>  >Norbert Lange
>  >>
>  >> 
>  >>
>  >> This message and any attachments are solely for the use of the intended
>  >recipients. They may contain privileged and/or confidential information or
>  >other information protected from disclosure. If you are not an intended
>  >recipient, you are hereby notified that you received this email in error 
> and that
>  >any review, dissemination, distribution or copying of this email and any
>  >attachment is strictly prohibited. If you have received this email in 
> error, please
>  >contact the sender and delete the message and any attachment from your
>  >system.
>  >>
>  >> ANDRITZ HYDRO GmbH
>  >>
>  >>
>  >> Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / 
> Corporation
>  >>
>  >> Firmensitz/ Registered seat: Wien
>  >>
>  >> Firmenbuchgericht/ Court of registry: Handelsgericht Wien
>  >>
>  >> Firmenbuchnummer/ Company registration: FN 61833 g
>  >>
>  >> DVR: 0605077
>  >>
>  >> UID-Nr.: ATU14756806
>  >>
>  >>
>  >> Thank You
>  >> 
>  >>
>  >> ___
>  >> Xenomai mailing list
>  >> Xenomai@xenomai.org
>  >> https://xenomai.org/mailman/listinfo/xenomai
>  >>
>  >
>  >--
>  >Siemens AG, Corporate Technology, CT RDA ITP SES-DE
>  >Corporate Competence Center Embedded Linux
> 
> 
> This message and any attachments are solely for the use of the intended 
> recipients. They may contain privileged and/or confidential information or 
> other information protected from disclosure. If you are not an intended 
> recipient, you are hereby notified that you received this email in