Wolfgang Grandegger wrote:
> Gilles Chanteperdrix wrote:
> > Wolfgang Grandegger wrote:
> > > 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.
> >
> > I tested the last program you posted, and it works on ARM (where I am
> > using linuxthreads, not NPTL), as far as I can tell. Could you send the
> > one that does not work ?
>
> Attached. On my MPC5200 it works with pthread_set_mode_np() in the
> counter loop of low_prio_thread(), but fails without.
This one works here. Maybe there is a problem with the I-pipe patch not
invoking signals handlers in some obscure case ?
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
