[Xenomai-help] xenomai thread crash

[Xenomai-help] xenomai thread crash

[yibo dai]

In my current project, there is a xenomai thread in the user space,It
doing the following things:
1.recieve the TIPC message from other services then handle it
2.recieve the packet from RTNet then handle it
Program is probably as follows:
while(1) {
	select(...); /*block and waiting for TIPC messages */
	/*do something*/
	
	do {
		ret = rt_dev_recvmsg(...,MSG_DONTWAIT); /*recieve packets from RTNet*/
		/* do something */
	} while(ret > 0);
}

the RTNet stack will trigger a virtual interrupt(use the
rtdm_nrtsig_pend) when recieved a packet,then the virtual interrupt
handler will send a SIGUSR2 to the xenomai thread,...,at last the
xenomai thread wake up.the problem is the xenomai thread will crash
when calling rt_dev_recvmsg sometimes.i found that
ops->operation##_nrt(i.e. ops->recvmsg_nrt) will be call(in the
MAJOR_FUNCTION_WRAPPER_TH),but ops->recvmsg_nrt is NULL,so the xenomai
thread crash.
is my usage wrong?why the current domain become linux when executing
xenomai syscall?by the way,what is the reason to remove
CONFIG_XENO_OPT_ISHIELD?
Thanks very much!!

[Xenomai-help] xenomai thread crash

[yibo dai]

In my current project, there is a xenomai thread in the user space,It
doing the following things:
1.recieve the TIPC message from other services then handle it
2.recieve the packet from RTNet then handle it
Program is probably as follows:
while(1) {
	select(...); /*block and waiting for TIPC messages */
	/*do something*/
	
	do {
		ret = rt_dev_recvmsg(...,MSG_DONTWAIT); /*recieve packets from RTNet*/
		/* do something */
	} while(ret > 0);
}

the RTNet stack will trigger a virtual interrupt(use the
rtdm_nrtsig_pend) when recieved a packet,then the virtual interrupt
handler will send a SIGUSR2 to the xenomai thread,...,at last the
xenomai thread wake up.the problem is the xenomai thread will crash
when calling rt_dev_recvmsg sometimes.i found that
ops->operation##_nrt(i.e. ops->recvmsg_nrt) will be call(in the
MAJOR_FUNCTION_WRAPPER_TH),but ops->recvmsg_nrt is NULL,so the xenomai
thread crash.
is my usage wrong?why the current domain become linux when executing
xenomai syscall?by the way,what is the reason to remove
CONFIG_XENO_OPT_ISHIELD?

system info:
Xenomai version:2.5.3/2.5.6
RTNet version:0.9.12
Linux version:2.6.28
Adeos patch:adeos-ipipe-2.6.28.10-arm-1.12-07.patch
processor:at91sam9260

Thanks very much!!

Re: [Xenomai-help] xenomai thread crash

[Gilles Chanteperdrix]

On 11/04/2011 03:42 AM, yibo dai wrote:
> In my current project, there is a xenomai thread in the user space,It
> doing the following things:
> 1.recieve the TIPC message from other services then handle it
> 2.recieve the packet from RTNet then handle it
> Program is probably as follows:
> while(1) {
> 	select(...); /*block and waiting for TIPC messages */
> 	/*do something*/
> 	
> 	do {
> 		ret = rt_dev_recvmsg(...,MSG_DONTWAIT); /*recieve packets from RTNet*/
> 		/* do something */
> 	} while(ret > 0);
> }
> 
> the RTNet stack will trigger a virtual interrupt(use the
> rtdm_nrtsig_pend) when recieved a packet,then the virtual interrupt
> handler will send a SIGUSR2 to the xenomai thread,...,at last the

When you do that, you cause the real-time thread to switch to secondary
mode, it means, it is no longer real-time, and using RTnet is in fact
pointless.

> xenomai thread wake up.the problem is the xenomai thread will crash
> when calling rt_dev_recvmsg sometimes.i found that
> ops->operation##_nrt(i.e. ops->recvmsg_nrt) will be call(in the
> MAJOR_FUNCTION_WRAPPER_TH),but ops->recvmsg_nrt is NULL,so the xenomai
> thread crash.

It is hard to say anything without seeing any code.

> is my usage wrong?

Yes.

why the current domain become linux when executing
> xenomai syscall?

Because you are executing a syscall which does so, not all syscalls do that.

by the way,what is the reason to remove
> CONFIG_XENO_OPT_ISHIELD?

It had problems of its own. Beside, it gave the false impression that
thread could have some real-time guarantees in secondary mode.

-- 
                                                                Gilles.