* [Xenomai] Some Information About compilation Xenomai and RT Patches
@ 2014-06-17 15:00 Jean Rodriguez
[not found] ` <be428e33f9f5482aa36cbc1654ec2db2@EX132MBOX1B.de2.local>
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Jean Rodriguez @ 2014-06-17 15:00 UTC (permalink / raw
To: xenomai
Hi guys,
I’m trying to compile kernel 3.8 with the last xenomai source.
I want to know some precisions about preempt option.
Is it useless to patch the kernel with with Xenomai and also with RT patch
from kernel.org?
Because With RT patch I can choose on menuconfig Preemption Model 5 choices
(No preempt, Voluntary and low latency , preemptible kernel or fully
preemptivekernel)
But if I patch only with xenomai I have just 3 choices of preemptive (No
preempt, Voluntary and low latency)
If patch first with RT and after xenomai I have a lot of Hunk message
(warning and error) but if I Patch first with xenomai and after RT -> no
problem
So my question are they compatible together? Or perhaps choosing fully
preemptive will turn my system unstable.
My goal is to catch Interruption with a small latency (50-10 µs) with a low
processor charge
Board Arbor card
<http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
=1&version=+Default> EmETX-i2900 with ATOM N450
Thanks for your future response
Kind regards,
Jean Rodriguez
Ingénieur R&D Informatique
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
[not found] ` <be428e33f9f5482aa36cbc1654ec2db2@EX132MBOX1B.de2.local>
@ 2014-06-20 8:50 ` Stoidner, Christoph
0 siblings, 0 replies; 11+ messages in thread
From: Stoidner, Christoph @ 2014-06-20 8:50 UTC (permalink / raw
To: xenomai@xenomai.org
Hi Jean,
I have merged successfully I-Pipe/Xenomai and Preempt RT patch for Kernel V3.10.18. From my point of view it is working very well. The only part which was a bit of tricky to solve was the kernel's spinlock implementation. This is since I-Pipe as well as Preempt-RT are patching this part of code each with own implementations. As result it is required to replace Preempt RT's default spinlock calls with new wrappers. Within the wrappers you have to decide if Preempt RT's spinlock or I-Pipe's spinlock have to be used at this place.
My pending problem which I hope to solve soon is the fast context switch extension (FCSE) that allows better latency times on ARM9. In "guaranteed" mode it crashs when using addresses above 32MB.
If you are interested in more details feel free to ask.
Regards,
Christoph
________________________________________
Von: Xenomai <xenomai-bounces@xenomai.org> im Auftrag von Jean Rodriguez <j.rodriguez@caustier.com>
Gesendet: Dienstag, 17. Juni 2014 17:00
An: xenomai@xenomai.org
Betreff: [Xenomai] Some Information About compilation Xenomai and RT Patches
Hi guys,
I’m trying to compile kernel 3.8 with the last xenomai source.
I want to know some precisions about preempt option.
Is it useless to patch the kernel with with Xenomai and also with RT patch
from kernel.org?
Because With RT patch I can choose on menuconfig Preemption Model 5 choices
(No preempt, Voluntary and low latency , preemptible kernel or fully
preemptivekernel)
But if I patch only with xenomai I have just 3 choices of preemptive (No
preempt, Voluntary and low latency)
If patch first with RT and after xenomai I have a lot of Hunk message
(warning and error) but if I Patch first with xenomai and after RT -> no
problem
So my question are they compatible together? Or perhaps choosing fully
preemptive will turn my system unstable.
My goal is to catch Interruption with a small latency (50-10 µs) with a low
processor charge
Board Arbor card
<http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
=1&version=+Default> EmETX-i2900 with ATOM N450
Thanks for your future response
Kind regards,
Jean Rodriguez
Ingénieur R&D Informatique
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-17 15:00 [Xenomai] Some Information About compilation Xenomai and RT Patches Jean Rodriguez
[not found] ` <be428e33f9f5482aa36cbc1654ec2db2@EX132MBOX1B.de2.local>
@ 2014-06-20 9:00 ` Philippe Gerum
2014-06-20 9:02 ` Stoidner, Christoph
2 siblings, 0 replies; 11+ messages in thread
From: Philippe Gerum @ 2014-06-20 9:00 UTC (permalink / raw
To: Jean Rodriguez, xenomai
On 06/17/2014 05:00 PM, Jean Rodriguez wrote:
> Hi guys,
>
> I’m trying to compile kernel 3.8 with the last xenomai source.
>
> I want to know some precisions about preempt option.
>
> Is it useless to patch the kernel with with Xenomai and also with RT patch
> from kernel.org?
Combining both makes sense only if your use case involves response time
requirements when running regular linux activities, in addition to the
real-time duties offloaded to the Xenomai co-kernel. In most cases where
a dual kernel solution applies, there is no requirement for full
preemption (-rt) on the regular linux side though.
>
> Because With RT patch I can choose on menuconfig Preemption Model 5 choices
> (No preempt, Voluntary and low latency , preemptible kernel or fully
> preemptivekernel)
>
> But if I patch only with xenomai I have just 3 choices of preemptive (No
> preempt, Voluntary and low latency)
>
Those choices affect the regular linux kernel behavior only, not
Xenomai. When the Xenomai co-kernel is present, there is no need for
additional preemption models, the linux kernel is inherently preemptible
by Xenomai activities at any time.
> If patch first with RT and after xenomai I have a lot of Hunk message
> (warning and error) but if I Patch first with xenomai and after RT -> no
> problem
>
>
>
> So my question are they compatible together? Or perhaps choosing fully
> preemptive will turn my system unstable.
>
Combining both is possible, and such configuration is actually used by
some projects. However, a combo patch merging preempt-rt and the I-pipe
has to be specifically crafted for the target kernel.
>
>
> My goal is to catch Interruption with a small latency (50-10 µs) with a low
> processor charge
Since there is no one-fits-it-all solution, I would suggest to benchmark
each configuration separately for your use case, and see which one best
fits the bill, taking into account the pros and cons of each approach in
the long run for your project.
>
> Board Arbor card
> <http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
> =1&version=+Default> EmETX-i2900 with ATOM N450
>
>
>
>
>
> Thanks for your future response
>
>
>
>
>
> Kind regards,
>
>
>
> Jean Rodriguez
>
> Ingénieur R&D Informatique
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---
> Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
> http://www.avast.com
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>
--
Philippe.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-17 15:00 [Xenomai] Some Information About compilation Xenomai and RT Patches Jean Rodriguez
[not found] ` <be428e33f9f5482aa36cbc1654ec2db2@EX132MBOX1B.de2.local>
2014-06-20 9:00 ` Philippe Gerum
@ 2014-06-20 9:02 ` Stoidner, Christoph
2014-06-20 11:50 ` Gilles Chanteperdrix
2 siblings, 1 reply; 11+ messages in thread
From: Stoidner, Christoph @ 2014-06-20 9:02 UTC (permalink / raw
To: xenomai@xenomai.org
Hi Jean,
I have merged successfully I-Pipe/Xenomai and Preempt RT patch for Kernel V3.10.18. From my point of view it is working very well. The only part which was a bit of tricky to solve was the kernel's spinlock implementation. This is since I-Pipe as well as Preempt-RT are patching this part of code each with own implementations. As result it is required to replace Preempt RT's default spinlock calls with new wrappers. Within the wrappers you have to decide if Preempt RT's spinlock or I-Pipe's spinlock have to be used at this place.
My pending problem which I hope to solve soon is the fast context switch extension (FCSE) that allows better latency times on ARM9. In "guaranteed" mode it crashs when using addresses above 32MB.
If you are interested in more details feel free to ask.
Regards,
Christoph
________________________________________
Von: Xenomai <xenomai-bounces@xenomai.org> im Auftrag von Jean Rodriguez <j.rodriguez@caustier.com>
Gesendet: Dienstag, 17. Juni 2014 17:00
An: xenomai@xenomai.org
Betreff: [Xenomai] Some Information About compilation Xenomai and RT Patches
Hi guys,
I’m trying to compile kernel 3.8 with the last xenomai source.
I want to know some precisions about preempt option.
Is it useless to patch the kernel with with Xenomai and also with RT patch
from kernel.org?
Because With RT patch I can choose on menuconfig Preemption Model 5 choices
(No preempt, Voluntary and low latency , preemptible kernel or fully
preemptivekernel)
But if I patch only with xenomai I have just 3 choices of preemptive (No
preempt, Voluntary and low latency)
If patch first with RT and after xenomai I have a lot of Hunk message
(warning and error) but if I Patch first with xenomai and after RT -> no
problem
So my question are they compatible together? Or perhaps choosing fully
preemptive will turn my system unstable.
My goal is to catch Interruption with a small latency (50-10 µs) with a low
processor charge
Board Arbor card
<http://www.arbor.com.tw/product/product.aspx?Product_Name=EmETX-i2900&os_id
=1&version=+Default> EmETX-i2900 with ATOM N450
Thanks for your future response
Kind regards,
Jean Rodriguez
Ingénieur R&D Informatique
---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-20 9:02 ` Stoidner, Christoph
@ 2014-06-20 11:50 ` Gilles Chanteperdrix
2014-06-23 9:33 ` Stoidner, Christoph
0 siblings, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2014-06-20 11:50 UTC (permalink / raw
To: Stoidner, Christoph, xenomai@xenomai.org
On 06/20/2014 11:02 AM, Stoidner, Christoph wrote:
> My pending problem which I hope to solve soon is the fast context
> switch extension (FCSE) that allows better latency times on ARM9. In
> "guaranteed" mode it crashs when using addresses above 32MB.
What do you mean it crashes? Normally, an mmap call that would return
addresses above 32MB simply fails, because you can not use addresses
above 32MB in guaranteed mode.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-20 11:50 ` Gilles Chanteperdrix
@ 2014-06-23 9:33 ` Stoidner, Christoph
2014-06-23 9:40 ` Gilles Chanteperdrix
2014-06-23 9:53 ` Gilles Chanteperdrix
0 siblings, 2 replies; 11+ messages in thread
From: Stoidner, Christoph @ 2014-06-23 9:33 UTC (permalink / raw
To: xenomai@xenomai.org
Hi Gilles,
when a userspace application starts it calls the brk() syscall to enlarge it's heap space. In some cases the call leads to an NOMEM error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM error at this place the a segfault exception appears.
It seems as this happens when brk() got an address above some limit, also when the process at all consumes less than 32MB RAM. E.g. busybox shell command "ls" is enough to get the segfault.
Regards,
Christoph
________________________________________
Von: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Gesendet: Freitag, 20. Juni 2014 13:50
An: Stoidner, Christoph; xenomai@xenomai.org
Betreff: Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
On 06/20/2014 11:02 AM, Stoidner, Christoph wrote:
> My pending problem which I hope to solve soon is the fast context
> switch extension (FCSE) that allows better latency times on ARM9. In
> "guaranteed" mode it crashs when using addresses above 32MB.
What do you mean it crashes? Normally, an mmap call that would return
addresses above 32MB simply fails, because you can not use addresses
above 32MB in guaranteed mode.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-23 9:33 ` Stoidner, Christoph
@ 2014-06-23 9:40 ` Gilles Chanteperdrix
2014-06-23 9:53 ` Gilles Chanteperdrix
1 sibling, 0 replies; 11+ messages in thread
From: Gilles Chanteperdrix @ 2014-06-23 9:40 UTC (permalink / raw
To: Stoidner, Christoph, xenomai@xenomai.org
On 06/23/2014 11:33 AM, Stoidner, Christoph wrote:
>
> Hi Gilles,
>
> when a userspace application starts it calls the brk() syscall to
> enlarge it's heap space. In some cases the call leads to an NOMEM
> error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM
> error at this place the a segfault exception appears.
>
> It seems as this happens when brk() got an address above some limit,
> also when the process at all consumes less than 32MB RAM. E.g.
> busybox shell command "ls" is enough to get the segfault.
with the glibc versions I have been testing with the FCSE patch since it
exists, when brk fails, the glibc uses mmap to allocate memory, and
everything continues.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-23 9:33 ` Stoidner, Christoph
2014-06-23 9:40 ` Gilles Chanteperdrix
@ 2014-06-23 9:53 ` Gilles Chanteperdrix
2014-06-23 10:04 ` Stoidner, Christoph
1 sibling, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2014-06-23 9:53 UTC (permalink / raw
To: Stoidner, Christoph, xenomai@xenomai.org
On 06/23/2014 11:33 AM, Stoidner, Christoph wrote:
>
> Hi Gilles,
>
> when a userspace application starts it calls the brk() syscall to
> enlarge it's heap space. In some cases the call leads to an NOMEM
> error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM
> error at this place the a segfault exception appears.
>
> It seems as this happens when brk() got an address above some limit,
> also when the process at all consumes less than 32MB RAM. E.g.
> busybox shell command "ls" is enough to get the segfault.
Could you test the I-pipe git branch ipipe-3.14, unmodified?
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-23 9:53 ` Gilles Chanteperdrix
@ 2014-06-23 10:04 ` Stoidner, Christoph
2014-06-23 23:41 ` Gilles Chanteperdrix
0 siblings, 1 reply; 11+ messages in thread
From: Stoidner, Christoph @ 2014-06-23 10:04 UTC (permalink / raw
To: xenomai@xenomai.org
Original ipipe-3.10.18 without Preempt-RT works without any problem. The problem occurs only in combination of my Preempt-RT merge and enabled FCSE in guaranteed mode.
Since unmodified ipipe-3.10 does not show the problem I assume unmodified ipipe-3.14 also does not show the problem. Or do you think 3.14 brings some more details?
Regards,
Christoph
________________________________________
Von: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Gesendet: Montag, 23. Juni 2014 11:53
An: Stoidner, Christoph; xenomai@xenomai.org
Betreff: Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
On 06/23/2014 11:33 AM, Stoidner, Christoph wrote:
>
> Hi Gilles,
>
> when a userspace application starts it calls the brk() syscall to
> enlarge it's heap space. In some cases the call leads to an NOMEM
> error in fcse_check_mmap_addr(). Since glibc does not handle NOMEM
> error at this place the a segfault exception appears.
>
> It seems as this happens when brk() got an address above some limit,
> also when the process at all consumes less than 32MB RAM. E.g.
> busybox shell command "ls" is enough to get the segfault.
Could you test the I-pipe git branch ipipe-3.14, unmodified?
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-23 10:04 ` Stoidner, Christoph
@ 2014-06-23 23:41 ` Gilles Chanteperdrix
2014-06-24 6:37 ` Gilles Chanteperdrix
0 siblings, 1 reply; 11+ messages in thread
From: Gilles Chanteperdrix @ 2014-06-23 23:41 UTC (permalink / raw
To: Stoidner, Christoph, xenomai@xenomai.org
On 06/23/2014 12:04 PM, Stoidner, Christoph wrote:
>
> Original ipipe-3.10.18 without Preempt-RT works without any problem.
> The problem occurs only in combination of my Preempt-RT merge and
> enabled FCSE in guaranteed mode.
>
> Since unmodified ipipe-3.10 does not show the problem I assume
> unmodified ipipe-3.14 also does not show the problem. Or do you think
> 3.14 brings some more details?
I definitely fixed some FCSE issues in the ipipe-3.14 branch, mostly
when FCSE is enabled without CONFIG_IPIPE. Now if ipipe-3.10.18 has no
issues, whereas mixing Prempt-rt in makes some issues appear, I would
suggest looking carefully at the changes introduced by the preempt-rt
patch with regard to mm handling.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Xenomai] Some Information About compilation Xenomai and RT Patches
2014-06-23 23:41 ` Gilles Chanteperdrix
@ 2014-06-24 6:37 ` Gilles Chanteperdrix
0 siblings, 0 replies; 11+ messages in thread
From: Gilles Chanteperdrix @ 2014-06-24 6:37 UTC (permalink / raw
To: Stoidner, Christoph, xenomai@xenomai.org
On 06/24/2014 01:41 AM, Gilles Chanteperdrix wrote:
> On 06/23/2014 12:04 PM, Stoidner, Christoph wrote:
>>
>> Original ipipe-3.10.18 without Preempt-RT works without any problem.
>> The problem occurs only in combination of my Preempt-RT merge and
>> enabled FCSE in guaranteed mode.
>>
>> Since unmodified ipipe-3.10 does not show the problem I assume
>> unmodified ipipe-3.14 also does not show the problem. Or do you think
>> 3.14 brings some more details?
>
> I definitely fixed some FCSE issues in the ipipe-3.14 branch, mostly
> when FCSE is enabled without CONFIG_IPIPE. Now if ipipe-3.10.18 has no
> issues, whereas mixing Prempt-rt in makes some issues appear, I would
> suggest looking carefully at the changes introduced by the preempt-rt
> patch with regard to mm handling.
>
Something else, if what you had trouble with is the spinlock merge, you
should maybe double check that ipipe_spinlocks work as expected, because
the FCSE code uses an ipipe_spinlock, and if this spinlock ends up as a
sleeping spinlock, things could get messy.
--
Gilles.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2014-06-24 6:37 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-06-17 15:00 [Xenomai] Some Information About compilation Xenomai and RT Patches Jean Rodriguez
[not found] ` <be428e33f9f5482aa36cbc1654ec2db2@EX132MBOX1B.de2.local>
2014-06-20 8:50 ` Stoidner, Christoph
2014-06-20 9:00 ` Philippe Gerum
2014-06-20 9:02 ` Stoidner, Christoph
2014-06-20 11:50 ` Gilles Chanteperdrix
2014-06-23 9:33 ` Stoidner, Christoph
2014-06-23 9:40 ` Gilles Chanteperdrix
2014-06-23 9:53 ` Gilles Chanteperdrix
2014-06-23 10:04 ` Stoidner, Christoph
2014-06-23 23:41 ` Gilles Chanteperdrix
2014-06-24 6:37 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.