On Thu, 2010-08-19 at 13:13 -0400, Herrera-Bendezu, Luis wrote:
> Philippe,
>
> Yes, the patch you sent me works, timers do not stop and RTDM task in my
> driver continuous to run when realtime app is stopped by debugger.
>
Ah. Ok, so _that_ is a bug.
> My statement bellow was not clear. I meant that on the unpatched kernel,
> resuming execution of realtime app does not resume execution of the RTDM task.
>
> There are two functions lock_/unlock_timers(), are these functions used
> to stop/start timers when a breakpoint is hit? If yes, I can put some
> tracing information to check if timers are unblocked.
Yes, those are the functions involved in this issue, and unlock_timers()
is expected to unblock all timers belonging to the master time base,
which it does. However, the timing code is messing badly when it comes
to postpone non-periodic timers while the time base is locked, hence the
bug. Could you try this patch? TIA,
diff --git a/ksrc/nucleus/timer.c b/ksrc/nucleus/timer.c
index 5fe8d08..828244a 100644
--- a/ksrc/nucleus/timer.c
+++ b/ksrc/nucleus/timer.c
@@ -283,9 +283,9 @@ void xntimer_tick_aperiodic(void)
{
xnsched_t *sched = xnpod_current_sched();
xntimerq_t *timerq = &sched->timerqueue;
+ xnticks_t now, interval;
xntimerh_t *holder;
xntimer_t *timer;
- xnticks_t now;
/* Optimisation: any local timer reprogramming triggered by invoked
timer handlers can wait until we leave the tick handler. Use this
@@ -324,8 +324,8 @@ void xntimer_tick_aperiodic(void)
/* Postpone the next tick to a reasonable date
in
the future, waiting for the timebase to be
unlocked
at some point. */
- xntimerh_date(&timer->aplink) =
xntimerh_date(&sched->htimer.aplink);
- continue;
+ interval = xnarch_ns_to_tsc(500000000ULL);
+ goto requeue;
}
} else {
/* By postponing the propagation of the low-priority
host
@@ -337,8 +337,10 @@ void xntimer_tick_aperiodic(void)
continue;
}
+ interval = timer->interval;
+ requeue:
do {
- xntimerh_date(&timer->aplink) += timer->interval;
+ xntimerh_date(&timer->aplink) += interval;
} while (xntimerh_date(&timer->aplink) < now + nklatency);
xntimer_enqueue_aperiodic(timer);
}
>
> Luis
>
> >-----Original Message-----
> >From: Philippe Gerum [mailto:[email protected]]
> >Sent: Thursday, August 19, 2010 12:43 PM
> >To: Herrera-Bendezu, Luis
> >Cc: [email protected]
> >Subject: RE: [Xenomai-help] RTDM task blocks when connecting gdb to realtime
> >task
> >
> >
> >On Thu, 2010-08-19 at 08:26 -0400, Herrera-Bendezu, Luis wrote:
> >> >-----Original Message-----
> >> >From: Philippe Gerum [mailto:[email protected]]
> >> >Sent: Wednesday, August 18, 2010 4:44 PM
> >> >To: Herrera-Bendezu, Luis
> >> >Cc: [email protected]
> >> >Subject: RE: [Xenomai-help] RTDM task blocks when connecting gdb to
> >> >realtime task
> >> >
> >> >
> >> >On Wed, 2010-08-18 at 13:29 -0400, Herrera-Bendezu, Luis wrote:
> >> >> Philippe,
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: Philippe Gerum [mailto:[email protected]]
> >> >> >Sent: Wednesday, August 18, 2010 12:39 PM
> >> >> >To: Herrera-Bendezu, Luis
> >> >> >Cc: [email protected]
> >> >> >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.
> >> >
> >> Status with application at breakpoint:
> >> # cat /proc/xenomai/stat
> >> CPU PID MSW CSW PF STAT %CPU NAME
> >> 0 0 0 14984 0 00400080 99.7 ROOT
> >> 0 0 0 3976 0 00000084 0.0 intr_sim
> >> 0 1261 1 1 1 00301380 0.0 ancvbirt
> >> 0 0 0 0 0 00000000 0.0 IRQ22:
> >> _vip_fpga_co...@2000000_r
> >> 0 0 0 337375 0 00000000 0.2 IRQ512: [timer]
> >>
> >> # cat /proc/xenomai/timerstat/master
> >> CPU SCHEDULED FIRED TIMEOUT INTERVAL HANDLER NAME
> >> 0 1005240 326161 1844335 - NULL
> >> [host-timer]
> >> 0 3976 3976 - - xnthread_ti intr_sim
> >>
> >> Status of application after application execution is resumed:
> >> # cat /proc/xenomai/stat
> >> CPU PID MSW CSW PF STAT %CPU NAME
> >> 0 0 0 15034 0 00400080 99.6 ROOT
> >> 0 0 0 3976 0 00000084 0.0 intr_sim
> >> 0 1261 2 2 2 00300380 0.0 ancvbirt
> >> 0 0 0 0 0 00000000 0.0 IRQ22:
> >> _vip_fpga_co...@2000000_r
> >> 0 0 0 428462 0 00000000 0.4 IRQ512: [timer]
> >>
> >> # cat /proc/xenomai/timerstat/master
> >> CPU SCHEDULED FIRED TIMEOUT INTERVAL HANDLER NAME
> >> 0 1314446 412961 410890 - NULL
> >> [host-timer]
> >> 0 3976 3976 - - xnthread_ti intr_sim
> >> 0 5 2 - - xnthread_ti
> >> AncVbiRt-in-int
> >> 0 4 1 - - xnthread_ti
> >> AncVbiRt-out-in
> >> 0 2 2 - - xnthread_ti
> >> AncVbiRt-client
> >> 0 3 1 - - xnthread_ti
> >> AncVbiRt-tsout
> >> 0 3 1 - - xnthread_ti
> >> AncVbiRt-pudi
> >> 0 1 1 - - xnthread_ti
> >> AncVbiRt-ancx
> >> 0 1 0 - - xnthread_ti
> >> AncVbiRt-vbix
> >> 0 1 0 - - xnthread_ti
> >> AncVbiRt-gpispl
> >>
> >> Notes:
> >> 1. GNU gdb Red Hat Linux (6.7-1rh)
> >> 2. GNU gdbserver Red Hat Linux (6.7-1rh)
> >> 3. set gdb to not stop/print/pass SIGXCPU signal.
> >> 4. Same behavior if program is executed within gdb and no breakpoints.
> >
> >Please check that you are running the modified kernel, and specifically
> >the updated xeno_rtdm module. This patch does work as expected.
> >
> >>
> >> Thanks,
> >> Luis
> >
> >--
> >Philippe.
> >
>
--
Philippe.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
