Gilles Chanteperdrix wrote: > Wolfgang Grandegger wrote: > > Gilles Chanteperdrix wrote: > > > Wolfgang Grandegger wrote: > > > > Gilles Chanteperdrix wrote: > > > > > On Dec 11, 2007 2:20 PM, Wolfgang Grandegger <[EMAIL PROTECTED]> > wrote: > > > > >> Wolfgang Grandegger wrote: > > > > >>> The attached test application using a more sophisticated signal > handling > > > > >>> works fine on my MPC5200-board running Linux 2.6.23 and Xenomai > trunk. > > > > >>> Going to try it tomorrow on my PC. > > > > >> It works fine as well on my PC with Linux 2.6.23 and Xenomai trunk > and > > > > >> now also with Linux 2.4.25 and Xenomai 2.3.x :-). Just to > understand it > > > > >> right: The task signaled with pthread_kill() will be suspended and > > > > >> switches to secondary mode if it was running in primary mode. The > signal > > > > >> will then be handled by Linux as usual. When the task resumes, > does it > > > > >> get switched back to primary mode automatically? > > > > > > > > > > No, it will get swtiched back to primary mode only if it calls a > > > > > service needing primary mode. > > > > > > > > OK. > > > > > > > > >> Great, the only open issue is why executing init_task() switches to > > > > >> secondary mode resulting in period overruns in high_prio_task(). > Is that > > > > >> obvious to you? > > > > > > > > > > init_task calls pthread_create, which needs running in secondary > mode > > > > > to create a thread. We can not create a task without help from > > > > > secondary mode. > > > > > > > > OK. > > > > > > > > I was a bit quick with my assumption that it works with 2.4. It > actually > > > > only works, if I have a pthread_set_mode_np() in the while loop of the > > > > primary task: > > > > > > > > while (1) { > > > > pthread_set_mode_np(0, PTHREAD_PRIMARY); > > > > count++; > > > > } > > > > > > > > Without pthread_set_mode_np(), the system hangs after the following > > > > output lines: > > > > > > > > bash-2.05b# ./kill_pthread2 > > > > Starting high_prio_task > > > > low_prio_task: policy=1 prio=5 > > > > SIGUSER1 to id_low: count=17497245, overruns=0 > > > > > > > > It seems to hang when the low_prio_task() calls pthread_wait_np() > > > > thereafter. Any quick idea where the problem is? > > > > > > I am clueless. Are you sure you recompiled the kernel after applying the > > > patch adding the pthread_kill syscall ? > > > > Well, I tried with v2.3.2, v2.3.x and also trunk, which does not require > > the patch. Unfortunately, all versions show the same behavior. > > Did you check all the system call return values to see if one of them is > not failing ?
pthread_kill() returns always 0, or what do you exactly mean. I also checked with printk() that ksrc/skins/posix/signal.c:pthread_kill() gets called. I realized the following behaviour if I call a printf after a certain count value: void* low_prio_task(void* dummy) { while (1) { count++; if (count == 100000000) printf("Wakeup\n"); } return 0; } Then the program goes on when the above count value is reached: Starting high_prio_task low_prio_task: policy=1 prio=5 SIGUSER1 to id_low: count=13819079, overruns=0 ... blocks for a while ... SIGUSER2 to id_low: count=27681649, overruns=0 suspend signal handler resume signal handler SIGUSER1 to id_low: count=100000000, overruns=0 SIGUSER2 to id_low: count=100000000, overruns=0 resume signal handler suspend signal handler SIGUSER1 to id_low: count=100000000, overruns=0 SIGUSER2 to id_low: count=100000000, overruns=0 ... This shows that the task did not get suspended before the printf is executed. And thereafter it never really resumes. Wolfgang. _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core