Hi Gilles,
i found in my trace the function 'xnthread_timeout_handler' that is
called in the code where there is the problem.
In xenomai there is a topic about that function. ( [Xenomai-core] [BUG?]
stalled xeno domain
http://www.opensubscriber.com/messages/xenomai-core@gna.org/39.html )
Do
On 04/12/2012 12:12 PM, Roberto Bielli wrote:
Hi Gilles,
i found in my trace the function 'xnthread_timeout_handler' that is
called in the code where there is the problem.
In xenomai there is a topic about that function. ( [Xenomai-core] [BUG?]
stalled xeno domain
Hi Gilles,
i try your workaround but nothing is changed.
I make another test. I try to comment out all the content of
mxc_mask_irq() but the result is the same.
(the mxc_mask_irq is used also for acking interrupts but is not correct
why it doesn't write in the processor manual)
Do you know if
On 04/11/2012 08:59 AM, Roberto Bielli wrote:
Hi Gilles,
i try your workaround but nothing is changed.
I make another test. I try to comment out all the content of
mxc_mask_irq() but the result is the same.
(the mxc_mask_irq is used also for acking interrupts but is not correct
why it
On 04/11/2012 08:59 AM, Roberto Bielli wrote:
Hi Gilles,
i try your workaround but nothing is changed.
I make another test. I try to comment out all the content of
mxc_mask_irq() but the result is the same.
(the mxc_mask_irq is used also for acking interrupts but is not correct
why it
Hi Gilles,
i learned the ipipe trace that i send you but i don't unserstand why i
have three timer reprogramming in few useconds.
Can you explain me the behaviour ?
Il 08/04/2012 00:17, Gilles Chanteperdrix ha scritto:
On 04/06/2012 06:59 PM, Roberto Bielli wrote:
Hi Gilles,
i made all
On 04/10/2012 10:18 AM, Roberto Bielli wrote:
Hi Gilles,
i learned the ipipe trace that i send you but i don't unserstand why i
have three timer reprogramming in few useconds.
Can you explain me the behaviour ?
Can you resend the trace and give us the time where this happens?
Anyway, the
Hi Gilles,
I don't find the end of last __ipipe_grab_irq in the trace that i send you.
Is it correct ?
Il 08/04/2012 00:17, Gilles Chanteperdrix ha scritto:
On 04/06/2012 06:59 PM, Roberto Bielli wrote:
Hi Gilles,
i made all your modifies and re-read all corect register but the problem
is
On 04/10/2012 10:43 AM, Roberto Bielli wrote:
Hi Gilles,
I don't find the end of last __ipipe_grab_irq in the trace that i send you.
Is it correct ?
Yes, because the timer interrupt reschedules and wakes up the periodic
task. I had a look at the timer programming events, it is true that the
Hi Gilles,
i look at the processor errata but for the imx25 there are no errata
elements on timer.
I see that tsc uses the same timer.
Does xenomai use the tsc for the next timer period ?
Il 10/04/2012 10:45, Gilles Chanteperdrix ha scritto:
On 04/10/2012 10:43 AM, Roberto Bielli wrote:
On 04/10/2012 10:58 AM, Roberto Bielli wrote:
Hi Gilles,
i look at the processor errata but for the imx25 there are no errata
elements on timer.
I see that tsc uses the same timer.
Does xenomai use the tsc for the next timer period ?
If you look at the trace, you will see that with the
On 04/10/2012 10:58 AM, Roberto Bielli wrote:
Hi Gilles,
i look at the processor errata but for the imx25 there are no errata
elements on timer.
It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
support imx25.
The I-pipe support has not been written for imx25, so, it
On 04/10/2012 11:06 AM, Gilles Chanteperdrix wrote:
On 04/10/2012 10:58 AM, Roberto Bielli wrote:
Hi Gilles,
i look at the processor errata but for the imx25 there are no errata
elements on timer.
It is strange that you use linux 2.6.31 on imx25: linux 2.6.31 does not
support imx25.
Hi Gilles,
the steps for supporting imx25 have been:
1. We buy a board with imx25
2. Our supplier made the porting of linux 2.6.31 freescale with imx25
3. we put a xenomai 2.5.6 and we have adapted for imx25. The only
changes is this (because imx25 registers are identical to mx3 ):
old:
Hi Gilles,
here is my time.c
Il 10/04/2012 11:11, Gilles Chanteperdrix ha scritto:
On 04/10/2012 11:06 AM, Gilles Chanteperdrix wrote:
On 04/10/2012 10:58 AM, Roberto Bielli wrote:
Hi Gilles,
i look at the processor errata but for the imx25 there are no errata
elements on timer.
It is
On 04/10/2012 11:19 AM, Roberto Bielli wrote:
Hi Gilles,
the steps for supporting imx25 have been:
1. We buy a board with imx25
2. Our supplier made the porting of linux 2.6.31 freescale with imx25
3. we put a xenomai 2.5.6 and we have adapted for imx25. The only
changes is this
On 04/10/2012 11:21 AM, Roberto Bielli wrote:
Hi Gilles,
here is my time.c
Looks fine, though I do not understand why you do not use timer_is_v2
instead of cpu_is_mx3 || cpu_is_mx25. I think the problem is elsewhere,
and I suggest you check whether linux without xenomai has or has not the
On 04/10/2012 11:21 AM, Roberto Bielli wrote:
Hi Gilles,
here is my time.c
Though you have not made all the changes I suggested. Here is the time.c
I would use.
--
Gilles.
/*
* linux/arch/arm/plat-mxc/time.c
*
* Copyright
Hi Gilles,
i tried your code but th behavior is the same.
Then i tried a linux base app and works correctly.
Il 10/04/2012 11:37, Gilles Chanteperdrix ha scritto:
On 04/10/2012 11:21 AM, Roberto Bielli wrote:
Hi Gilles,
here is my time.c
Though you have not made all the changes I
On 04/10/2012 12:39 PM, Roberto Bielli wrote:
Hi Gilles,
i tried your code but th behavior is the same.
Then i tried a linux base app and works correctly.
The tsc physical address passed to user-space looks wrong.
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
On 04/10/2012 12:39 PM, Roberto Bielli wrote:
Hi Gilles,
i tried your code but th behavior is the same.
Then i tried a linux base app and works correctly.
In the exact same conditions? With the crunching task running with
SCHED_FIFO, priority 1, and the periodic task running with
Hi Gilles,
i added this in configure of xenomai so i pass --enable-arm-mach=imx25
imx25)arch=5
tsc_type=__XN_TSC_TYPE_FREERUNNING;;
Furthermore in plat-mxc/include/mach/mxc.h explain which are cpumx2 and
imx25 is NOT mx2
#define cpu_is_mx2()(cpu_is_mx21() ||
Il 10/04/2012 14:06, Gilles Chanteperdrix ha scritto:
On 04/10/2012 02:05 PM, Roberto Bielli wrote:
Hi Gilles,
i added this in configure of xenomai so i pass --enable-arm-mach=imx25
imx25)arch=5
tsc_type=__XN_TSC_TYPE_FREERUNNING;;
Furthermore in
here is some logs.
status=on:setup=616:clock=509343446344:timerdev=mxc_timer1:clockdev=mxc_timer1
root@AXC25:/data# cat /proc/xenomai/timer
status=on:setup=616:clock=509413956366:timerdev=mxc_timer1:clockdev=mxc_timer1
root@AXC25:/data# cat /proc/xenomai/timer
On 04/10/2012 02:33 PM, Roberto Bielli wrote:
Il 10/04/2012 13:49, Gilles Chanteperdrix ha scritto:
On 04/10/2012 12:39 PM, Roberto Bielli wrote:
Hi Gilles,
i tried your code but th behavior is the same.
Then i tried a linux base app and works correctly.
In the exact same conditions? With
In the xenomai example the task periodic is 2ms not 200us. (
rt_task_sleep( 2ms 000us 000ns ) );
And the 10ms is because the default system time period of the timer
without xenomai is ~10ms.
So a process that execute in linux base can be re-scheduled only when
the timer generate an interrupt ,
On 04/10/2012 02:58 PM, Roberto Bielli wrote:
In the xenomai example the task periodic is 2ms not 200us. (
rt_task_sleep( 2ms 000us 000ns ) );
sorry, I misred.
And the 10ms is because the default system time period of the timer
without xenomai is ~10ms.
So a process that execute in linux
On 04/06/2012 06:59 PM, Roberto Bielli wrote:
Hi Gilles,
i made all your modifies and re-read all corect register but the problem
is the same.
Ok. What I would do at this point is check whether linux has the same
issue. You can also check the processor errata to see if there is no
issue
On 04/06/2012 05:35 PM, Roberto Bielli wrote:
Hi Gilles,
excuse me, but i don't understand why i have to read the register after
a write.
In the imx processor manual i didn't find that behaviour.
Read again what I wrote: I do not say you have to, I say you may want
to, it is just a trick
Hi Gilles,
i made all your modifies and re-read all corect register but the problem
is the same.
Best Regards
Il 06/04/2012 17:40, Gilles Chanteperdrix ha scritto:
On 04/06/2012 05:35 PM, Roberto Bielli wrote:
Hi Gilles,
excuse me, but i don't understand why i have to read the register
On 03/07/2012 07:13 PM, Roberto Bielli wrote:
Hi Gilles,
this is the trace and the test.
It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
disable interrupts.
Thanks a lot for your time.
Hi Roberto,
any news about this issue?
Regards.
--
Hi Gilles,
i have always this big problem but the timer and the avic are programmed
correctly.
There is something else but i don't know what.
In this moment i'm doing another work but soon i want to debug that error.
Thanks for all
Il 04/04/2012 11:21, Gilles Chanteperdrix ha scritto:
On
On 04/04/2012 11:29 AM, Roberto Bielli wrote:
Hi Gilles,
i have always this big problem but the timer and the avic are programmed
correctly.
There is something else but i don't know what.
In this moment i'm doing another work but soon i want to debug that error.
It is undoubtly a timer
On 03/07/2012 07:13 PM, Roberto Bielli wrote:
Hi Gilles,
this is the trace and the test.
It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
disable interrupts.
Sorry, I somehow missed this post.
I am afraid you are mis-reading the trace. The time spent in user-space
On 03/13/2012 12:44 PM, Gilles Chanteperdrix wrote:
On 03/07/2012 07:13 PM, Roberto Bielli wrote:
Hi Gilles,
this is the trace and the test.
It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
disable interrupts.
Sorry, I somehow missed this post.
I am afraid you
Hi Gilles,
we are sure that when a task execute NO INTERRUPTS arrives in interrupt
service routine in assembler in the kernel,
until it sleeps. It's not a problem of secondary mode.
So we tried the same application on another porting of xenomai with
marvell ( kernel 2.6.31.8 - xenomai always
On 03/07/2012 01:59 PM, Roberto Bielli wrote:
Hi Gilles,
we are sure that when a task execute NO INTERRUPTS arrives in interrupt
service routine in assembler in the kernel,
until it sleeps. It's not a problem of secondary mode.
Show me the trace and I will believe you (approximately fourth
Hi Gilles,
this is the trace and the test.
It seems that '__ipipe_dispatch_event' last about ~84 milliseconds with
disable interrupts.
Thanks a lot for your time.
Il 07/03/2012 14:44, Gilles Chanteperdrix ha scritto:
On 03/07/2012 01:59 PM, Roberto Bielli wrote:
Hi Gilles,
we are sure
On 03/06/2012 08:55 AM, Roberto Bielli wrote:
Hi,
it seems that i have a big problem with preemption. (kernel 2.6.31, arm
freescale imx25, xenomai 2.5.6 )
I send a simple application that doesn't work.
The task with name 'task2ms' has higher priority than 'taskPrintf', but
Hi Gilles,
here is the new trace.
Il 06/03/2012 13:09, Gilles Chanteperdrix ha scritto:
On 03/06/2012 11:14 AM, Roberto Bielli wrote:
Hi,
here is the trace.
Please try to capture the xntimer_next_local_shot which happens before
the bug to see if the timer ticks when expected.
Also note
On 03/06/2012 02:00 PM, Roberto Bielli wrote:
Hi Gilles,
here is the new trace.
There is nothing to see on that trace. Please increase the number of
trace points, and trigger a trace when you detect a problem., the number
of trace points should be sufficient to get the timer programmation
Hi Gilles,
i changed the min value of the '__ipipe_mach_set_dec' but the situation
is the same.
I see with the scope that the task with less priority is not interrupted.
It's difficult to see with the ipipe trace the problem so i put the
xenomai trace in the application with
On 03/06/2012 04:14 PM, Roberto Bielli wrote:
Hi Gilles,
i changed the min value of the '__ipipe_mach_set_dec' but the situation
is the same.
I see with the scope that the task with less priority is not interrupted.
In the trace you sent, we clearly saw that it was interrupted by a timer
Hi Gilles,
about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change mode
(the value of MSW is 0 )
so, it hasn't changed in secondary mode.
Correct ?
Il 06/03/2012 16:20, Gilles Chanteperdrix ha scritto:
On 03/06/2012 04:14 PM, Roberto Bielli wrote:
Hi Gilles,
i changed
On 03/06/2012 04:35 PM, Roberto Bielli wrote:
Hi Gilles,
about T_WARNSW i see in the /proc/xenomai/stat that my task hasn't change
mode (the value of MSW is 0 )
so, it hasn't changed in secondary mode.
Or maybe it started in secondary mode and never switched mode?
--
Hi,
it seems that i have a big problem with preemption. (kernel 2.6.31, arm
freescale imx25, xenomai 2.5.6 )
I send a simple application that doesn't work.
The task with name 'task2ms' has higher priority than 'taskPrintf', but
'taskPrintf' stop the task 'task2ms' until sleeps.
I think i
46 matches
Mail list logo
