On Fri, 2010-08-20 at 07:39 +0200, Philippe Gerum wrote:
> 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.
> >
Yeah, I mean... _that_ is a bug. Oh, well...
> > 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
