All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [Xenomai-help] rt_queue_read switch to secondary mode
@ 2006-10-20 23:37 Sunny Bhuller
  2006-10-21  0:09 ` Philippe Gerum
  0 siblings, 1 reply; 7+ messages in thread
From: Sunny Bhuller @ 2006-10-20 23:37 UTC (permalink / raw)
  To: rpm; +Cc: xenomai

Hi Philippe,

  I don't think the signal is occuring due to pthread_exit().  If you put the rt_queue_read call in a loop you will see that the signal occurs on every call to rt_queue_read.  

...
	while (1)
 	{
		rt_queue_read( msq_q, &data, sizeof ( some_data ), TM_NONBLOCK);
		rt_task_sleep((RTIME) 100000);
	}
...

  The back trace produced the following output for me.

(gdb) r
Starting program: /root/ipas/apps/skel/test
[Thread debugging using libthread_db enabled]
[New Thread -1211189568 (LWP 15101)]
[New Thread -1208869968 (LWP 15104)]

Program received signal SIGXCPU, CPU time limit exceeded.
[Switching to Thread -1208869968 (LWP 15104)]
0xffffe410 in ?? ()
(gdb) bt
#0  0xffffe410 in ?? ()
#1  0xb7f20fe8 in ?? ()
#2  0x00000400 in ?? ()
#3  0xb7f21010 in ?? ()
#4  0xb7ef2c72 in rt_queue_read () from /usr/xenomai/lib/libnative.so.0
#5  0x08048852 in task_procedure (arg=0xbf93a640) at test.cpp:23
#6  0xb7ef3141 in rt_task_trampoline () from /usr/xenomai/lib/libnative.so.0
#7  0xb7efb0fb in start_thread () from /lib/tls/libpthread.so.0
#8  0xb7da399e in clone () from /lib/tls/libc.so.6
(gdb)


  Let me know if you see something wrong.
-- Sunny





----- Original Message -----
From: Philippe Gerum <rpm@xenomai.org>
Date: Friday, October 20, 2006 5:11 pm
Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode

> On Fri, 2006-10-20 at 16:00 -0600, Sunny Bhuller wrote:
> > Hi Philippe,
> >   I am including some code below that will produce the problem I 
> am seeing. 
> > I must be missing something because if remove the force to 
> primary mode in the
> >  function task_procedure the signal will not be caught.  This 
> tells me that
> >  without the rt_task_set_mode the task is starting off in 
> secondary mode.  
> > 
> 
> The backtrace of your program is this one when SIGXCPU is caught:
> 
> (gdb) r
> Starting program: /home/rpm/frags/secondary/main
> [Thread debugging using libthread_db enabled]
> [New Thread -1210504992 (LWP 18784)]
> [New Thread -1209074768 (LWP 18787)]
> 
> Program received signal SIGXCPU, CPU time limit exceeded.
> [Switching to Thread -1209074768 (zombie)]
> 0xb7f02634 in calloc () from /lib/ld-linux.so.2
> (gdb) bt
> #0  0xb7f02634 in calloc () from /lib/ld-linux.so.2
> #1  0xb7ef9110 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #2  0xb7ef8b01 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #3  0xb7e93200 in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> #4  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #5  0xb7e92c6f in _dl_open () from /lib/tls/i686/cmov/libc.so.6
> #6  0xb7e9548d in __libc_dlsym () from /lib/tls/i686/cmov/libc.so.6
> #7  0xb7efd43f in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2
> #8  0xb7e954ee in __libc_dlopen_mode ()
> from /lib/tls/i686/cmov/libc.so.6
> #9  0xb7ed7398 in pthread_cancel_init ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #10 0xb7ed74c1 in _Unwind_ForcedUnwind ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #11 0xb7ed51f1 in __pthread_unwind ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #12 0xb7ed1210 in pthread_exit ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #13 0xb7ec832a in rt_task_trampoline (cookie=0xbfcbb750)
>    at /home/rpm/xenomai-2.2.4/src/skins/native/task.c:93
> #14 0xb7ed0240 in start_thread ()
> from /lib/tls/i686/cmov/libpthread.so.0
> #15 0xb7e5e29e in clone () from /lib/tls/i686/cmov/libc.so.6
> (gdb)
> 
> This means that the signal was sent as a result of performing a 
> calloc()call, during the late binding of some dynamic library on 
> behalf of
> pthread_exit(), which gets called as your real-time task exits
> immediately after the non-blocking call to rt_queue_read(). So 
> this is
> ok. The following patch should better illustrate the issue:
> 
> --- main.c~	2006-10-21 00:15:19.000000000 +0200
> +++ main.c	2006-10-21 00:27:52.000000000 +0200
> @@ -18,7 +18,7 @@
>         some_data data;
> 
>         rt_queue_read( msq_q, &data, sizeof ( some_data ), 
> TM_NONBLOCK);        
> -        
> +	rt_task_suspend(NULL);
> }
> 
> void signal_handler(int sig)
> 
> PS: the call to rt_task_set_mode() in the main() function always 
> fails,since the main routine is not a Xenomai-thread when started. 
> Therefore,the call - which requires to be invoked by Xenomai 
> threads - always
> returns with -EPERM. Note: this behaviour may differ depending on the
> skin bound to the application; for instance, the POSIX skin
> automatically promotes the main code as a Xenomai-controlled 
> thread, but
> the native skin does not (maybe we should, though).
> 
> -- 
> Philippe.
> 
> 
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread
* Re: [Xenomai-help] rt_queue_read switch to secondary mode
@ 2006-10-20 22:00 Sunny Bhuller
  2006-10-20 23:11 ` Philippe Gerum
  0 siblings, 1 reply; 7+ messages in thread
From: Sunny Bhuller @ 2006-10-20 22:00 UTC (permalink / raw)
  To: rpm; +Cc: xenomai

Hi Philippe,
  I am including some code below that will produce the problem I am seeing.  I must be missing something because if remove the force to primary mode in the function task_procedure the signal will not be caught.  This tells me that without the rt_task_set_mode the task is starting off in secondary mode.  

//------ Start

#include <signal.h>
#include <sys/mman.h>
#include <inttypes.h>
#include <native/task.h>
#include <native/queue.h>


typedef struct {
	uint8_t data[1024]; 
} __attribute__((packed)) some_data;


void task_procedure(void *arg)
{
	RT_QUEUE *msq_q = (RT_QUEUE *)arg;
	rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

	some_data data;

	rt_queue_read( msq_q, &data, sizeof ( some_data ), TM_NONBLOCK);	
	
}

void signal_handler(int sig)
{
	if (sig == SIGXCPU)
		printf("---!! uh oh, switched to secondary mode !!--\n");
}


int main(int argc, char *argv[])
{
	RT_QUEUE msg_q;
	RT_TASK msg_task;

    	mlockall(MCL_CURRENT | MCL_FUTURE);

	rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

	signal(SIGXCPU, signal_handler);

	rt_queue_create( &msg_q, "phil_test", sizeof(some_data), Q_UNLIMITED, Q_FIFO | Q_SHARED );

        rt_task_create(&msg_task, NULL, 0, 5, T_FPU | T_JOINABLE);
	rt_task_start(&msg_task, &task_procedure, &msg_q );

	rt_task_join( &msg_task );
	rt_task_delete( &msg_task );
	rt_queue_delete( &msg_q );

	return 0;
}


//-------- END


----- Original Message -----
From: Philippe Gerum <rpm@xenomai.org>
Date: Friday, October 20, 2006 2:59 pm
Subject: Re: [Xenomai-help] rt_queue_read switch to secondary mode

> On Fri, 2006-10-20 at 14:50 -0600, Sunny Bhuller wrote:
> > Hello,
> >   I am new to xenomai and was having a problem with the 
> rt_queue_read call.  I am creating a new RT_TASK from my main 
> program with:
> > 
> > rt_task_create(&task, NULL, 0 /* default stack size */, 5 /* 
> priority */, T_FPU | T_JOINABLE);
> > 
> > Once the task has started I switch it to primary mode with:
> > 
> > rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);
> 
> Forcing to primary is useless, every real-time task starts in primary
> mode, regardless of the relevant skin.
> 
> > 
> > Now if I call the rt_queue_read I catch the signal that 
> specifies the system has switched to secondary mode.  Is there 
> something fundamentally wrong with what I am doing?  I can post a 
> more detailed explanation if required, thanks!
> > 
> 
> There is no reason for rt_queue_read() to move the thread to secondary
> mode. You should try running the app over GDB, and inspect the 
> backtracewhen the signal is received; you might discover that some 
> other code
> does cause this, or you might discover that we indeed have a bug 
> hidingsomewhere. Posting a simple but complete test code that 
> reproduces the
> issue unambiguously would help too.
> 
> > -- Sunny
> > 
> > 
> > 
> > _______________________________________________
> > Xenomai-help mailing list
> > Xenomai-help@domain.hid
> > https://mail.gna.org/listinfo/xenomai-help
> -- 
> Philippe.
> 
> 
> 



^ permalink raw reply	[flat|nested] 7+ messages in thread
* [Xenomai-help] rt_queue_read switch to secondary mode
@ 2006-10-20 20:50 Sunny Bhuller
  2006-10-20 20:59 ` Philippe Gerum
  0 siblings, 1 reply; 7+ messages in thread
From: Sunny Bhuller @ 2006-10-20 20:50 UTC (permalink / raw)
  To: xenomai

Hello,
  I am new to xenomai and was having a problem with the rt_queue_read call.  I am creating a new RT_TASK from my main program with:

rt_task_create(&task, NULL, 0 /* default stack size */, 5 /* priority */, T_FPU | T_JOINABLE);

Once the task has started I switch it to primary mode with:

rt_task_set_mode(0, T_PRIMARY | T_WARNSW, NULL);

Now if I call the rt_queue_read I catch the signal that specifies the system has switched to secondary mode.  Is there something fundamentally wrong with what I am doing?  I can post a more detailed explanation if required, thanks!

-- Sunny




^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-10-24  0:28 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-20 23:37 [Xenomai-help] rt_queue_read switch to secondary mode Sunny Bhuller
2006-10-21  0:09 ` Philippe Gerum
2006-10-24  0:28   ` Sunny
  -- strict thread matches above, loose matches on Subject: below --
2006-10-20 22:00 Sunny Bhuller
2006-10-20 23:11 ` Philippe Gerum
2006-10-20 20:50 Sunny Bhuller
2006-10-20 20:59 ` Philippe Gerum

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.