Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
On 04/11/2012 10:51 PM, Minh GIANG wrote: ok for CC, i was afraid of spam everyone by my mail. I answer your questions. - non, i didn't modify cross-link program (even if i used to modify this program to make it run, but it worked the same way) - Xenomai 2.6 What version (cat /proc/xenomai/version)? - Linux 2.6.38 and patch Adeos 2.6.38 of course - i build the program in Eclipse C++ so my command in setting configuration is command : g++ All options: -l/usr/xenomai/include -O3 -wall -c -fmessage-length=0 That bogous! Please try the image created as shown below: $ cd xenomai-2.6-path/examples/rtdm/profiles/serial $ make XENO=/usr/xenomai/bin Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
Hello sir, Here is the message after doing your command: giang@debianrt:~/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial$ make XENO=/usr/xenomai/bin --xeno-cflags is deprecated, use --skin=name --cflags instead --xeno-ldflags is deprecated, use --skin=name --ldflags instead gcc -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ -L/usr/xenomai/lib -lxenomai -lpthread -lrt -lnative -lrtdm -Xlinker -rpath -Xlinker /usr/xenomai/lib cross-link.c -o cross-link cross-link.c: In function ‘write_task_proc’: cross-link.c:167: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘ssize_t’ cross-link.c:167: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’ cross-link.c: In function ‘read_task_proc’: cross-link.c:227: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘ssize_t’ cross-link.c:227: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’ giang@debianrt:~/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial$ ./cross-link Xenomai: binding failed: Operation not permitted. giang@debianrt:~/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial$ su Mot de passe : root@debianrt:/home/giang/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial# ./cross-link main : write-file opened main : write-config written main : read-file opened main : read-config written main : write-task created main : read-task created main : starting write-task main : starting read-task Nr | write-irq|irq-read| write-read | --- 0 | 104495 | 617720 | 722215 1 | 104649 | 617061 | 721710 2 | 104360 | 617820 | 722180 3 | 104906 | 617050 | 721956 4 | 105794 | 617188 | 722982 5 | 103504 | 618103 | 721607 6 | 104643 | 617084 | 721727 7 | 106633 | 617767 | 724400 oh, it seems to work perfectly, i don't know why it works in this case when i lauched it in the terminal linux, i copied exactly the program in Eclipse C++ and it doesn't work. Ah the only thing i have changed (otherwise my program don't compile in Eclipse), is static const struct rtser_config read_config = { 0x, 115200, RTSER_DEF_PARITY, RTSER_DEF_BITS, RTSER_DEF_STOPB, RTSER_DEF_HAND, RTSER_DEF_FIFO_DEPTH, RTSER_DEF_TIMEOUT, RTSER_DEF_TIMEOUT, 10, /* 1 s */ RTSER_RX_TIMESTAMP_HISTORY, RTSER_EVENT_RXPEND, }; static const struct rtser_config write_config = { RTSER_SET_BAUD | RTSER_SET_TIMESTAMP_HISTORY, 115200, RTSER_DEF_TIMESTAMP_HISTORY, /* the rest implicitely remains default */ }; maybe, i don't compile with good parameters in Eclipse? my version Xenomai 2.6.0 On Thu, Apr 12, 2012 at 9:52 AM, Wolfgang Grandegger w...@grandegger.comwrote: On 04/11/2012 10:51 PM, Minh GIANG wrote: ok for CC, i was afraid of spam everyone by my mail. I answer your questions. - non, i didn't modify cross-link program (even if i used to modify this program to make it run, but it worked the same way) - Xenomai 2.6 What version (cat /proc/xenomai/version)? - Linux 2.6.38 and patch Adeos 2.6.38 of course - i build the program in Eclipse C++ so my command in setting configuration is command : g++ All options: -l/usr/xenomai/include -O3 -wall -c -fmessage-length=0 That bogous! Please try the image created as shown below: $ cd xenomai-2.6-path/examples/rtdm/profiles/serial $ make XENO=/usr/xenomai/bin Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt latency greater than 250ms
The code masking the interrupt in IPIC (call for ipipe_pre_cascade_noeoi()) initially showed up in the patch you recommended (see your email attached). Later on it was integrated in Xenomai commit 9a5e42df8bccc59620c08caeb4b9fe92dbf94a1b. As shown in the trail below, it keeps interrupts all the time until the scheduler returns, thus breaking real-time responsiveness. A solution to this is probably to remove calling ipipe_pre_cascade_noeoi() and let the cascading handler mask the interrupt. Am I missing something? Do you think it is safe to use this solution? Michael Pustylnik, P.Eng. Senior Software Engineer RuggedCom Inc. www.ruggedcom.comhttp://www.ruggedcom.com/ 300 Applewood Crescent Concord, Ontario, L4K 5C7 Tel: (905)482-4523 Fax: (905)856-1995 From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Makarand Pradhan Sent: Wednesday, April 04, 2012 12:59 PM To: Philippe Gerum Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Interrupt latency greater than 250ms. Question. Hi Philippe, We have found that the problem is that the interrupt is unexpectedly held masked at the IPIC level for a long time. Please find the trace below: 2552 :| + func -544130.590 qe_ic_cascade_low_ipic+0x8 (__ipipe_ack_irq+0x2c) 2553 :| + func -544120.696 qe_ic_get_low_irq+0x8 (qe_ic_cascade_low_ipic+0x30) 2554 :| + func -544110.666 irq_linear_revmap+0x8 (qe_ic_get_low_irq+0x5c) MASK in IPIC (SIMSR_H register bit 1) 2555 :| + func -544110.606 ipic_mask_irq+0x8 (qe_ic_cascade_low_ipic+0x48) 2556 :| + func -544100.590 irqd_to_hwirq+0x8 (ipic_mask_irq+0x30) 2557 :| + func -544100.909 __ipipe_spin_lock_irqsave+0x8 (ipic_mask_irq+0x40) 2558 :| # func -544090.727 __ipipe_spin_unlock_irqrestore+0x8 (ipic_mask_irq+0xa8 ) 2559 :| + func -544080.560 __ipipe_qe_ic_cascade_irq+0x8 (qe_ic_cascade_low_ipic+ 0x5c) 2560 :| + begin 0x002b -544070.530 __ipipe_qe_ic_cascade_irq+0x2c (qe_ic_cascade_low_ipic +0x5c) 2561 :| + func -544070.651 __ipipe_handle_irq+0x8 (__ipipe_qe_ic_cascade_irq+0x38 ) 2562 :| + func -544060.939 __ipipe_ack_level_irq+0x8 (__ipipe_handle_irq+0xbc) MASK in QUICC (CIMR register bit 11) 2563 :| + func -544050.787 qe_ic_mask_irq+0x8 (__ipipe_ack_level_irq+0x40) XENOMAI SCHEDULER IS INVOKED 2576 :| # func -543930.590 __xnpod_schedule+0x8 (xnintr_irq_handler+0x1f8) UNMASK in QUICC (done by our user space handler) 2595 : + func -543770.621 __rt_intr_enable+0x8 [xeno_native] (hisyscall_event+0x 1e4) UNMASK in IPIC (after 50ms, i.e. only after the scheduler returns): 31637 :| #end 0x002b -518+ 2.272 __ipipe_qe_ic_cascade_irq+0x40 (qe_ic_cascade_low_ipic+ 0x5c) 31638 :| #func-516+ 1.090 ipic_unmask_irq+0x8 (qe_ic_cascade_low_ipic+0x70) As you can see from the trace above, the interrupt is held masked at the IPIC level all the time until the Xenomai scheduler returns and is only unmasked after that. Is it really the way it should be? Shouldn't the interrupt be unmasked at the IPIC level right after masking it at the QUICC engine level? Rgds, Mak. On 28/03/12 02:23 PM, Makarand Pradhan wrote: Hi Philippe, On 28/03/12 12:17 PM, Philippe Gerum wrote: The log says your code wants to control when the IRQ is enabled again, by calling rt_intr_enable() from userland. I guess you are setting I_NOAUTOENA too. Correct? That is correct. I_NOAUTOENA is used in rt_intr_create. Otherwise the level trigerred interrupt will not allow the userland processing of the int. The userland handler is very small and it unconditionally rt_intr_enables the intr. Testing indicates that the interrupt is always enabled from user space within 250 usec after kernel gets the interrupt. I have noted that unless I see #end 0x002b and a hit to the ipic_unmask_irq, the next interrupt is not processed. And this is getting delayed once in a while which causes a delay in processing the next interrupt. So the sequence of events leading to the problem is: 1. Get interrupt: #begin 0x002b noted in ipipe trace 2. Intr enabled from user space. Always happens roughly within 250usec. 3. #end 0x002b noted in ipipe trace where the int is unmasked by ipipe. When I see the problem, step 3 is delayed. I am trying to capture a trace where the begin, int enable and end are captured. Your thoughts on what might cause this delay would be appreciated. Rgds, Mak. -- ___ NOTICE OF CONFIDENTIALITY: This e-mail and any attachments may contain confidential and privileged information. If you
Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT
On 04/12/2012 10:51 AM, Minh GIANG wrote: Hello sir, Here is the message after doing your command: giang@debianrt:~/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial$ make XENO=/usr/xenomai/bin --xeno-cflags is deprecated, use --skin=name --cflags instead --xeno-ldflags is deprecated, use --skin=name --ldflags instead gcc -I/usr/xenomai/include -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ -L/usr/xenomai/lib -lxenomai -lpthread -lrt -lnative -lrtdm -Xlinker -rpath -Xlinker That's how the program should be comiled and linked. /usr/xenomai/lib cross-link.c -o cross-link cross-link.c: In function ‘write_task_proc’: cross-link.c:167: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘ssize_t’ cross-link.c:167: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’ cross-link.c: In function ‘read_task_proc’: cross-link.c:227: warning: format ‘%d’ expects type ‘int’, but argument 2 has type ‘ssize_t’ cross-link.c:227: warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘ssize_t’ giang@debianrt:~/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial$ ./cross-link Xenomai: binding failed: Operation not permitted. giang@debianrt:~/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial$ su Mot de passe : root@debianrt:/home/giang/Documents/xenomai-2.6.0/examples/rtdm/profiles/serial# ./cross-link main : write-file opened main : write-config written main : read-file opened main : read-config written main : write-task created main : read-task created main : starting write-task main : starting read-task Nr | write-irq|irq-read| write-read | --- 0 | 104495 | 617720 | 722215 1 | 104649 | 617061 | 721710 2 | 104360 | 617820 | 722180 3 | 104906 | 617050 | 721956 4 | 105794 | 617188 | 722982 5 | 103504 | 618103 | 721607 6 | 104643 | 617084 | 721727 7 | 106633 | 617767 | 724400 oh, it seems to work perfectly, i don't know why it works in this case when i lauched it in the terminal linux, i copied exactly the program in Eclipse C++ and it doesn't work. Ah the only thing i have changed (otherwise my program don't compile in Eclipse), is static const struct rtser_config read_config = { 0x, 115200, RTSER_DEF_PARITY, RTSER_DEF_BITS, RTSER_DEF_STOPB, RTSER_DEF_HAND, RTSER_DEF_FIFO_DEPTH, RTSER_DEF_TIMEOUT, RTSER_DEF_TIMEOUT, 10, /* 1 s */ RTSER_RX_TIMESTAMP_HISTORY, RTSER_EVENT_RXPEND, }; static const struct rtser_config write_config = { RTSER_SET_BAUD | RTSER_SET_TIMESTAMP_HISTORY, 115200, RTSER_DEF_TIMESTAMP_HISTORY, /* the rest implicitely remains default */ }; maybe, i don't compile with good parameters in Eclipse? Yes, that's your problem. And exactly to avoid such problems, Xenomai provides the script xeno-config to retrieve proper compiler and linker options. my version Xenomai 2.6.0 I also recommend to update to a more recent version. Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help