Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task

[Philippe Gerum <rpm@xenomai.org>]

On Wed, 2010-08-18 at 13:29 -0400, Herrera-Bendezu, Luis wrote:
> Philippe,
> 
> >-----Original Message-----
> >From: Philippe Gerum [mailto:rpm@xenomai.org]
> >Sent: Wednesday, August 18, 2010 12:39 PM
> >To: Herrera-Bendezu, Luis
> >Cc: xenomai@xenomai.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.