[Xenomai-core] Fwd: Re: preemptive doesn't work
Hi Gilles,
have you received the trace ?
Have you find a weird behaviour ?
In attach you find the same trace.
Thanks a lot in advance.
Messaggio originale
Oggetto:Re: [Xenomai-core] preemptive doesn't work
Data: Wed, 07 Mar 2012 19:13:59 +0100
Mittente: Roberto Bielli roberto.bie...@axelsw.it
A: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
CC: xenomai-core@gna.org
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 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 time I ask).
--
++
Roberto Bielli
Sviluppo Software
Axel S.r.l.
Via Del Cannino, 3
21020 Crosio Della Valle
Varese - Italy
Telefono: +39 0332 949600
Fax: +39 0332 969315
E-mail: roberto.bie...@axelsw.it
Web Site: www.axelsw.it
++
Si precisa che le informazioni contenute in questo messaggio sono riservate e
ad uso esclusivo del destinatario.
Qualora il messaggio in parola Le fosse pervenuto per errore, La preghiamo di
eliminarlo senza copiarlo e di non inoltrarlo a terzi,
dandocene gentilmente comunicazione. Grazie.
Informativa sul trattamento dei dati personali (D. Lgs. 196/2003).
I dati utilizzati per la spedizione del presente messaggio sono utilizzati da
Axel S.r.l., titolare del trattamento,
per l'invio delle comunicazioni dei diversi settori aziendali, non essendo
autorizzata la divulgazione a terzi.
Potrete rivolgere alla seguente mail richieste di verifica, rettifica o
cancellazione dei Vostri dati: i...@axelsw.it
This e-mail and any attachments is confidential and may contain privileged
information
intended for the addressee(s) only. Dissemination, copying, printing or use by
anybody
else is unauthorised. If you are not the intended recipient,
please delete this message and any attachments and advise the sender
by return e-mail.Thank you.
++
I-pipe frozen back-tracing service on 2.6.31/ipipe-1.16-02
CPU: 0, Freeze: 2038911849125 cycles, Trace Points: 100 (+10)
Calibrated minimum trace-point overhead: 1.044 us
+- Hard IRQs ('|': locked)
|+ unused
||+--- unused
|||+-- Xenomai
+- Linux ('*': domain stalled, '+': current, '#': current+stalled)
|+-- Delay flag ('+': 1 us, '!': 10 us)
||+- NMI noise ('N')
|||
TypeUser Val. TimeDelay Function (Parent)
:| #func -84864+ 1.313 __ipipe_handle_irq+0x14
(__ipipe_grab_irq+0x68)
:| #func -84863+ 1.164 __ipipe_ack_timerirq+0x10
(__ipipe_handle_irq+0x9c)
:| #func -84862+ 1.462 __ipipe_ack_level_irq+0x10
(__ipipe_ack_timerirq+0x24)
:| #func -84860+ 1.358 mxc_mask_irq+0x10
(__ipipe_ack_level_irq+0x3c)
:| #func -84859+ 1.432 mxc_mask_irq+0x10
(__ipipe_ack_level_irq+0x54)
:| #func -84858+ 1.268 __ipipe_mach_acktimer+0x10
(__ipipe_ack_timerirq+0x28)
:| #func -84856+ 1.298 __ipipe_end_level_irq+0x10
(__ipipe_ack_timerirq+0x38)
:| #func -84855+ 1.358 mxc_unmask_irq+0x10
(__ipipe_end_level_irq+0x28)
:| #func -84854+ 1.552 __ipipe_dispatch_wired+0x10
(__ipipe_handle_irq+0xa8)
:| #func -84852+ 1.238 __ipipe_dispatch_wired_nocheck+0x10
(__ipipe_dispatch_wired+0x84)
:| #*func -84851+ 1.507 xnintr_clock_handler+0x10
(__ipipe_dispatch_wired_nocheck+0x68)
:| #*func -84849+ 2.208 xntimer_tick_aperiodic+0x14
(xnintr_clock_handler+0x44)
:| #*func -84847+ 2.074 xntimer_next_local_shot+0x10
(xntimer_tick_aperiodic+0x258)
:| #*event tick@-84784-84845+ 1.164
Re: [Xenomai-core] preemptive doesn't work
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 gets accounted to __ipipe_dispatch_event, because this is the last instrumented function called before the return to user-space. Interrupts are disabled at this point, this is perfectly normal, but they are probably re-enabled when returning to user-space. What is more problematic, however, is that the timer interrupt did not tick at -83749 like it is supposed to. If it had ticked and the interrupt had been disabled in user-space, you would have taken the interrupt at -35, when __ipipe_syscall_root gets called with interrupts on. So, now, you have to understand why the timer interrupt did not tick. I suggest, when the problem happens, you look at: * the interrupt controller register, to see if the timer interrupt is still masked, if it is masked, then try first commenting out the snippet in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the irq_mask_ack callback * the timer registers, to see if the timer was programmed correctly, and is still ticking when the issue happens. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 are mis-reading the trace. The time spent in user-space gets accounted to __ipipe_dispatch_event, because this is the last instrumented function called before the return to user-space. Interrupts are disabled at this point, this is perfectly normal, but they are probably re-enabled when returning to user-space. What is more problematic, however, is that the timer interrupt did not tick at -83749 like it is supposed to. If it had ticked and the interrupt had been disabled in user-space, you would have taken the interrupt at -35, when __ipipe_syscall_root gets called with interrupts on. So, now, you have to understand why the timer interrupt did not tick. I suggest, when the problem happens, you look at: * the interrupt controller register, to see if the timer interrupt is still masked, if it is masked, then try first commenting out the snippet in arch/arm/plat-mxc/avic.c which declares mxc_mask_irq as the irq_mask_ack callback * the timer registers, to see if the timer was programmed correctly, and is still ticking when the issue happens. You may also want, in __ipipe_mach_set_dec, to re-read the comparator value after writing it. Sometimes, such things are needed for the write to register to be really taken into account. -- Gilles. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
