[Xenomai] a question about ADEOS

[Xenomai] a question about ADEOS

[ali hagigat]

I know that adeos project presents an API set. It means some functions
mostly which start with adeos_.
Why adeos patch does not add them to the linux kernel? Those functions
are used for creating domains as far as I know.
So maybe they are not needed for xenomai, is that true? So in Xenomain
project all the software components have the same domain?

My another question is about i-pipe concept of ADEOS. What is that?
can any one explain it? Is it a queue?

Thank you all for reading this message.

Re: [Xenomai] a question about ADEOS

[Chris Stone]

There is an excellent article explaining ADEOS at:

http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf 

Cheers,
   Chris.

-----Original Message-----
From: xenomai-bounces@xenomai.org [mailto:xenomai-bounces@xenomai.org] On Behalf Of ali hagigat
Sent: Wednesday, May 30, 2012 10:36 AM
To: xenomai@xenomai.org
Subject: [Xenomai] a question about ADEOS

I know that adeos project presents an API set. It means some functions mostly which start with adeos_.
Why adeos patch does not add them to the linux kernel? Those functions are used for creating domains as far as I know.
So maybe they are not needed for xenomai, is that true? So in Xenomain project all the software components have the same domain?

My another question is about i-pipe concept of ADEOS. What is that?
can any one explain it? Is it a queue?

Thank you all for reading this message.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] a question about ADEOS

[Philippe Gerum]

On 05/30/2012 04:35 PM, ali hagigat wrote:
> I know that adeos project presents an API set. It means some functions
> mostly which start with adeos_.
> Why adeos patch does not add them to the linux kernel?

I don't understand your question.

Those functions
> are used for creating domains as far as I know.
> So maybe they are not needed for xenomai, is that true?

No, we do use them to create a real-time domain where Xenomai lives.

  So in Xenomain
> project all the software components have the same domain?
>

No.

> My another question is about i-pipe concept of ADEOS. What is that?
> can any one explain it? Is it a queue?
>

I-pipe means interrupt pipeline, i.e. what "Adeos" implements at its 
core. Adeos == I-pipe == interrupt pipeline, same thing.

> Thank you all for reading this message.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai
>


-- 
Philippe.

Re: [Xenomai] a question about ADEOS

[Gilles Chanteperdrix]

On 05/30/2012 05:08 PM, Philippe Gerum wrote:
> On 05/30/2012 04:35 PM, ali hagigat wrote:
>> I know that adeos project presents an API set. It means some functions
>> mostly which start with adeos_.
>> Why adeos patch does not add them to the linux kernel?
> 
> I don't understand your question.

If the question is: why is not Adeos integrated in the mainline kernel ?
the answer is that the kernel community has chosen another solution to
enable real-time, and is not interested in integrating the Adeos patch.

-- 
					    Gilles.

Re: [Xenomai] a question about ADEOS

[Lennart Sorensen]

On Wed, May 30, 2012 at 05:27:15PM +0200, Gilles Chanteperdrix wrote:
> If the question is: why is not Adeos integrated in the mainline kernel ?
> the answer is that the kernel community has chosen another solution to
> enable real-time, and is not interested in integrating the Adeos patch.

As a user of adeos and xenomai, I do look forward to the day xenomai works
with the other option so that a single scheduler can handle everything
and give much better control over things.  But there is much work to be
done before that happens as far as I can tell.

ipipe is an interesting solution, although not a particularly nice one.

-- 
Len Sorensen

Re: [Xenomai] a question about ADEOS

[Gilles Chanteperdrix]

On 05/30/2012 05:57 PM, Lennart Sorensen wrote:
> On Wed, May 30, 2012 at 05:27:15PM +0200, Gilles Chanteperdrix wrote:
>> If the question is: why is not Adeos integrated in the mainline kernel ?
>> the answer is that the kernel community has chosen another solution to
>> enable real-time, and is not interested in integrating the Adeos patch.
> 
> As a user of adeos and xenomai, I do look forward to the day xenomai works
> with the other option so that a single scheduler can handle everything
> and give much better control over things.  But there is much work to be
> done before that happens as far as I can tell.

You can see for yourself with the xenomai-forge branch. It is already in
a usable state. I do not buy the scheduler argument: the linux scheduler
does pretty much the same separation between real-time and non real-time
tasks as the separation which happens with xenomai. And the scheduler
for real-time tasks is simple, it does not need to know much more than
the tasks priorities, I do not see what more you would like to control.

> 
> ipipe is an interesting solution, although not a particularly nice one.
> 

It depends on your definition of "nice". It ends up being a relatively
simple implementation which provides good latency results.

-- 
					    Gilles.

Re: [Xenomai] a question about ADEOS

[Chris Stone]

Rest assured there are many users of Adeos/Xenomai that believe it is a much more elegant/reliable/efficient/simple 
choice for real time in Linux. The linux scheduler is a mammoth beast that takes far too long to run. One of 
the finest advantages of Adeos/Xenomai is that you get to preempt the mammoth beast with a simple and fast 
real time scheduler. PREEMPT-RT is an interesting solution, but is not a particularly well thought out one. 
PREEMPT-RT is unstable and slow, which is why it STILL isn't fully accepted into the native kernel yet, after at 
least 8 years of trying to get it in. In another five years, PREEMPT_RT will make Xenomai better by reducing 
worst case latency when an application switches to secondary mode, but it will never replace Adeos/Xenomai. 

Cheers,
  Chris.

-----Original Message-----
From: xenomai-bounces@xenomai.org [mailto:xenomai-bounces@xenomai.org] On Behalf Of Lennart Sorensen
Sent: Wednesday, May 30, 2012 11:58 AM
To: Gilles Chanteperdrix
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai] a question about ADEOS

On Wed, May 30, 2012 at 05:27:15PM +0200, Gilles Chanteperdrix wrote:
> If the question is: why is not Adeos integrated in the mainline kernel ?
> the answer is that the kernel community has chosen another solution to 
> enable real-time, and is not interested in integrating the Adeos patch.

As a user of adeos and xenomai, I do look forward to the day xenomai works with the other option so that a single scheduler can handle everything and give much better control over things.  But there is much work to be done before that happens as far as I can tell.

ipipe is an interesting solution, although not a particularly nice one.

--
Len Sorensen

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] a question about ADEOS

[Lennart Sorensen]

On Wed, May 30, 2012 at 06:53:00PM +0200, Gilles Chanteperdrix wrote:
> You can see for yourself with the xenomai-forge branch. It is already in
> a usable state. I do not buy the scheduler argument: the linux scheduler
> does pretty much the same separation between real-time and non real-time
> tasks as the separation which happens with xenomai. And the scheduler
> for real-time tasks is simple, it does not need to know much more than
> the tasks priorities, I do not see what more you would like to control.

I have been looking at it a bit.  Maybe I should give it a try soon.

Based on what I have seen for the real time linux patches, you can set
priorities of kernel threads as well, which would be nice at times.

Perhaps our use is just not normal, in that we ahve an application that
uses realtime, but has some work to do that is very low priority (and
not in need of realtime) but needs to share memory space and resources
with the stuff that does have to be real time, which makes it hard to
make linux tasks run before the less important stuff in the xenomai
application runs.  It works using an idle priority thread, but it would
be nice to have better control of it, which I hope the rt patches for
linux would allow.  Maybe I am hoping for too much.

Is there anywhere that has the current status of the xenomai-forge branch?
Like what is expected to work already and what isn't working.

> It depends on your definition of "nice". It ends up being a relatively
> simple implementation which provides good latency results.

That is true.  It does end up easliy making linux unhappy though.
Of course that is always going to be an issue when you want realtime
for some things.

-- 
Len Sorensen

Re: [Xenomai] a question about ADEOS

[Lennart Sorensen]

On Wed, May 30, 2012 at 05:32:48PM +0000, Chris Stone wrote:
> Rest assured there are many users of Adeos/Xenomai that believe it is a much more elegant/reliable/efficient/simple 
> choice for real time in Linux. The linux scheduler is a mammoth beast that takes far too long to run. One of 
> the finest advantages of Adeos/Xenomai is that you get to preempt the mammoth beast with a simple and fast 
> real time scheduler. PREEMPT-RT is an interesting solution, but is not a particularly well thought out one. 
> PREEMPT-RT is unstable and slow, which is why it STILL isn't fully accepted into the native kernel yet, after at 
> least 8 years of trying to get it in. In another five years, PREEMPT_RT will make Xenomai better by reducing 
> worst case latency when an application switches to secondary mode, but it will never replace Adeos/Xenomai. 

Hmm, that's too bad.  Well maybe we will end up having to stick with
ipipe then.

-- 
Len Sorensen

Re: [Xenomai] a question about ADEOS

[Gilles Chanteperdrix]

On 05/30/2012 07:57 PM, Lennart Sorensen wrote:
> On Wed, May 30, 2012 at 06:53:00PM +0200, Gilles Chanteperdrix wrote:
>> You can see for yourself with the xenomai-forge branch. It is already in
>> a usable state. I do not buy the scheduler argument: the linux scheduler
>> does pretty much the same separation between real-time and non real-time
>> tasks as the separation which happens with xenomai. And the scheduler
>> for real-time tasks is simple, it does not need to know much more than
>> the tasks priorities, I do not see what more you would like to control.
> 
> I have been looking at it a bit.  Maybe I should give it a try soon.
> 
> Based on what I have seen for the real time linux patches, you can set
> priorities of kernel threads as well, which would be nice at times.

I am not sure to get what you mean, Xenomai kernel threads priority are
configurable as well.

> 
> Perhaps our use is just not normal, in that we ahve an application that
> uses realtime, but has some work to do that is very low priority (and
> not in need of realtime) but needs to share memory space and resources
> with the stuff that does have to be real time, which makes it hard to
> make linux tasks run before the less important stuff in the xenomai
> application runs.  It works using an idle priority thread, but it would
> be nice to have better control of it, which I hope the rt patches for
> linux would allow.  Maybe I am hoping for too much.

Starting with Xenomai 2.6, if you create a xenomai thread with
scheduling policy SCHED_OTHER (and priority 0), it returns to secondary
mode as soon as possible, so, is handled by Linux scheduler as a low
priority thread most of the time. If this task is cpu bound, you
probably can even decrease its time slices by using the renice() service.

-- 
					    Gilles.

Re: [Xenomai] a question about ADEOS

[Gilles Chanteperdrix]

On 05/30/2012 07:32 PM, Chris Stone wrote:
> Rest assured there are many users of Adeos/Xenomai that believe it is
> a much more elegant/reliable/efficient/simple choice for real time in
> Linux. The linux scheduler is a mammoth beast that takes far too long
> to run. One of the finest advantages of Adeos/Xenomai is that you get
> to preempt the mammoth beast with a simple and fast real time
> scheduler. PREEMPT-RT is an interesting solution, but is not a
> particularly well thought out one. PREEMPT-RT is unstable and slow,
> which is why it STILL isn't fully accepted into the native kernel
> yet, after at least 8 years of trying to get it in. In another five
> years, PREEMPT_RT will make Xenomai better by reducing worst case
> latency when an application switches to secondary mode, but it will
> never replace Adeos/Xenomai.

Do not get me wrong, I have no issue with preempt_rt being the solution
chosen by the kernel community as the solution for real-time. I would
even tend to be a bit less extreme than you, calling room for
improvement the "mammoth beast" and the slow kernel.

As for the stability, the OSADL published some results:
https://www.osadl.org/Single-View.111+M59e3481cdfe.0.html

which show that the preempt_rt patched kernels are able to run for
sustained period of times under load without crashes, at least on the
tested platforms. This is not so different of the way we validate the
I-pipe patch.

I was merely trying to answer the question "why is not adeos integrated
to the linux kernel?".
-- 
                                                                Gilles.

Re: [Xenomai] a question about ADEOS

[Chris Stone]

> Do not get me wrong, I have no issue with preempt_rt being the solution
> chosen by the kernel community as the solution for real-time. I would
> even tend to be a bit less extreme than you, calling room for
> improvement the "mammoth beast" and the slow kernel.

Agreed, the Linux scheduler is pretty good. My point was simply that in hard
real time, the simpler the scheduler the better. I have a fundamental issue
with trying to make the Linux scheduler into one size fits all. This is why
I believe Xenomai to be a better solution. I am running a 1ms periodic task
on Xenomai, which was impossible on PREEMPT-RT because the scheduler ate a
significant portion of the 1ms interval.

> 
> As for the stability, the OSADL published some results:
> https://www.osadl.org/Single-View.111+M59e3481cdfe.0.html

The problem with these kinds of stability tests is that they are artificial. They
don't reflect real world applications, which are orders of magnitude more complicated.
It is the complicated applications that turn up the problems. We have had 
stability issues with PREEMPT-RT on the MX35 platform that don't turn up in the 
OSADL tests. When I turn off PREEMPT-RT the application runs fine, when I turn it on, 
the kernel hangs within 8 hours. The Xenomai solution is actually a lot older than 
PREEMPT_RT and is therefore, much more tested and stable. Code is like wine, it gets
better with age, although it can eventually turn into vinegar, so you have to use it
while it is still good. Xenomai is a pretty fine wine right now. I solved my stability problems 
with PREEMPT-RT by switching to Xenomai.

As with you, I am not trying to be political by saying PREEMPT-RT is bad and Xenomai is
good. I have no problem with PREEMPT-RT as the chosen kernel real time solution, and I am 
sure, with a little more time in the barrel, it will improve. The great thing about Linux is 
that there are always multiple solutions, so we are not tied to what the official kernel is 
capable of. There is no vendor lock in. I am a software engineer doing real work on real 
world applications that are shipping to customers. So, I have to be practical, which leads 
me to choose seasoned solutions. PREEMPT-RT will be more seasoned in about five years. Despite
the value that PREEMPT-RT adds to the kernel there will always be a niche for Xenomai, such
as special situations where you want to override the complexity of the Linux kernel.

Cheers,
   Chris.

Re: [Xenomai] a question about ADEOS

[ali hagigat]

Much appreciates for the replies.

if you look at the following page:

http://home.gna.org/adeos/doc/api/globals.html

You can see some functions like adeos_alloc_irq() or adeos_alloc_ptdkey().

But if you patch the linux kernel with the adeos patch, these
functions do not exist.



On Wed, May 30, 2012 at 7:38 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 05/30/2012 04:35 PM, ali hagigat wrote:
>>
>> I know that adeos project presents an API set. It means some functions
>> mostly which start with adeos_.
>> Why adeos patch does not add them to the linux kernel?
>
>
> I don't understand your question.
>
>
> Those functions
>>
>> are used for creating domains as far as I know.
>> So maybe they are not needed for xenomai, is that true?
>
>
> No, we do use them to create a real-time domain where Xenomai lives.
>
>

Re: [Xenomai] a question about ADEOS

[Philippe Gerum]

On 06/05/2012 08:26 AM, ali hagigat wrote:
> Much appreciates for the replies.
>
> if you look at the following page:
>
> http://home.gna.org/adeos/doc/api/globals.html
>
> You can see some functions like adeos_alloc_irq() or adeos_alloc_ptdkey().
>
> But if you patch the linux kernel with the adeos patch, these
> functions do not exist.
>

This doc is out of date. There is no doc on the current API.

>
>
> On Wed, May 30, 2012 at 7:38 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>> On 05/30/2012 04:35 PM, ali hagigat wrote:
>>>
>>> I know that adeos project presents an API set. It means some functions
>>> mostly which start with adeos_.
>>> Why adeos patch does not add them to the linux kernel?
>>
>>
>> I don't understand your question.
>>
>>
>> Those functions
>>>
>>> are used for creating domains as far as I know.
>>> So maybe they are not needed for xenomai, is that true?
>>
>>
>> No, we do use them to create a real-time domain where Xenomai lives.
>>
>>
>


-- 
Philippe.

Re: [Xenomai] a question about ADEOS

[Philippe Gerum]

On 06/05/2012 08:26 AM, ali hagigat wrote:
> Much appreciates for the replies.
>
> if you look at the following page:
>
> http://home.gna.org/adeos/doc/api/globals.html

Btw, that homepage is dead as well. Access to it has been disabled from 
gna.org/projects/adeos some time ago. All info there is at best of 
archaeological interest.

The current information about Xenomai and the interrupt pipeline is 
available from xenomai.org.

>
> You can see some functions like adeos_alloc_irq() or adeos_alloc_ptdkey().
>
> But if you patch the linux kernel with the adeos patch, these
> functions do not exist.
>
>
>
> On Wed, May 30, 2012 at 7:38 PM, Philippe Gerum<rpm@xenomai.org>  wrote:
>> On 05/30/2012 04:35 PM, ali hagigat wrote:
>>>
>>> I know that adeos project presents an API set. It means some functions
>>> mostly which start with adeos_.
>>> Why adeos patch does not add them to the linux kernel?
>>
>>
>> I don't understand your question.
>>
>>
>> Those functions
>>>
>>> are used for creating domains as far as I know.
>>> So maybe they are not needed for xenomai, is that true?
>>
>>
>> No, we do use them to create a real-time domain where Xenomai lives.
>>
>>
>


-- 
Philippe.

[Xenomai] ftrace

[dietmar.schindler]

A Xenomai-patched 2.6.34 kernel (ppc GNU/Linux) crashes when issuing the command

echo function >/sys/kernel/debug/tracing/current_tracer

(sometimes displaying NIP in a function from "source/kernel/trace/ring_buffer.c", sometimes with no message).

Are Xenomai and ftrace incompatible?

--
Best Regards,
Dietmar
________________________________________
manroland web systems GmbH -- Managing Director: Uwe Lüders
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No. 26816 -- VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, please notify us immediately via info@manroland-web.com, then delete this eMail.

- Please consider your environmental responsibility before printing this eMail
________________________________________

Re: [Xenomai] ftrace

[Philippe Gerum]

On 06/05/2012 10:06 AM, dietmar.schindler@manroland.com wrote:
> A Xenomai-patched 2.6.34 kernel (ppc GNU/Linux) crashes when issuing the command
>
> echo function>/sys/kernel/debug/tracing/current_tracer
>
> (sometimes displaying NIP in a function from "source/kernel/trace/ring_buffer.c", sometimes with no message).
>
> Are Xenomai and ftrace incompatible?
>

No, but some ftrace bits have to be made pipeline-aware. The generic 
ones should be, but some powerpc-specific fix ups might be missing. I'm 
not using/testing ftrace routinely when upgrading patches. Also, 2.6.34 
is fairly old.

> --
> Best Regards,
> Dietmar
> ________________________________________
> manroland web systems GmbH -- Managing Director: Uwe Lüders
> Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No. 26816 -- VAT: DE281389840
>
> Confidentiality note:
> This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, please notify us immediately via info@manroland-web.com, then delete this eMail.
>
> - Please consider your environmental responsibility before printing this eMail
> ________________________________________
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai


-- 
Philippe.

Re: [Xenomai] ftrace

[dietmar.schindler]

> From: Philippe Gerum [mailto:rpm@xenomai.org]
> Sent: Tuesday, June 05, 2012 10:17 AM
>
> On 06/05/2012 10:06 AM, dietmar.schindler@manroland.com wrote:
> > A Xenomai-patched 2.6.34 kernel (ppc GNU/Linux) crashes when issuing the
> command
> >
> > echo function>/sys/kernel/debug/tracing/current_tracer
> >
> > (sometimes displaying NIP in a function from
> "source/kernel/trace/ring_buffer.c", sometimes with no message).
> >
> > Are Xenomai and ftrace incompatible?
> >
>
> No, but some ftrace bits have to be made pipeline-aware. The generic
> ones should be, but some powerpc-specific fix ups might be missing. I'm
> not using/testing ftrace routinely when upgrading patches. Also, 2.6.34
> is fairly old.

http://www.xenomai.org/index.php/I-pipe:Tracer#Configuration says: "Ftrace's function and graph tracers themselves are still not usable over I-pipe kernels, latest I-pipe will prevent conflicting use."

I'm confused - I can't gather from this whether the Function Tracer might work or can't possibly work.

--
Best Regards,
Dietmar
________________________________________
manroland web systems GmbH -- Managing Director: Uwe Lüders
Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No. 26816 -- VAT: DE281389840

Confidentiality note:
This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, please notify us immediately via info@manroland-web.com, then delete this eMail.

- Please consider your environmental responsibility before printing this eMail
________________________________________

Re: [Xenomai] ftrace

[Wolfgang Grandegger]

Hi Dietmar,

On 06/13/2012 11:32 AM, dietmar.schindler@manroland.com wrote:
>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>> Sent: Tuesday, June 05, 2012 10:17 AM
>>
>> On 06/05/2012 10:06 AM, dietmar.schindler@manroland.com wrote:
>>> A Xenomai-patched 2.6.34 kernel (ppc GNU/Linux) crashes when issuing the
>> command
>>>
>>> echo function>/sys/kernel/debug/tracing/current_tracer
>>>
>>> (sometimes displaying NIP in a function from
>> "source/kernel/trace/ring_buffer.c", sometimes with no message).
>>>
>>> Are Xenomai and ftrace incompatible?
>>>
>>
>> No, but some ftrace bits have to be made pipeline-aware. The generic
>> ones should be, but some powerpc-specific fix ups might be missing. I'm
>> not using/testing ftrace routinely when upgrading patches. Also, 2.6.34
>> is fairly old.
> 
> http://www.xenomai.org/index.php/I-pipe:Tracer#Configuration says: "Ftrace's function and graph tracers themselves are still not usable over I-pipe kernels, latest I-pipe will prevent conflicting use."
> 
> I'm confused - I can't gather from this whether the Function Tracer might work or can't possibly work.

If the iPipe-Tracer is enabled in the Kernel, you can't use Linux ftrace
via "/sys/kernel/debug/tracing" any more. I checked that for PowerPC up
to Linux 3.2.1. In contrast, the iPipe-Tracer is controlled by files in
/proc/ipipe/trace and that works. For your kernel version you need the
attached two patches, though.

Wolfgang.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adeos-ipipe-2.6.34.4-powerpc-2.10-05-tracer.patch
Type: text/x-diff
Size: 592 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120613/c8f10542/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: adeos-ipipe-2.6.34.4-powerpc-2.10-05-tsc2us.patch
Type: text/x-diff
Size: 1279 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120613/c8f10542/attachment-0001.patch>

Re: [Xenomai] ftrace

[Wolfgang Grandegger]

On 06/13/2012 11:32 AM, dietmar.schindler@manroland.com wrote:
>> From: Philippe Gerum [mailto:rpm@xenomai.org]
>> Sent: Tuesday, June 05, 2012 10:17 AM
>>
>> On 06/05/2012 10:06 AM, dietmar.schindler@manroland.com wrote:
>>> A Xenomai-patched 2.6.34 kernel (ppc GNU/Linux) crashes when issuing the
>> command
>>>
>>> echo function>/sys/kernel/debug/tracing/current_tracer
>>>
>>> (sometimes displaying NIP in a function from
>> "source/kernel/trace/ring_buffer.c", sometimes with no message).
>>>
>>> Are Xenomai and ftrace incompatible?
>>>
>>
>> No, but some ftrace bits have to be made pipeline-aware. The generic
>> ones should be, but some powerpc-specific fix ups might be missing. I'm
>> not using/testing ftrace routinely when upgrading patches. Also, 2.6.34
>> is fairly old.
> 
> http://www.xenomai.org/index.php/I-pipe:Tracer#Configuration says: "Ftrace's function and graph tracers themselves are still not usable over I-pipe kernels, latest I-pipe will prevent conflicting use."
> 
> I'm confused - I can't gather from this whether the Function Tracer might work or can't possibly work.
> 
> --
> Best Regards,
> Dietmar
> ________________________________________
> manroland web systems GmbH -- Managing Director: Uwe Lüders
> Registered Office: Augsburg -- Trade Register: AG Augsburg -- HRB-No. 26816 -- VAT: DE281389840
> 
> Confidentiality note:
> This eMail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you have received this eMail in error, please notify us immediately via info@manroland-web.com, then delete this eMail.
> 
> - Please consider your environmental responsibility before printing this eMail
> ________________________________________

You should try to get rid of this useless message when you send messages
to a public mailing list.

Wolfgang