[Xenomai-help] IDDP send-receive example emits SIGXCPU signal
Hi
My environment looks like the following:
Xenomai 2.5.6
Used skin: Posix
Kernel 2.6.35.3
Target Environment: ARM
I have compiled the example iddp-sendrecv which can be found under
/examples/rtdm/profiles/ipc
(http://www.xenomai.org/documentation/xenomai-head/html/api/iddp-sendrecv_8c-example.html
)
with the existing makefile under the same directory. The binary seems to be
linking ok with the
xenomai libraries as you can also see here:
arm-linux-readelf -d iddp-sendrecv
Dynamic section at offset 0x1ed8 contains 32 entries:
Tag Type Name/Value
0x0001 (NEEDED) Shared library: [libpthread_rt.so.1]
0x0001 (NEEDED) Shared library: [libxenomai.so.0]
0x0001 (NEEDED) Shared library: [libpthread.so.0]
0x0001 (NEEDED) Shared library: [librt.so.1]
0x0001 (NEEDED) Shared library: [librtdm.so.1]
0x0001 (NEEDED) Shared library: [librtdk.so.0]
0x0001 (NEEDED) Shared library: [libc.so.6]
In order to test the real-timeliness of this piece of binary, I have added
one line of code to the beginning of the each thread (client and server)
pthread_set_mode_np(0, PTHREAD_WARNSW);
so that any switch from Primary to Secondary will be reported with a
SIGXCPU. My expectation was that I wouldnt see any switch to secondary
mode as IDDP is supposed to work between real time threads without hurting
their real-timeliness.
But I do get the SIGXCPU after adding the PTHREAD_WARNSW and the
gdb output says
Program received signal SIGXCPU, CPU time limit exceeded.
[Switching to Thread 0x2bc83470 (LWP 3401)]
0x2aad9894 in __wrap_socket () from /usr/xenomai/lib/libpthread_rt.so.1
so it looks like the __wrap_socket call in the posix skin hurts the
realtimeliness
of the threads when using IDDP. Do you have any idea why this may be
happening ?
If we look deeper in the posix skin where __wrap_socket is implemented
ret = XENOMAI_SKINCALL3(__rtdm_muxid,
__rtdm_socket,
protocol_family, socket_type, protocol);
if (ret >= 0)
ret += __rtdm_fd_start;
else if (ret == -EAFNOSUPPORT || ret == -ENOSYS) {
ret = __real_socket(protocol_family, socket_type, protocol);
if (ret >= __rtdm_fd_start) {
__real_close(ret);
errno = -EMFILE;
ret = -1;
}
looks like XENOMAI_SKINCALL3 macro is failing for some reason but I can't
explain this behavior as I am using the example code linked with the correct
xenomai libraries. Any help would be highly appreciated.
Thanks in advance
Guvenc
___
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal
On 11/11/2011 08:04 AM, Guvenc Gulce wrote: > looks like XENOMAI_SKINCALL3 macro is failing for some reason but I can't > > explain this behavior as I am using the example code linked with the correct > > xenomai libraries. Any help would be highly appreciated. Do you have support for iddp sockets enabled in kernel configuration? If yes, do you have the same issue with xenomai 2.6.0? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal
Yes.. I have enabled the support for iddp sockets in the kernel configuration. It looks like that it works with xenomai 2.6.0 when I enable the pthread_set_mode_np(0, PTHREAD_WARNSW); after the socket() and bind() calls. (tested again with the example code from xenomai) My question is: Is it designed that way that the calls socket() and bind() for IDDP cause a switch to secondary mode and the calls recvfrom() and sendto() do not ? In other words does the real-timeliness guarantee exist only for recvfrom() and sendto() ? Thanks & Regards Guvenc - Original Message - From: Gilles Chanteperdrix To: Guvenc Gulce Cc: "xenomai-help@gna.org" Sent: Friday, November 11, 2011 12:43 PM Subject: Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal On 11/11/2011 08:04 AM, Guvenc Gulce wrote: > looks like XENOMAI_SKINCALL3 macro is failing for some reason but I can't > > explain this behavior as I am using the example code linked with the correct > > xenomai libraries. Any help would be highly appreciated. Do you have support for iddp sockets enabled in kernel configuration? If yes, do you have the same issue with xenomai 2.6.0? -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal
On 11/23/2011 09:31 AM, Guvenc Gulce wrote: Yes.. I have enabled the support for iddp sockets in the kernel configuration. It looks like that it works with xenomai 2.6.0 when I enable the pthread_set_mode_np(0, PTHREAD_WARNSW); after the socket() and bind() calls. (tested again with the example code from xenomai) My question is: Is it designed that way that the calls socket() and bind() for IDDP cause a switch to secondary mode and the calls recvfrom() and sendto() do not ? In other words does the real-timeliness guarantee exist only for recvfrom() and sendto() ? No. socket() or bind() have no reason to switch to secondary mode, unless socket() fails for the AF_RTIPC domain, in which case the call is routed to the regular kernel to handle the address family. You not only need to enable IDDP in the kernel, but you also have to wrap POSIX calls to libpthread_rt services. If socket(AF_RTIPC, ...) failed reaching Xenomai/RTDM, then it will also fail with the regular kernel, and this call will return an error. Thanks& Regards Guvenc - Original Message - From: Gilles Chanteperdrix To: Guvenc Gulce Cc: "xenomai-help@gna.org" Sent: Friday, November 11, 2011 12:43 PM Subject: Re: [Xenomai-help] IDDP send-receive example emits SIGXCPU signal On 11/11/2011 08:04 AM, Guvenc Gulce wrote: looks like XENOMAI_SKINCALL3 macro is failing for some reason but I can't explain this behavior as I am using the example code linked with the correct xenomai libraries. Any help would be highly appreciated. Do you have support for iddp sockets enabled in kernel configuration? If yes, do you have the same issue with xenomai 2.6.0? -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
