[Xenomai-core] rt_task_create and rt_task delete re-scheduling calling task
Hi, i saw in the documentation that rt_task_create and rt_task_delete should re-scheduling the calling task. So i lost the priority if in a task try to call rt_task_create or rt_task create. Do i understand correctly ? Is there a way to avoid this behaviour ? Or which are all the case of re-scheduling whne calling rt_task_create/rt_task_delete ? Thanks of all P.S. the imx25 now it's perfect. Was only the reentrant interrupt. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
Hi Gilles, i found the problem that disable interrupts when execute a task. My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config. This properties enable reentrant interrupts so it uses the NIMASK(normal interrupt mask register ) register to disable interrupts with certain priority level. The interrupt of timer is disabled in that cases. i tried to disable this option in the kernel but i have other big problems with the task and so i have to do other tests before saying the conclusions. Do you know if xenomai doesn't work with reentrant interrupts ? Il 18/04/2012 13:51, Gilles Chanteperdrix ha scritto: On 04/18/2012 12:28 PM, Roberto Bielli wrote: Hi Gilles, i try to give only another accurate information. i made another test: i write a xenomai driver for reading the timer and avic register and i see a strange behaviour. when there is the problem the interrupt is NOT masqueraded in avic but the timer has the interrupt not acked. Ah, that is good news, at least now we have a clue. Note that it could also mean that the timer has ticked, but the irq is not generated for another reason. I think you should dump all the timer registers, and see if anything is wrong by decoding their values with the datasheet. A quick test also, assuming that the write to the MX3_TSTAT regiter in gpt_irq_acknowledge may be posted, try rereading the register after writing it. After this i understand that now are my problems. Do you know somebody that can help me understanding the problem only for xenomai side? If you need someone's help, you need to give access to your board to that person or company. Because indirect debugging is really inefficient: look at how many mails I had to send you over how much time to get you to do what anybody with xenomai experience would have done in just a few hours. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
have you a .config for imx31 to give me so i can compare them? Il 19/04/2012 10:54, Gilles Chanteperdrix ha scritto: On 04/19/2012 10:52 AM, Roberto Bielli wrote: Hi Gilles, i found the problem that disable interrupts when execute a task. My kernel for imx25 uses the properties CONFIG_MXC_IRQ_PRIOR in the .config. This properties enable reentrant interrupts so it uses the NIMASK(normal interrupt mask register ) register to disable interrupts with certain priority level. The interrupt of timer is disabled in that cases. i tried to disable this option in the kernel but i have other big problems with the task and so i have to do other tests before saying the conclusions. Do you know if xenomai doesn't work with reentrant interrupts ? Xenomai as it is will not work in that case, and this option is useless as all interrupts handlers are executed with hardware irqs disabled, so your best solution is to try and disable this option. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
Hi Gilles, i try to give only another accurate information. i made another test: i write a xenomai driver for reading the timer and avic register and i see a strange behaviour. when there is the problem the interrupt is NOT masqueraded in avic but the timer has the interrupt not acked. After this i understand that now are my problems. Do you know somebody that can help me understanding the problem only for xenomai side? We can accept a quotation of work. Thanks for all information and if you Il 18/04/2012 11:19, Gilles Chanteperdrix ha scritto: On 04/18/2012 10:44 AM, Roberto Bielli wrote: Hi Gilles, here find the answers. sorry for the delay. Il 13/04/2012 15:47, Gilles Chanteperdrix ha scritto: On 04/13/2012 10:44 AM, Roberto Bielli wrote: Hi Gilles, you don't feel like to repeat. I'm trying all the things that you told me and i will do all the missing test that you told me. So, what is the result of running your test with unpatched Linux, but with CONFIG_HIGH_RES_TIMERS enabled? the result is the same. With the base linux application and CONFIG_HIGH_RES_TIMERS all it's ok, instead with xenomai application the task with less priority halt the task with higher priority until it sleeps. I send you my .config file and the test with pthread base. You know as well as me that this description of the problem is inaccurate, what really happens is that the timer is programmed but does not tick. What you have to do now is try and understand what is the difference between the way xenomai and linux handle the timer to understand what cause it not to work in xenomai case. If I were you, to understand this difference, I would start by dumping all timer registers values at the time when the problem is detected, that is, before the timer is programmed again. But I am afraid I can not give you more help, ultimately you are the one which is doing the port to imx25, so you are on your own. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] porting xenomai on imx25
Hi Gilles, you don't feel like to repeat. I'm trying all the things that you told me and i will do all the missing test that you told me. And now this is the result of latency that i ran. It seems correct. root@AXC25:/usr/xenomai/bin# ./latency == Sampling period: 1000 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99) RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat worst RTD| 67.263| 77.203| 85.458| 0| 0| 67.263| 85.458 RTD| 67.293| 77.203|100.240| 0| 0| 67.263| 100.240 RTD| 67.413| 77.203| 88.360| 0| 0| 67.263| 100.240 RTD| 67.323| 77.233| 86.661| 0| 0| 67.263| 100.240 RTD| 66.676| 77.187| 85.849| 0| 0| 66.676| 100.240 RTD| 67.353| 77.233| 87.172| 0| 0| 66.676| 100.240 RTD| 67.203| 77.368|217.323| 0| 0| 66.676| 217.323 RTD| 67.609| 77.172| 87.022| 0| 0| 66.676| 217.323 RTD| 66.796| 77.218| 86.030| 0| 0| 66.676| 217.323 RTD| 67.714| 77.172| 85.368| 0| 0| 66.676| 217.323 RTD| 67.263| 77.233| 87.263| 0| 0| 66.676| 217.323 RTD| 67.022| 77.172| 85.684| 0| 0| 66.676| 217.323 RTD| 67.669| 77.248| 83.894| 0| 0| 66.676| 217.323 RTD| 67.969| 77.172| 86.736| 0| 0| 66.676| 217.323 RTD| 66.827| 77.187| 87.383| 0| 0| 66.676| 217.323 RTD| 67.097| 77.263|119.909| 0| 0| 66.676| 217.323 RTD| 67.022| 77.308|183.548| 0| 0| 66.676| 217.323 RTD| 66.616| 77.187| 84.902| 0| 0| 66.616| 217.323 RTD| 67.353| 77.187| 91.338| 0| 0| 66.616| 217.323 RTD| 67.022| 77.233| 83.278| 0| 0| 66.616| 217.323 RTD| 67.037| 77.248| 87.022| 0| 0| 66.616| 217.323 RTT| 00:00:22 (periodic user-mode task, 1000 us period, priority 99) RTH|lat min|lat avg|lat max|-overrun|---msw|---lat best|--lat worst RTD| 67.037| 77.157| 86.796| 0| 0| 66.616| 217.323 RTD| 66.902| 77.263|125.383| 0| 0| 66.616| 217.323 RTD| 67.548| 77.187| 87.894| 0| 0| 66.616| 217.323 RTD| 67.338| 77.248| 86.255| 0| 0| 66.616| 217.323 RTD| 67.157| 77.218| 87.157| 0| 0| 66.616| 217.323 RTD| 67.308| 77.233| 84.180| 0| 0| 66.616| 217.323 RTD| 67.684| 77.203| 86.631| 0| 0| 66.616| 217.323 RTD| 67.578| 77.187| 89.368| 0| 0| 66.616| 217.323 RTD| 66.917| 77.203| 86.691| 0| 0| 66.616| 217.323 RTD| 66.992| 77.218| 86.616| 0| 0| 66.616| 217.323 RTD| 67.142| 77.218| 87.097| 0| 0| 66.616| 217.323 RTD| 67.248| 77.187| 90.180| 0| 0| 66.616| 217.323 RTD| 67.368| 77.233| 87.939| 0| 0| 66.616| 217.323 RTD| 67.413| 77.187| 89.503| 0| 0| 66.616| 217.323 RTD| 67.684| 77.233| 87.368| 0| 0| 66.616| 217.323 RTD| 67.428| 77.157| 87.203| 0| 0| 66.616| 217.323 RTD| 67.248| 77.157| 91.368| 0| 0| 66.616| 217.323 RTD| 67.233| 77.368|215.879| 0| 0| 66.616| 217.323 RTD| 67.428| 77.323|178.857| 0| 0| 66.616| 217.323 RTD| 66.917| 77.187| 92.075| 0| 0| 66.616| 217.323 ---|---|---|---||--|- RTS| 66.616| 77.218|217.323| 0| 0| 00:00:41/00:00:41 Il 12/04/2012 19:40, Gilles Chanteperdrix ha scritto: On 04/12/2012 06:58 PM, Roberto Bielli wrote: Hi Gilles, you tell me that you are working on imx. Do you know if there is a working xenomai on imx (any kernel or imx version) ? I have tested Xenomai on imx31, imx51, imx53, imx6q. It works on these platforms. Now, what you are doing is in fact porting xenomai on imx25, nobody did that before you, and you are faced with a peculiarity of the timer on this platform. What you should do is: - try to reproduce the problem with an unpatched linux with CONFIG_HIGH_RES_TIMERS - or try and look at the timers registers value at the time when the bug happens to see what is going wrong. Also, the first thing to do when running xenomai on a new platform is to run the latency test. Have you run this test? I feel like I am starting to repeat
Re: [Xenomai-core] preemptive doesn't work
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 you think that can be a similar problem ? Il 11/04/2012 14:10, Gilles Chanteperdrix ha scritto: 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 doesn't write in the processor manual) Do you know if there is a code over the mxc_mask_irq that disable the interrupts ? About interrupt gpio it should be a link with this behaviour ? ( i don't want gpio as interrupts ) No, I do not think it is possible. You do not get to decide whether you want gpio as interrupts or not, the design of the board you use does. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 there is a code over the mxc_mask_irq that disable the
interrupts ?
About interrupt gpio it should be a link with this behaviour ? ( i don't
want gpio as interrupts )
Il 10/04/2012 14:40, Gilles Chanteperdrix ha scritto:
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 the crunching task running with
SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO,
priority 99, and the linux real-time throttling disabled?
Yes, and i see that every LATCH ( about ~10ms ) period the task with
higher priority is wakeup.
So a task with lower priority is interrupted by timer interrupt and
reschedule the task with higher priority.
The only thing I can think is that the timer interrupt in fact stays
masked. You can try the following patch:
diff --git a/arch/arm/plat-mxc/irq.c b/arch/arm/plat-mxc/irq.c
index 8aee763..7e4cc2e 100644
--- a/arch/arm/plat-mxc/irq.c
+++ b/arch/arm/plat-mxc/irq.c
@@ -94,12 +94,14 @@ EXPORT_SYMBOL(mxc_set_irq_fiq);
static void mxc_mask_irq(unsigned int irq)
{
__raw_writel(irq, avic_base + AVIC_INTDISNUM);
+ __raw_readl(avic_base + AVIC_INTDISNUM);
}
/* Enable interrupt number irq in the AVIC */
static void mxc_unmask_irq(unsigned int irq)
{
__raw_writel(irq, avic_base + AVIC_INTENNUM);
+ __raw_readl(avic_base + AVIC_INTENNUM);
}
static struct irq_chip mxc_avic_chip = {
If I had to debug this issue, I would look at all the timer and
interrupt controller registers value, to see what is wrong.
You can also try the plain linux example with CONFIG_IPIPE on, but
without CONFIG_XENOMAI.
Other than that, without access to the board, it is hard for me to
debug further, so I am afraid you are on your own.
--
++
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.
++
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 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 with the timer. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 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 with the timer. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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: 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 timer ticks more often than it should. Generally, this is an indication that the timer frequency is not what xenomai believe it is. xenomai idea of the timer frequency is given by __ipipe_mach_ticks_per_jiffy. Anyway, this should not cause the timer not to tick, only to tick it more often. What you should do now is try and reproduce the same conditions under an unpatched linux to see if you get the same phenomenon. Did you have a look a the processor errata ? -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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: #define timer_is_v2()(cpu_is_mx3() || cpu_is_mx5()) new: #define timer_is_v2()(cpu_is_mx3() || cpu_is_mx25() || cpu_is_mx5()) Il 10/04/2012 11:06, Gilles Chanteperdrix ha scritto: 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 is entirely possible that you have to adapt it. See: http://www.xenomai.org/index.php/I-pipe:ArmPorting -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 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 is entirely possible that you have to adapt it. See: http://www.xenomai.org/index.php/I-pipe:ArmPorting Latest kernels support imx25, and imx25 works like an mx3, not an mx2, can you show me arch/arm/plat-mxc/time.c for your (undoubtedly) patched kernel? -- ++ 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. ++ /* * linux/arch/arm/plat-mxc/time.c * * Copyright (C) 2000-2001 Deep Blue Solutions * Copyright (C) 2002 Shane Nay (sh...@minirl.com) * Copyright (C) 2006-2007 Pavel Pisa (pp...@pikron.com) * Copyright (C) 2008 Juergen Beisert (ker...@pengutronix.de) * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option) any later version. * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, * MA 02110-1301, USA. */ #include linux/interrupt.h #include linux/irq.h #include linux/clockchips.h #include linux/clk.h #include mach/hardware.h #include asm/mach/time.h #include mach/common.h /* defines common for all i.MX */ #define MXC_TCTL0x00 #define MXC_TCTL_TEN(1 0) #define MXC_TPRER 0x04 /* MX1, MX21, MX27 */ #define MX1_2_TCTL_CLK_PCLK1(1 1) #define MX1_2_TCTL_IRQEN(1 4) #define MX1_2_TCTL_FRR (1 8) #define MX1_2_TCMP 0x08 #define MX1_2_TCN 0x10 #define MX1_2_TSTAT 0x14 /* MX21, MX27 */ #define MX2_TSTAT_CAPT (1 1) #define MX2_TSTAT_COMP (1 0) /* MX31, MX35, MX25 */ #define MX3_TCTL_WAITEN (1 3) #define MX3_TCTL_CLK_IPG(1 6) #define MX3_TCTL_CLK_PER(2 6) #define MX3_TCTL_FRR(1 9) #define MX3_IR 0x0c #define MX3_TSTAT 0x08 #define MX3_TSTAT_OF1 (1 0) #define MX3_TCN 0x24 #define MX3_TCMP0x10 #ifdef CONFIG_IPIPE #ifdef CONFIG_NO_IDLE_HZ #error dynamic tick timer not yet supported with IPIPE #endif /* CONFIG_NO_IDLE_HZ */ int __ipipe_mach_timerint; EXPORT_SYMBOL(__ipipe_mach_timerint
Re: [Xenomai-core] preemptive doesn't work
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 suggested. Here is the time.c I would use. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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() || cpu_is_mx27())
i don't understand a things.
Does the tsc necessary to calculate correct timer period, or can i
disable tsc and xenomai continue work correctly ?
However i cannot use tsc in my simple application. I resend the simple C
application that doesn't work.
Il 10/04/2012 13:25, 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.
The tsc physical address passed to user-space looks wrong.
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
info-type = IPIPE_TSC_TYPE_FREERUNNING;
if (cpu_is_mx1()) {
#ifdef CONFIG_ARCH_MX1
info-u.fr.counter = (unsigned *) (TIM1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx2()) {
#ifdef CONFIG_ARCH_MX2
info-u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX1_2_TCN);
#endif
} else if (cpu_is_mx3() || cpu_is_mx25() ) {
#if defined CONFIG_ARCH_MX3 || defined CONFIG_ARCH_MX25
info-u.fr.counter = (unsigned *) (GPT1_BASE_ADDR + MX3_TCN);
#endif
}
info-u.fr.mask = 0x;
info-u.fr.tsc =tsc-full;
}
Here cpu_is_mx2() will return true, and we will not go to cpu_is_mx25().
Are you using the tsc in user-space?
If you are passing --enable-arm-mach=mx2 to xenomai configure
script, you are using the tsc in user-space, and it is a wonder
how it works.
--
++
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.
++
#include stdio.h
#include stdint.h
#include fcntl.h
#include sys/ioctl.h
#include string.h
#include stdlib.h
#include stdio.h
#include sys/mman.h /* for MCL_CURRENT and MCL_FUTURE */
#include rtdm/rtdm.h
#include native/task.h
#include nucleus/trace.h
#define GPIO6_ON*Gpio2ValAddr |= 1 6
#define GPIO6_OFF *Gpio2ValAddr = ~(1 6);
static RT_TASK rt_task_desc;
static RT_TASK tsk2ms;
//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;
volatile int cnt2ms = 0;
volatile int cntmain = 0;
volatile int x;
void funct2ms( void * params )
{
for(;;)
{
GPIO6_ON;
rt_task_sleep( 200 );
++ cnt2ms;
GPIO6_OFF;
}
}
int main(int argc, char *argv[])
{
int count = 0;
int traceOn = 0;
int fd, ret;
// no memory-swapping for this programm
ret = mlockall(MCL_CURRENT | MCL_FUTURE);
if( ret )
{
perror(ERROR : mlockall has failled);
exit(1);
}
fd = open( /dev/mem, O_RDWR | O_SYNC
Re: [Xenomai-core] preemptive doesn't work
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 plat-mxc/include/mach/mxc.h explain which are cpumx2 and imx25 is NOT mx2 #define cpu_is_mx2()(cpu_is_mx21() || cpu_is_mx27()) i don't understand a things. Does the tsc necessary to calculate correct timer period, or can i disable tsc and xenomai continue work correctly ? Xenomai needs the tsc in kernel-space. Obviously, if you do not use the tsc in user-space, you will not see that it is wrong. Correct physical address is only needed for user-space. However i cannot use tsc in my simple application. I resend the simple C application that doesn't work. What do you mean you can not use the tsc in your application? What happens if you use it? If i use tsc i have no error and i read a correct value. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 status=on:setup=616:clock=50946186:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=509493738137:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=509642692217:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=509889401336:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=509959233537:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=510033716418:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=510083589650:timerdev=mxc_timer1:clockdev=mxc_timer1 root@AXC25:/data# cat /proc/xenomai/timer status=on:setup=616:clock=510145433674:timerdev=mxc_timer1:clockdev=mxc_timer1 Il 10/04/2012 14:12, Gilles Chanteperdrix ha scritto: On 04/10/2012 02:11 PM, Roberto Bielli wrote: 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 plat-mxc/include/mach/mxc.h explain which are cpumx2 and imx25 is NOT mx2 #define cpu_is_mx2()(cpu_is_mx21() || cpu_is_mx27()) i don't understand a things. Does the tsc necessary to calculate correct timer period, or can i disable tsc and xenomai continue work correctly ? Xenomai needs the tsc in kernel-space. Obviously, if you do not use the tsc in user-space, you will not see that it is wrong. Correct physical address is only needed for user-space. However i cannot use tsc in my simple application. I resend the simple C application that doesn't work. What do you mean you can not use the tsc in your application? What happens if you use it? If i use tsc i have no error and i read a correct value. So, it works. Good news. To know if it works as expected, you can try the latency test. Something I have not asked, could you type: cat /proc/xenomai/timer on the mx25 board? -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 , the task makes I/O, or sleeps. Il 10/04/2012 14:36, Gilles Chanteperdrix ha scritto: 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 the crunching task running with SCHED_FIFO, priority 1, and the periodic task running with SCHED_FIFO, priority 99, and the linux real-time throttling disabled? Yes, and i see that every LATCH ( about ~10ms ) period the task with higher priority is wakeup. In the example you sent the periodic task was running with a 200us period, not 10ms. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 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 you may want to try, which I have already seen solving this kind of issues. Besides, that is what the linux clockevent driver does. I would first try reading the status register in the __ipipe_mach_acktimer , and if it does not fix the issue, try the re-read trick. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 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. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Using xenomai with standard ethernet driver
Hi Jan, if i want to send a raw ethernet (for example for implement ethercat communication) so the best practise for xenomai is to transform the linux base driver to xenomai driver. Is it correct ? Thanks for all Il 23/03/2012 13:14, Jan Kiszka ha scritto: On 2012-03-23 12:18, Roberto Bielli wrote: Hi Jan, i want to send and receive custom raw packets over ethernet. is it possibile with RTnet or it sends only rtnet packets ? Thanks for your response. RTnet is modular, and if you use the stack a sketched, you are free to define the payload of the sent Ethernet frames on your own. Jan -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Using xenomai with standard ethernet driver
I explain better the problem. I want to use ethernet driver raw without using all the abstract layer (tcp, socket etc) and my xenomai application must link to the raw driver without enter in secondary mode. Have i change the driver interface with xenomai calls (rtdm_..) or is there another chance ? Thanks a lot for your response. Il 22/03/2012 16:30, Jan Kiszka ha scritto: On 2012-03-21 17:48, Roberto Bielli wrote: Hi, i want to use xenomai for sending standard tcp/ip packets. Is it possible to rewrite the ethernet driver for xenomai without using rtnet ? Or if i use rtnet is there a way to send standard tcp packet instead rtnet packets ? Is the TCP/IP communication itself part of your time-critical path, or could it run with lower priority as well? Jan -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Using xenomai with standard ethernet driver
Hi, i want to use xenomai for sending standard tcp/ip packets. Is it possible to rewrite the ethernet driver for xenomai without using rtnet ? Or if i use rtnet is there a way to send standard tcp packet instead rtnet packets ? Thanks for all. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[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
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 2.5.6 ) and there is no problem. We cannot change the kernel so we must find the problem in this version 2.6.31 with xenomai 2.5.6 . The patch of ipipe used is for 2.6.31.8 instead 2.6.31. Is there a problem for this ? There are the hw locks (spin_lock, etc...) in the 2.6.31 that are different in 2.6.31.8 ? I repeat that seems that all interrupt are disabled, as if there are some irq_enable/irq_disable when execute a task, or the interrupt line is not acked. The hw implementation of read/write/ack timer are correct. Can you explain me how work the scheduler of xenomai compared with the tasks and the timer ? Thanks for all. Il 06/03/2012 17:16, Gilles Chanteperdrix ha scritto: 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? -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 xntimer_next_local_shot+0xcc
(xntimer_tick_aperiodic+0x258)
:| #*func -84844+ 2.268 __ipipe_mach_set_dec+0x10
(xntimer_next_local_shot+0x110)
:| #func -84842+ 1.552 __ipipe_walk_pipeline+0x10
(__ipipe_dispatch_wired_nocheck+0xac)
:| #end 0x -84840+ 1.835 __ipipe_grab_irq+0x74 (__irq_svc+0x68)
:#func -84838+ 1.522 vma_prio_tree_remove+0x10
Re: [Xenomai-core] preemptive doesn't work
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 that if we are going through __ipipe_preempt_schedule_irq, it
means that the task eating the cpu is running in secondary mode. So, you
should use T_WARNSW to see.
Please keep the discussion on the mailing list.
--
++
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 worst-case tracing service on 2.6.31/ipipe-1.16-02
CPU: 0, Begin: 413559887374 cycles, Trace Points: 27 (-10/+1), Length: 81 us
Calibrated minimum trace-point overhead: 1.029 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)
| +begin 0x8001 -1262.313 __up_read+0x30 (up_read+0x18)
| #end 0x8001 -1241.880 __up_read+0x50 (up_read+0x18)
#func-1221.850 ipipe_check_context+0x10
(__up_read+0x5c)
#func-1201.522 __ipipe_restore_root+0x10
(__up_read+0x130)
#func-1191.149 __ipipe_unstall_root+0x10
(__ipipe_restore_root+0x94)
| #begin 0x8000 -1181.597 __ipipe_unstall_root+0x34
(__ipipe_restore_root+0x94)
| +end 0x8000 -1161.432 __ipipe_unstall_root+0x98
(__ipipe_restore_root+0x94)
+func-1152.970 ipipe_check_context+0x10
(__up_read+0x138)
+func-112 107.507 __ipipe_check_root+0x10
(ret_from_exception+0x4)
| +func -44.656 __ipipe_grab_irq+0x10 (__irq_usr+0x70)
| +begin 0x 0+ 2.462 __ipipe_grab_irq+0x5c (__irq_usr+0x70)
:| +func 2+ 3.626 __ipipe_handle_irq+0x14
(__ipipe_grab_irq+0x68)
:| +func 6+ 2.104 __ipipe_ack_timerirq+0x10
(__ipipe_handle_irq+0x9c)
:| +func 8+ 2.805 __ipipe_ack_level_irq+0x10
(__ipipe_ack_timerirq+0x24)
:| +func 11+ 1.776 mxc_mask_irq+0x10
(__ipipe_ack_level_irq+0x3c)
:| +func 12+ 1.686 mxc_mask_irq+0x10
(__ipipe_ack_level_irq+0x54)
:| +func 14+ 1.507 __ipipe_mach_acktimer+0x10
(__ipipe_ack_timerirq+0x28)
:| +func 15+ 1.611 __ipipe_end_level_irq+0x10
(__ipipe_ack_timerirq+0x38)
:| +func 17+ 2.253 mxc_unmask_irq+0x10
(__ipipe_end_level_irq+0x28)
:| +func 19+ 2.283 __ipipe_dispatch_wired+0x10
Re: [Xenomai-core] preemptive doesn't work
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 |xntrace_user_start|/|xntrace_user_stop|. Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ? Thanks a lot Il 06/03/2012 14:04, Gilles Chanteperdrix ha scritto: 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 which happens before the problem. Also, did you try T_WANRSW ? Please disable the configuration of you mail server which asks me to send a receipt to each every mail you send me. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] preemptive doesn't work
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 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 interrupt. It's difficult to see with the ipipe trace the problem so i put the xenomai trace in the application with |xntrace_user_start|/|xntrace_user_stop|. Is the log of xenomai in the same place (/proc/ipipe/trace/max ) of ipipe ? See the latency test for an example of usage of the I-pipe tracer in user-space. When using latency -f the trace is available in /proc/ipipe/trace/frozen. What about T_WARNSW (it is the third time I ask). Also, it would be nice if you could try a more recent version of Xenomai and of the I-pipe patch, say 2.6.0 with the I-pipe patch for 2.6.38. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] preemptive doesn't work
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 have a problem with ipipe porting.
Any idea ?
--
++
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.
++
#include stdio.h
#include stdint.h
#include fcntl.h
#include sys/ioctl.h
#include string.h
#include stdlib.h
#include stdio.h
#include sys/mman.h /* for MCL_CURRENT and MCL_FUTURE */
#include rtdm/rtdm.h
#include native/task.h
#define RTXENDRIVER_TYPERTDM_CLASS_TESTING
#define RTXENDRIVER_SUBCLASS0
#define DEVICE_NAME
axc25xendriverCAN
/*---PRIVATE DATA-*/
#define GPIO6_ON*Gpio2ValAddr |= 1 6
#define GPIO6_OFF *Gpio2ValAddr = ~(1 6);
static RT_TASK rt_task_desc;
typedef unsigned int canid_t;
struct can_frame {
canid_t can_id; /* 32 bit CAN_ID + EFF/RTR/ERR flags */
unsigned charcan_dlc; /* data length code: 0 .. 8 */
unsigned chardata[8] __attribute__((aligned(8)));
};
/* valid bits in CAN ID for frame formats */
#define CAN_SFF_MASK 0x07FFU /* standard frame format (SFF) */
#define CAN_EFF_MASK 0x1FFFU /* extended frame format (EFF) */
#define CAN_ERR_MASK 0x1FFFU /* omit EFF, RTR, ERR flags */
/* special address description flags for the CAN_ID */
#define CAN_EFF_FLAG 0x8000U /* EFF/SFF is set in the MSB */
#define CAN_RTR_FLAG 0x4000U /* remote transmission request */
#define CAN_ERR_FLAG 0x2000U /* error frame */
int device;
//dati per la gestione memoria mappata
static unsigned long * Gpio2ValAddr = NULL;
/*---PUBLIC FUNCTIONS--*/
RT_TASK tskDesc;
RT_TASK tskCan;
RT_TASK tskDesc1;
int read_index =0;
int write_index =0;
#define SIZE_BUFFER 64
struct can_frame globCanFrameBuffer[SIZE_BUFFER];
volatile int x;
volatile int y;
/*void taskCan( void * params )
{
struct can_frame frame;
int nbytes;
for(;;)
{
nbytes = rt_dev_read( device, frame, sizeof( frame ));
}
}*/
void task2ms( void * params )
{
struct can_frame frame;
int nbytes;
for(;;)
{
GPIO6_ON;
rt_task_sleep( 200 );
GPIO6_OFF;
}
}
void taskPrintf( void * params )
{
for(;;)
{
for( x=0; x 100; x++ );
for( x=0; x 100; x++ );
rt_task_sleep( 1000 );
}
}
/*void taskRead( void * params )
{
struct can_frame frame;
int i;
while (1 )
{
//rt_task_sleep( 1000
[Xenomai-core] high duration of __ipipe_handle_irq
Hi, i have this problem with xenomai ( 2.5.6 - arm freescale imx25 ): I have a xenomai application that uses more rt_tasks, and i have a strange behaviour. When i run my application the period of *__ipipe_handle_irq* is very long ( ~3ms in some cases ) in the moment that come the *__ipipe_mach_timerint *interrupt and so the other interrupts are very late. Do you know something about this ? Thanks for all -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] iMX25 problem with gpio and xenomai
Hi, i'm doing the porting of xenomai version 2.5.6 on imx25 board and i'm looking to start from imx27. I have some problem with gpio. It seems there are spurious interrupts. I would know what xenomai want to know about interrupts (i see ipipe_handle_irq_cond in gpio handler, is it needed ?) and registry save (spin_lock_irqsave in mxc_gpio_set etc...) Thanks a lot -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] some problems with interrupts
Hi, i installed the patch 'adeos-ipipe-2.6.31-arm-1.16-02.patch' on a kernel 2.6.31 for imx257 processor. I have a xenomai complex application that read touchscreen events with tslib when pressed. In the kernel log i try these lines: ( the read job is made in a not-realtime thread ) [ cut here ] WARNING: at drivers/input/touchscreen/mxc_tsc.c:599 mxc_tsc_interrupt+0x19c/0x30c [mxc_tsc]() Modules linked in: can_raw can flexcan sdhci_mxc ehci_hcd mmc_core usbcore mxc_tsc nls_base Backtrace: [c0028150] (dump_backtrace+0x0/0x114) from [c02c9a48] (dump_stack+0x18/0x1c) r7:bf0054bc r6:0257 r5:bf0046d8 r4: [c02c9a30] (dump_stack+0x0/0x1c) from [c0043390] (warn_slowpath_common+0x50/0x68) [c0043340] (warn_slowpath_common+0x0/0x68) from [c00433c0] (warn_slowpath_null+0x18/0x1c) r7:002e r6:0001 r5:8013 r4:d1959400 [c00433a8] (warn_slowpath_null+0x0/0x1c) from [bf0046d8] (mxc_tsc_interrupt+0x19c/0x30c [mxc_tsc]) [bf00453c] (mxc_tsc_interrupt+0x0/0x30c [mxc_tsc]) from [c007242c] (handle_IRQ_event+0x3c/0x124) r7:002e r6: r5: r4:d1c69840 [c00723f0] (handle_IRQ_event+0x0/0x124) from [c007466c] (handle_level_irq+0x98/0x12c) r7:002e r6:d1c69840 r5:002e r4:c0399b70 [c00745d4] (handle_level_irq+0x0/0x12c) from [c0023070] (_text+0x70/0x8c) r7:002e r6:c03fc240 r5: r4:002e [c0023000] (_text+0x0/0x8c) from [c0076ee8] (__ipipe_sync_stage+0x180/0x268) Exception stack(0xc038ff40 to 0xc038ff88) ff40: 0020 0004 c03fc264 fffd 0001 c038e000 ff60: c039d540 c0392418 c03b7444 8001f200 41069264 8001f1cc c038ff94 c038ff88 ff80: c000 c0076d78 r5:c039d508 r4:c03fc260 [c0076d68] (__ipipe_sync_stage+0x0/0x268) from [c000] (__ipipe_unstall_root+0x3c/0x50) [c0077734] (__ipipe_unstall_root+0x0/0x50) from [c00257a8] (cpu_idle+0x64/0xcc) [c0025744] (cpu_idle+0x0/0xcc) from [c02c6eb0] (rest_init+0x78/0x8c) r7:c0392410 r6:c0020e14 r5:c0020e18 r4:c038e000 [c02c6e38] (rest_init+0x0/0x8c) from [c00089a4] (start_kernel+0x284/0x2e0) r5:c0020e18 r4:c0410190 [c0008720] (start_kernel+0x0/0x2e0) from [80008034] (0x80008034) r5:c03b74cc r4:00053175 ---[ end trace c83bf7139f281ac6 ]--- mx25-tsc mx25-tsc: mxc_tsc_read_ts: Failed to get data Do you know the meaning in xenomai of this error (so i can modify something to resolve the problem )? Thanks a lot -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt_task handle status after delete
Hi, it's ok to call rt_task_inquire after the task is deleted or the rt_task handle is invalid after a rt_task_delete ? Thanks for all -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] do rt_task_create after a deletion
Hi, if i don't want to use rt_task_join to wait termination on a task, is it correct to use rt_task_create and wait until the return value is different from -EEXIST after a deletion? Thanks for all -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] do rt_task_create after a deletion
Hi, i explain better. if i don't use rt_task_join i remove the flag T_JOINABLE, so i wait the task termination with a rt_task_create that return -EEXIST. Thanks Il 31/08/2011 09:12, Gilles Chanteperdrix ha scritto: On 08/31/2011 08:57 AM, Roberto Bielli wrote: Hi, if i don't want to use rt_task_join to wait termination on a task, Then do not create the task with the T_JOINABLE flag. is it correct to use rt_task_create and wait until the return value is different from -EEXIST after a deletion? I am not sure rt_task_create returns EEXIST when a task has been deleted but not joined. But in any case, the answer is no, a joinable task will not be joined automatically, only rt_task_join will cause it to be joined. -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt_task_suspend, rt_task_delete chooses wrong tasks
Hi,
i see a big problem in xenomai. Aftear a certain number of task deletion
(rt_task_delete) and re-create task
the RT_TASK descriptors that i have in my application don't match with
the correct task.
1. function for deleting the task.
int mtsuspendtask( int idTsk )
{
int err;
RT_TASK_INFO tskInfo;
RT_TASK_INFO tskInfoD;
rt_task_inquire( rt_task_self(), tskInfo );
//non sospendo task che non esistono
if((err = (rt_task_inquire (tabRtTask[idTsk].rtDesc, NULL ))) != 0)
{
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_inquire (ts): %s - err
%d (caller: %s), tabRtTask[idTsk].name, err, tskInfo.name );
return err;
}
err = rt_task_suspend ( tabRtTask[idTsk].rtDesc );
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_suspend : %s - err %d
(caller: %s), tabRtTask[idTsk].name, err, tskInfo.name );
if( err != 0 )
{
return err;
}
err = rt_task_delete (tabRtTask[idTsk].rtDesc);
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_delete : %s - err %d
(caller: %s), tabRtTask[idTsk].name, err, tskInfo.name );
if ((err != 0) (err != -3))
{
return (err);
}
while ((err = (rt_task_inquire (tabRtTask[idTsk].rtDesc, tskInfoD)))
== 0)
{
AltTraceInN(ALTRACE_LEV_OS_TASK, idTsk in tabella: %d, idTsk );
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_inquire : %s,
tskInfoD.name );
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_inquire : %s - err %d
(caller: %s), tabRtTask[idTsk].name, err, tskInfo.name );
mtsleep (2); //...rt_task_sleep( 4 milliseconds );
}
return (err);
}
2. function for creating the task
int mtresettask( int idTsk )
{
int err;
RT_TASK_INFO tskInfo;
rt_task_inquire( rt_task_self(), tskInfo );
memset( tabRtTask[idTsk].rtDesc, 0, sizeof( RT_TASK ) );
err = rt_task_create( tabRtTask[idTsk].rtDesc,
tabRtTask[idTsk].name,
tabRtTask[idTsk].stkSize,tabRtTask[idTsk].priority,tabRtTask[idTsk].mode);
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_create : %s - err %d
(caller: %s), tabRtTask[idTsk].name, err, tskInfo.name );
if( err != 0 )
return err;
err = rt_task_start( tabRtTask[idTsk].rtDesc, (void
(*)(void*))tabRtTask[idTsk].fnAddr, tabRtTask[idTsk].tskArgs );
AltTraceInN(ALTRACE_LEV_OS_TASK, rt_task_start : %s - err %d
(caller: %s), tabRtTask[idTsk].name, err, tskInfo.name );
return (err);
}
Thanks in advance
Best Regards
--
++
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.
++
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] rt_task_suspend, rt_task_delete chooses wrong tasks
Hi,
i send the source files with the initialization.
In the file apgs.c there is the main procedure that call the function
InitRTEnv() that initialize all.
Thanks a lot
Best regards
Il 01/08/2011 16:42, Gilles Chanteperdrix ha scritto:
Could you show us the code which initializes the rtDesc member of the
structure, in order to allow us reproducing your scenario?
--
++
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.
++
/** \file APgs.c
* Applicazione per eseguire PLC in tempo reale. Axel S.r.l. 2008
*
*/
#include stdio.h
#include sys/ucontext.h
#include unistd.h
#include stdlib.h
#include cext.h
#include fujitsu.h
#include pc.h
#include rttasks.h
#include sysgen.h
#include version.h
#include alplc/communication.h
#include alplc/plcmanager.h
#include TraceInput.h
#include TraceLog.h
/** versione Real time */
#define RT_VERSION AXEL S.R.L - NAME_ARM_APGS - v.
VERS_ARM_APGS - DATE_ARM_APGS
/** opzioni da linea di comando */
#define CMD_OPT p:hc:DM:
static boolean stopApplication;
/** gestore dei segnali di processo */
void sigHandler( int sig, siginfo_t *info,void *context )
{
ucontext_t *uc = (ucontext_t *)context;
int i = 0;
RT_TASK_INFO dstTaskSig;
if (! stopApplication)
{
for( i = 0; i NUMTASKS; i++ )
{
if( rt_task_inquire( tabRtTask[i].rtDesc, dstTaskSig )
== 0 ( dstTaskSig.status 0x380 ) == 0x380 )
{
AltTraceInN( ALTRACE_LEV_BASE, Il Task RT %s
ha generato un segnale: 0x%08X, dstTaskSig.name, dstTaskSig.status );
break;
}
}
switch( sig )
{
case SIGTERM:
AltTraceIn0( ALTRACE_LEV_BASE, Arrivato
segnale di SIGTERM );
break;
// case SIGINT:
// PrintTimeMex( TRUE,Arrivato segnale di SIGINT\n );
// break;
case SIGPIPE:
AltTraceIn0( ALTRACE_LEV_BASE,Arrivato segnale
di SIGPIPE );
break;
case SIGFPE:
AltTraceInN( ALTRACE_LEV_BASE,Arrivato segnale
di SIGFPE all'indirizzo: 0x%08x, uc-uc_mcontext.fault_address );
break;
case SIGSEGV:
AltTraceInN( ALTRACE_LEV_BASE,Arrivato segnale
di SIGSEGV all'indirizzo: 0x%08x, uc-uc_mcontext.fault_address );
signal( SIGSEGV, SIG_DFL );
break;
case SIGBUS:
AltTraceInN( ALTRACE_LEV_BASE, Arrivato segnale di SIGBUS
all'indirizzo: 0x%08x, uc-uc_mcontext.arm_pc);
signal( SIGBUS, SIG_DFL );
break
[Xenomai-core] gdb and lost priority
Hi, i know that debugging a user application with gdb can broke the task priority but also if i insert no breakpoints ? I explain better, in the 2.5.6 version a see that if i launch an application with gdbserver a task that has an inferior priority execute while another task with a high priority is running. It's possible or the task has switched on secondary mode ? Thanks for all ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt_task_delete or rt_task_suspend strange behavior
Hi, i'm using xenomai 2.5.6 stable implemented for Marvell mv78xx on Arm. I have a very strange behaviour. I have 60 tasks and some tasks delete other tasks. In the case that one task delete/suspend a task that is just deleted/suspended, the next delete/suspend kill the wrong task and if i print the sequence i see that rt_task_delete or rt_task_suspend returned the value -3 (-ESRCH) that is NOT documented in the manual. Unfortunately i can't send the source code because it's very large and i cannot see the problem with a small program. Any ideas ? Thanks for all ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] gdb and breakpoint
Hi, i have little questions. 1 .A GDB breakpoint in a xenomai task switch to secodary mode the task or the entire application ? 2. when i run the application that is halted on a breakpoint, when the xenomai scheduler enter to restore the task in primary mode, how does ? (i can say with assurancethe any other task goes before me when i release the breakpoint ) Thanks for all -- ++ 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. ++ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Fwd: Re: rt_task_delete doesn't work
Here is the example and the command.
RT_TASK pippo;
RT_TASK pluto;
void test1()
{
int err;
err = rt_task_delete(pippo );
if( err != 0 )
printf(error task delete\n);
}
int main (int argc, char *argv[])
{
//Porta di comunicazione
//int s;
mlockall(MCL_CURRENT|MCL_FUTURE);
// gestione signal handler
//struct sigaction sa;
//sa.sa_sigaction = (void *)sigHandler;
//sigemptyset (sa.sa_mask);
//sa.sa_flags = SA_SIGINFO;
//sigaction(SIGTERM,sa, NULL);
//sigaction(SIGINT,sa, NULL);
//sigaction(SIGPIPE,sa, NULL);
//sigaction(SIGFPE,sa, NULL);
//sigaction(SIGSEGV,sa, NULL);
char * namePippo = pippo;
char * namePluto = pluto;
int err;
err = rt_task_create(pippo, namePippo, 0x2000, 20, T_FPU );
if( err != 0 )
printf(error task create %s\n, namePippo );
err = rt_task_create(pluto, namePluto, 0x2000, 20, T_FPU );
if( err != 0 )
printf(error task create %s\n, namePluto );
err = rt_task_start(pluto, (void *)test1, NULL );
if( err != 0 )
printf(error task start %s\n, namePluto );
}
--COMMAND--
# gdb --args ./apgs -D
GNU gdb (GDB) 6.8.50.20080821-cvs
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as arm-mv5sft-linux-gnueabi.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
(gdb) r
`/flash/apgs' has disappeared; keeping its symbols.
Starting program: /flash/apgs -D
[Thread debugging using libthread_db enabled]
[New Thread 0x2acf7490 (LWP 537)]
[New Thread 0x2acfc490 (LWP 538)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2acfc490 (LWP 538)]
0x2aab9d74 in _dl_catch_error () from /lib/ld-linux.so.3
(gdb)
Il 10/06/2011 19:32, Gilles Chanteperdrix ha scritto:
On 06/10/2011 06:51 PM, Roberto Bielli wrote:
The segmentation fault was not on this code line.
i upgraded the version to 2.5.6 but the error is the same.
The fault is when i try to delete a realtime task from another realtime
task.
It's possible to do that ?
Please post a self-contained testcase. A self-contained test case is
worth a thousand words.
-
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 10.0.1382 / Database dei virus: 1513/3699 - Data di rilascio:
12/06/2011
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] rt_task_delete doesn't work
Hi,
the function rt_task_delete goes in segmentation fault.
this is the environment:
- kernel 2.6.31.8 arm marvell (test custom porting)
- xenomai 2.5.5.1
- the code:
int main (int argc, char *argv[])
{
//Porta di comunicazione
int s;
RT_TASK pippo;
int err;
mlockall(MCL_CURRENT|MCL_FUTURE);
// gestione signal handler
struct sigaction sa;
sa.sa_sigaction = (void *)sigHandler;
sigemptyset (sa.sa_mask);
sa.sa_flags = SA_SIGINFO;
sigaction(SIGTERM, sa, NULL);
sigaction(SIGINT, sa, NULL);
sigaction(SIGPIPE, sa, NULL);
sigaction(SIGFPE, sa, NULL);
sigaction(SIGSEGV, sa, NULL);
PrintTimeMex( TRUE,RT_VERSION\n );
unlink( LOGEXT_FILE );
err = rt_task_create( pippo, pippo, 0x2000, 20, T_FPU );
err = rt_task_delete( pippo );
...
...
...
Can anyone help me ?
Thanks for all
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
