Greetings All,
We note the QorlQ processors, and the Freescale e500 PowerPC architecture
is not on the list of Supported Architectures at
http://www.xenomai.org/index.php/Embedded_Device_Support.
On the other hand, that document states that the QorIQ P2020
is supported under "Supported Evaluatio
To: Gilles Chanteperdrix ; makarand pradhan
Cc: "xenomai-help@gna.org"
Sent: Tuesday, November 8, 2011 9:22 AM
Subject: RE: [Xenomai-help] Is there Xenomai support for the Freescale P1020
processor?
Hi Gilles,
It is not a pressure and it is sad it looked that way to you.
We don&
pressuring anyone.
I'm new to the list and hence was a bit unsure. My sincere apologies.
Rgds,
Makarand.
From: Gilles Chanteperdrix
To: Michael Pustylnik
Cc: makarand pradhan ; "xenomai-help@gna.org"
Sent: Tuesday, November 8, 2011 9:50 AM
Subject: Re
On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote:
Xenomai uses the same interrupt numbers as linux. But rt_intr_create is
deprecated in user-space, you should instead write a driver using the
rtdm skin. The enable bit is handled by xenomai when you request the irq
at xenomai level.
Hi Gilles,
Thanks.
On 23/12/11 10:53 AM, Gilles Chanteperdrix wrote:
On 12/23/2011 04:26 PM, Makarand Pradhan wrote:
On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote:
Xenomai uses the same interrupt numbers as linux. But rt_intr_create is
deprecated in user-space, you should instead write a driver using
Hi,
I am running kernel 3.0.0, xenomai: 2.6, powerpc 8360.
I am noticing an issue while using the auto relax feature related to
mutexes. I am using nested mutexes. The code is attached to this email.
The problem is that I am not relaxing after a RT thread grabs and
releases a mutex. On furth
mux in HP
Mux held by Task2
Release complete
bP: 0, cp: 0, mode: 1
Acquire complete
Release complete
bP: 0, cp: 0, mode: 1
Acquire complete
Rgds,
Mak.
On 10/01/12 10:11 AM, Philippe Gerum wrote:
On 01/09/2012 09:50 PM, Makarand Pradhan wrote:
Hi,
I am running kernel 3.0.0, xenomai: 2.6, powerp
1
Spawning: tasks
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
^C
Rgds,
Mak.
On 10/01/12 10:26 AM, Makarand Pradhan wrote:
Hi Phillippe,
You are right. Task 1 requires to be started with
se in kernel. Will try to
check it out.
Rgds,
Mak.
On 10/01/12 10:42 AM, Philippe Gerum wrote:
On 01/10/2012 04:40 PM, Philippe Gerum wrote:
On 01/10/2012 04:40 PM, Makarand Pradhan wrote:
Another point:
"These are fast mutexes, the thread does not have to jump to kernel space
unless th
rt_task_set_priority. I think this would fix that problem as well.
Will test the patch and get back with the results.
Thanks and Rgds,
Mak.
On 10/01/12 01:08 PM, Philippe Gerum wrote:
On 01/10/2012 04:51 PM, Makarand Pradhan wrote:
Based on my testing, it is noted that the rescnt is not released when
task1 gets
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Grabbing mux in HP
Mux held by Task2
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
Release complete
bP: 0, cp: 0, mode: 0
Acquire complete
^C
root@ruggedcom:~#
On 10/01/12 01:39 PM, Makarand Pradhan wrote:
Hi Phillipe,
A bit surprised
read, XNOTHER);
+ }
Setting XNOTHER in rt_task_set_priority does not look appropriate. I
believe the right place is in the xnpod_set_thread_schedparam.
Would highly appreciate your views.
Rgds,
Mak
On 10/01/12 02:10 PM, Makarand Pradhan wrote:
The patch does work. Thanks.
Will it be availabl
rd to your opinions.
Rgds,
Mak.
On 19/01/12 06:25 AM, Philippe Gerum wrote:
On 01/18/2012 11:41 PM, Makarand Pradhan wrote:
Hi,
Another problem was encountered with rescnt related to nested mutexes.
This time the rescnt is not incrementing because the XNOTHER bit is not
set, causing a SIGDEB
he
base priority is adjusted in the kernel.
I have tried to explain the scenario again in my last email.
Your inputs will be highly appreciated.
Rgds,
Mak
On 19/01/12 07:29 AM, Gilles Chanteperdrix wrote:
On 01/19/2012 12:25 PM, Philippe Gerum wrote:
On 01/18/2012 11:41 PM, Makarand Pradhan
t shortly.
Rgds,
Mak
On 19/01/12 10:49 AM, Philippe Gerum wrote:
On 01/19/2012 04:22 PM, Makarand Pradhan wrote:
Hi Philippe,
I think I may have not communicated the scenario properly. I am not
trying to control the priorities from user space during resource
contention. That is left to the kerne
The attached c file should get you a SIGXCPU/SIGDEBUG revealing the bug
that I am talking about.
Rgds,
Mak.
On 19/01/12 11:22 AM, Makarand Pradhan wrote:
Hi,
The scenario is:
Start task prio 0
Set priority 85
Set priority 0
get_mutex<-- rescnt not incremented as XNOTHER is not
ewhere
Release mutex <-- Sends a SIGDEBUG/SIGXCPU
Would highly appreciate your opinion. Do you feel that there is a
genuine issue out here?
Rgds,
Mak.
On 19/01/12 11:39 AM, Makarand Pradhan wrote:
The attached c file should get you a SIGXCPU/SIGDEBUG revealing the bug
that I am talking abo
Hi,
I am trying to get an ipipe trace and need help to get it working.
I am using Xenomai 2.6 with linux 3.0.0.
The kernel is compiled with following config parameters:
CONFIG_IPIPE_DEBUG=y
CONFIG_IPIPE_DEBUG_CONTEXT=y
CONFIG_IPIPE_DEBUG_INTERNAL=y
CONFIG_IPIPE_TRACE=y
CONFIG_IPIPE_TRACE_ENABL
invoked?
Thanks and Rgds,
Mak.
On 01/03/12 02:38 PM, Gilles Chanteperdrix wrote:
On 03/01/2012 08:20 PM, Makarand Pradhan wrote:
Hi,
I am trying to get an ipipe trace and need help to get it working.
I am using Xenomai 2.6 with linux 3.0.0.
The kernel is compiled with following config
Thanks Gilles.
That was very helpful. I can now see the intr handlers after increasing
the back_trace_points to 5000.
Rgds,
Mak.
On 01/03/12 03:28 PM, Gilles Chanteperdrix wrote:
On 03/01/2012 09:02 PM, Makarand Pradhan wrote:
Thanks Gilles for your prompt response.
Yes. I am aware
Hi Philippe,
On 28/03/12 12:17 PM, Philippe Gerum wrote:
The log says your code wants to control when the IRQ is enabled again,
by calling rt_intr_enable() from userland. I guess you are setting
I_NOAUTOENA too. Correct?
That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the
le
On 28/03/12 02:23 PM, Makarand Pradhan wrote:
Hi Philippe,
On 28/03/12 12:17 PM, Philippe Gerum wrote:
The log says your code wants to control when the IRQ is enabled again,
by calling rt_intr_enable() from userland. I guess you are setting
I_NOAUTOENA too. Correct?
That is correct. I_NOAUTOE
Hi,
There has been a thread on this topic in the past:
https://mail.gna.org/public/xenomai-help/2009-08/msg00023.html
A quick background: We get the alignment exception, as we pass
-fpack-struct option to gcc and some data in structures is misaligned.
I have been testing the patch on Linux 3
Thanks Philippe. That helps.
Rgds,
Makarand.
On 01/05/12 03:45 AM, Philippe Gerum wrote:
On 04/30/2012 07:55 PM, Makarand Pradhan wrote:
Hi,
There has been a thread on this topic in the past:
https://mail.gna.org/public/xenomai-help/2009-08/msg00023.html
A quick background: We get the
24 matches
Mail list logo
