Re: [Xenomai-help] Cross-link.c ---RTSER_RTIOC_WAIT_EVENT

2012-04-12 Thread Wolfgang Grandegger
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

2012-04-12 Thread Minh GIANG
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

2012-04-12 Thread Michael Pustylnik
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

2012-04-12 Thread Wolfgang Grandegger
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