On Wed, 2010-08-18 at 13:29 -0400, Herrera-Bendezu, Luis wrote: > Philippe, > > >-----Original Message----- > >From: Philippe Gerum [mailto:r...@xenomai.org] > >Sent: Wednesday, August 18, 2010 12:39 PM > >To: Herrera-Bendezu, Luis > >Cc: xenomai-help@gna.org > >Subject: Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime > >task > > > > > >On Wed, 2010-08-18 at 12:03 -0400, Herrera-Bendezu, Luis wrote: > >> Hello: > >> > >> I am using Xenomai 2.4.10 on PPC. An RTDM driver creates an RTDM task > >> using rtdm_task_init() and goes to sleep periodically via function > >> rtdm_task_sleep(). > >> > >> When driver is loaded, RTDM task executes as expected. Then a realtime > >> application is started via gdbserver on target board and on a linux host > >> a gdb client is connected to that board. As soon as gdb breakpoints the > >> realtime application the RTDM task never returns from rtdm_task_sleep(). > >> The application does not open the RTMD driver so at this point there is > >> no interaction with the driver. > >> > >> The RTDM task is intr_sim and the timer is no longer firing > >> # cat /proc/xenomai/timerstat/master > >> CPU SCHEDULED FIRED TIMEOUT INTERVAL HANDLER NAME > >> 0 29198042 9132085 3724750 - NULL > >> [host-timer] > >> 0 1340 1340 - - xnthread_ti intr_sim > >> > >> The realtime application is ancvbirt. > >> # cat /proc/xenomai/sched > >> CPU PID PRI PERIOD TIMEOUT TIMEBASE STAT NAME > >> 0 0 -1 0 0 master R ROOT > >> 0 0 90 0 0 master D intr_sim > >> 0 1869 0 0 0 master XT ancvbirt > >> > >> Any ideas on the cause of the problem and fix? > > > >This is a side-effect of hitting a breakpoint in your application > >introduced by Xenomai: all Xenomai timers are frozen system-wide, until > >the application is continued. This includes the per-thread timer which > >is used to have your RTDM task wake up after a delay. > After continuing the application, the RTDM task does not resume execution. > I had to reload driver to have it working again. > > > >There is a way to prevent this behavior, which was defined for internal > >purposes only so far. Since Jan is not watching, here is a patch against > >2.4.10 which happily butchers his nifty interface, that should prevent > >the per-thread timers of _all_ RTDM tasks from being blocked in that > >case, which may be enough to help you though: > > > >diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c > >index 65c630f..0295690 100644 > >--- a/ksrc/skins/rtdm/drvlib.c > >+++ b/ksrc/skins/rtdm/drvlib.c > >@@ -144,6 +144,7 @@ int rtdm_task_init(rtdm_task_t *task, const char *name, > > res = xnpod_init_thread(task, rtdm_tbase, name, priority, 0, 0, NULL); > > if (res) > > goto error_out; > >+ task->rtimer.status |= XNTIMER_NOBLCK; > > > > if (period > 0) { > > res = xnpod_set_thread_periodic(task, XN_INFINITE, > >@@ -151,6 +152,7 @@ int rtdm_task_init(rtdm_task_t *task, const char *name, > > (rtdm_tbase, period)); > > if (res) > > goto cleanup_out; > >+ task->ptimer.status |= XNTIMER_NOBLCK; > > } > > > > res = xnpod_start_thread(task, 0, 0, XNPOD_ALL_CPUS, task_proc, arg); > > > Yes, this patch avoids stopping the timers. I see the value on stopping the > timers on the RTDM driver when application hits a breakpoint but for some > reason timer does not recover. I am using Linux 2.6.30.
Could you paste the output from: /proc/xenomai/stat /proc/xenomai/timerstat/master after the application has resumed execution? TIA, -- Philippe. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
