Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
> > Gilles Chanteperdrix wrote:
> > > Gilles Chanteperdrix wrote:
> > > > Wolfgang Grandegger wrote:
> > > > > Hi Gilles,
> > > > >
> > > > > Gilles Chanteperdrix wrote:
> > > > > > On Dec 6, 2007 3:05 PM, Wolfgang Grandegger <[EMAIL PROTECTED]>
> wrote:
> > > > > >> Gilles Chanteperdrix wrote:
> > > > > >>> On Dec 6, 2007 2:28 PM, Gilles Chanteperdrix
> > > > > >>> <[EMAIL PROTECTED]> wrote:
> > > > > >>>> On Dec 6, 2007 2:24 PM, Wolfgang Grandegger <[EMAIL
> PROTECTED]> wrote:
> > > > > >>>>> Gilles Chanteperdrix wrote:
> > > > > >>>>>> On Dec 6, 2007 1:31 PM, Wolfgang Grandegger <[EMAIL
> PROTECTED]> wrote:
> > > > > >>>>>>> Hello,
> > > > > >>>>>>>
> > > > > >>>>>>> how do I cancel or delete a Xenomai POSIX thread running
> in primary
> > > > > >>>>>>> context from a higher priority thread? IIUC,
> pthread_kill() can only be
> > > > > >>>>>>> used in secondary context. I tried pthread_cancel(), but
> it only works
> > > > > >>>>>>> when hitting a cancelation point, e.g.
> pthread_testcancel(). Setting
> > > > > >>>>>>> pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS) did not
> help. Is
> > > > > >>>>>>> there a code snippet or even an example program showing
> how to cancel a
> > > > > >>>>>>> pthread in primary context?
> > > > > >>>>>> pthread_kill or pthread_cancel should result in sending a
> signal to
> > > > > >>>>>> the target thread, so should cause this thread to switch to
> secondary
> > > > > >>>>>> mode to handle it. If you want to wait for the target
> thread to be
> > > > > >>>>>> canceled, you should use pthread_cancel and pthread_join.
> > > > > >>>>> There is no way to cancel a pthread in primary mode from
> another pthread?
> > > > > >>>> No. You always need secondary mode to effectively delete a
> thread. The
> > > > > >>>> same goes for the native skin.
> > > > > >>> Ok. I understand what you mean. You want pthread_cancel not to
> leave
> > > > > >>> primary mode. This can easily be done by causing
> pthread_cancel to use
> > > > > >>> the kernel-space real-time pthread_cancel service. This should
> work
> > > > > >>> with no further modification.
> > > > > >> I want to cancel/delete a task running in primary mode, e.g.
> > > > > >>
> > > > > >> void* work_task(void* dummy)
> > > > > >> {
> > > > > >> int count = 0;
> > > > > >> while (1)
> > > > > >> count++;
> > > > > >> }
> > > > > >>
> > > > > >> from the outside (= another higher priority task). How can I
> use the
> > > > > >> kernel-space real-time pthread_cancel service? My POSIX app is
> runs in
> > > > > >> user-land.
> > > > > >
> > > > > > I was thinking about adding a pthread_cancel syscall that would
> have
> > > > > > triggered the kernel-space pthread_cancel. But this will not
> work:
> > > > > > user-space cleanup handlers would no longer get executed.
> However,
> > > > > > this can work for pthread_kill. Here is a patch which adds the
> > > > > > pthread_kill syscall.
> > > > >
> > > > > Great, thanks a lot. This seems to work but I'm now fiddling with
> proper
> > > > > cleanup and exit. I have attached my small test program. It behaves
> > > > > somehow strange, at least to me:
> > > > >
> > > > > - I see task period overruns when the low prio task is started. I
> > > > > suspect some switch to secondary mode in init_task().
> > > > >
> > > > > - The program/system hangs after the listed messages:
> > > > >
> > > > > # ./kill_pthread
> > > > > Starting high_prio_task
> > > > > Killed low_prio task: count=3813129, overruns=0
> > > > >
> > > > > Any idea what I'm doing wrong?
> > > > >
> > > > > This is with Linux 2.4.25 and Xenomai 2.3.x on a MPC5200 board.
> > > >
> > > > Your test runs fine with Xenomai trunk (on ARM). I will now try with
> > > > current state of the v2.3.x branch.
> > >
> > > Works with v2.3.x too.
> >
> > I re-activated my test PC running Linux 2.6.20.21. with Xenomai 2.3.x.
> > There the program runs fine _without_ your pthread_kill patch. For some
> > reason the low_prio_task() is running in secondary mode (do you know
> > why? Is there a function to check the mode?). I added
> >
> > struct sched_param param = { .sched_priority = LOW_PRIO };
> > pthread_setschedparam(pthread_self(), SCHED_FIFO, ¶m);
> >
> > to the head of that function and then I get:
> >
> > ./kill_pthread
> > Starting high_prio_task
> > BUG: NMI Watchdog detected LOCKUP
> > Killed low_prio task: count=1588495996, overruns=0
> > Exiting main
> >
> > I have attached the corresponding oops in case it's of interest.
> > Unfortunately, with your patch and adding the function
> > __real_pthread_kill() to wrappers.c, the behavior is the same. I'm going
> > to repeat the tests with Xenomai trunk tomorrow.
>
> The oops is due to the NMI watchdog calling some linux domain functions
> over Xenomai domain. You should probably use Xenomai watchdog instead.
OK, the Xenomai watchdog might be another possibility to kill a pthread
blocking the system.
> As for the reason why the watchdog triggers: are you sure you are
> running the kernel recompiled after having applied the patch?
Yes, because:
# grep pthread_kill System.map
c015af9e T pthread_kill
c015f4e6 t __pthread_kill
c0390650 r __ksymtab_pthread_kill
c03968b8 r __kcrctab_pthread_kill
c039ce83 r __kstrtab_pthread_kill
But I will double-check again.
Wolfgang.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
