* [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
@ 2010-08-18 16:03 Herrera-Bendezu, Luis
2010-08-18 16:20 ` Gilles Chanteperdrix
2010-08-18 16:38 ` Philippe Gerum
0 siblings, 2 replies; 18+ messages in thread
From: Herrera-Bendezu, Luis @ 2010-08-18 16:03 UTC (permalink / raw)
To: xenomai
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?
Thanks,
Luis G. Herrera-Bendezu
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-18 16:03 [Xenomai-help] RTDM task blocks when connecting gdb to realtime task Herrera-Bendezu, Luis
@ 2010-08-18 16:20 ` Gilles Chanteperdrix
2010-08-18 16:38 ` Philippe Gerum
1 sibling, 0 replies; 18+ messages in thread
From: Gilles Chanteperdrix @ 2010-08-18 16:20 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
Herrera-Bendezu, Luis wrote:
> 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.
> (...)
>
> Any ideas on the cause of the problem and fix?
That is a feature actually, in order to help you debug your application,
all timers in the system are stopped. So, the rtdm task will only
return from rtdm_task_sleep when you will type "continue" in gdb.
The timer which have the XNTIMER_NOBLCK bit are not stopped, but setting
this bit cleanly will need extensions of the RTDM driver API.
--
Gilles.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-18 16:03 [Xenomai-help] RTDM task blocks when connecting gdb to realtime task Herrera-Bendezu, Luis
2010-08-18 16:20 ` Gilles Chanteperdrix
@ 2010-08-18 16:38 ` Philippe Gerum
2010-08-18 17:29 ` Herrera-Bendezu, Luis
1 sibling, 1 reply; 18+ messages in thread
From: Philippe Gerum @ 2010-08-18 16:38 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
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.
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);
NOTE: please don't take this patch as an official way to handle this
issue, it is not. It's an ugly kludge, until we find a better way to
selectively enable this behavior for built-in timers (2.5.x has a way to
do this for user-defined timers already, it is called
xntimer_init_noblock()).
>
> Thanks,
> Luis G. Herrera-Bendezu
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-18 16:38 ` Philippe Gerum
@ 2010-08-18 17:29 ` Herrera-Bendezu, Luis
2010-08-18 20:44 ` Philippe Gerum
0 siblings, 1 reply; 18+ messages in thread
From: Herrera-Bendezu, Luis @ 2010-08-18 17:29 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe,
>-----Original Message-----
>From: Philippe Gerum [mailto:rpm@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.
>NOTE: please don't take this patch as an official way to handle this
>issue, it is not. It's an ugly kludge, until we find a better way to
>selectively enable this behavior for built-in timers (2.5.x has a way to
>do this for user-defined timers already, it is called
>xntimer_init_noblock()).
>
>>
>> Thanks,
>> Luis G. Herrera-Bendezu
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@gna.org
>> https://mail.gna.org/listinfo/xenomai-help
>
>--
>Philippe.
>
Thanks,
Luis
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-18 17:29 ` Herrera-Bendezu, Luis
@ 2010-08-18 20:44 ` Philippe Gerum
2010-08-19 12:26 ` Herrera-Bendezu, Luis
0 siblings, 1 reply; 18+ messages in thread
From: Philippe Gerum @ 2010-08-18 20:44 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-18 20:44 ` Philippe Gerum
@ 2010-08-19 12:26 ` Herrera-Bendezu, Luis
2010-08-19 16:42 ` Philippe Gerum
0 siblings, 1 reply; 18+ messages in thread
From: Herrera-Bendezu, Luis @ 2010-08-19 12:26 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
>-----Original Message-----
>From: Philippe Gerum [mailto:rpm@xenomai.org]
>Sent: Wednesday, August 18, 2010 4:44 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 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-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.
>
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_codec@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_codec@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.
Thanks,
Luis
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-19 12:26 ` Herrera-Bendezu, Luis
@ 2010-08-19 16:42 ` Philippe Gerum
2010-08-19 17:13 ` Herrera-Bendezu, Luis
0 siblings, 1 reply; 18+ messages in thread
From: Philippe Gerum @ 2010-08-19 16:42 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
On Thu, 2010-08-19 at 08:26 -0400, Herrera-Bendezu, Luis wrote:
> >-----Original Message-----
> >From: Philippe Gerum [mailto:rpm@xenomai.org]
> >Sent: Wednesday, August 18, 2010 4:44 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 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.
> >
> 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_codec@domain.hid
> 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_codec@domain.hid
> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-19 16:42 ` Philippe Gerum
@ 2010-08-19 17:13 ` Herrera-Bendezu, Luis
2010-08-20 5:39 ` Philippe Gerum
0 siblings, 1 reply; 18+ messages in thread
From: Herrera-Bendezu, Luis @ 2010-08-19 17:13 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
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.
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.
Luis
>-----Original Message-----
>From: Philippe Gerum [mailto:rpm@xenomai.org]
>Sent: Thursday, August 19, 2010 12:43 PM
>To: Herrera-Bendezu, Luis
>Cc: xenomai-help@gna.org
>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:rpm@xenomai.org]
>> >Sent: Wednesday, August 18, 2010 4:44 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 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-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.
>> >
>> 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_codec@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_codec@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.
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-19 17:13 ` Herrera-Bendezu, Luis
@ 2010-08-20 5:39 ` Philippe Gerum
2010-08-20 6:03 ` Philippe Gerum
2010-08-20 13:30 ` Herrera-Bendezu, Luis
0 siblings, 2 replies; 18+ messages in thread
From: Philippe Gerum @ 2010-08-20 5:39 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
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:rpm@xenomai.org]
> >Sent: Thursday, August 19, 2010 12:43 PM
> >To: Herrera-Bendezu, Luis
> >Cc: xenomai@xenomai.org
> >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:rpm@xenomai.org]
> >> >Sent: Wednesday, August 18, 2010 4:44 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 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.
> >> >
> >> 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_codec@domain.hid
> >> 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_codec@domain.hid
> >> 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.
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 5:39 ` Philippe Gerum
@ 2010-08-20 6:03 ` Philippe Gerum
2010-08-20 13:30 ` Herrera-Bendezu, Luis
1 sibling, 0 replies; 18+ messages in thread
From: Philippe Gerum @ 2010-08-20 6:03 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
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:rpm@xenomai.org]
> > >Sent: Thursday, August 19, 2010 12:43 PM
> > >To: Herrera-Bendezu, Luis
> > >Cc: xenomai@xenomai.org
> > >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:rpm@xenomai.org]
> > >> >Sent: Wednesday, August 18, 2010 4:44 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 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.
> > >> >
> > >> 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_codec@domain.hid
> > >> 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_codec@domain.hid
> > >> 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 5:39 ` Philippe Gerum
2010-08-20 6:03 ` Philippe Gerum
@ 2010-08-20 13:30 ` Herrera-Bendezu, Luis
2010-08-20 13:49 ` Philippe Gerum
1 sibling, 1 reply; 18+ messages in thread
From: Herrera-Bendezu, Luis @ 2010-08-20 13:30 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Removed the first patch for drlib.cand applied the second one to timer.c.
Resuming realtime task does not seem unblock RTDM task for next scheduled
interval, 30 ms. However, terminating gdb and restarting app outside gdb
does make RTDM task resume execution. Before, the driver had to be reloaded.
So gdb appears to be causing timer to block even if no breakpoint is set,
probably signals?
Regards,
Luis
>-----Original Message-----
>From: Philippe Gerum [mailto:rpm@xenomai.org]
>Sent: Friday, August 20, 2010 1:40 AM
>To: Herrera-Bendezu, Luis
>Cc: xenomai-help@gna.org
>Subject: RE: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
>
>
>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:rpm@xenomai.org]
>> >Sent: Thursday, August 19, 2010 12:43 PM
>> >To: Herrera-Bendezu, Luis
>> >Cc: xenomai-help@gna.org
>> >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:rpm@xenomai.org]
>> >> >Sent: Wednesday, August 18, 2010 4:44 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 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-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.
>> >> >
>> >> 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_codec@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_codec@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.
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 13:30 ` Herrera-Bendezu, Luis
@ 2010-08-20 13:49 ` Philippe Gerum
2010-08-20 13:58 ` Jan Kiszka
0 siblings, 1 reply; 18+ messages in thread
From: Philippe Gerum @ 2010-08-20 13:49 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: xenomai
On Fri, 2010-08-20 at 09:30 -0400, Herrera-Bendezu, Luis wrote:
> Removed the first patch for drlib.cand applied the second one to timer.c.
>
> Resuming realtime task does not seem unblock RTDM task for next scheduled
> interval, 30 ms.
Actually, the code I sent simply postpones the timer shot of a frozen
timer by steps of 500 ms until the timebase is unblocked (I changed this
value to 250 ms in the tree), so this is expected. The assumption here
is that you can't expect the timer to be precise for the next shot,
since you held execution for an indefinite amount of time via gdb. What
is guaranteed now is that the associated handler will be called when the
timer is thawed, thus resuming your RTDM task shortly after the
execution is continued.
> However, terminating gdb and restarting app outside gdb
> does make RTDM task resume execution. Before, the driver had to be reloaded.
>
> So gdb appears to be causing timer to block even if no breakpoint is set,
> probably signals?
>
There is no reason for that. Sending "continue" to gdb is expected to
unblock the timers, until the code is single-stepped again (e.g. after
^C or any breakpoint).
> Regards,
> Luis
>
> >-----Original Message-----
> >From: Philippe Gerum [mailto:rpm@xenomai.org]
> >Sent: Friday, August 20, 2010 1:40 AM
> >To: Herrera-Bendezu, Luis
> >Cc: xenomai@xenomai.org
> >Subject: RE: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
> >
> >
> >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:rpm@xenomai.org]
> >> >Sent: Thursday, August 19, 2010 12:43 PM
> >> >To: Herrera-Bendezu, Luis
> >> >Cc: xenomai@xenomai.org
> >> >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:rpm@xenomai.org]
> >> >> >Sent: Wednesday, August 18, 2010 4:44 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 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.
> >> >> >
> >> >> 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_codec@domain.hid
> >> >> 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_codec@domain.hid
> >> >> 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.
> >
>
--
Philippe.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 13:49 ` Philippe Gerum
@ 2010-08-20 13:58 ` Jan Kiszka
2010-08-20 14:06 ` Philippe Gerum
0 siblings, 1 reply; 18+ messages in thread
From: Jan Kiszka @ 2010-08-20 13:58 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
>> However, terminating gdb and restarting app outside gdb
>> does make RTDM task resume execution. Before, the driver had to be reloaded.
>>
>> So gdb appears to be causing timer to block even if no breakpoint is set,
>> probably signals?
>>
>
> There is no reason for that. Sending "continue" to gdb is expected to
> unblock the timers, until the code is single-stepped again (e.g. after
> ^C or any breakpoint).
gdb silently intercepts a traced program for various reasons, e.g.
thread creation or library loading. Even if no user breakpoint is set,
the program may briefly be stopped nevertheless. If that happens
frequently enough, and every stop can add latencies to running timers...
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 13:58 ` Jan Kiszka
@ 2010-08-20 14:06 ` Philippe Gerum
2010-08-20 14:08 ` Jan Kiszka
0 siblings, 1 reply; 18+ messages in thread
From: Philippe Gerum @ 2010-08-20 14:06 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Fri, 2010-08-20 at 15:58 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> >> However, terminating gdb and restarting app outside gdb
> >> does make RTDM task resume execution. Before, the driver had to be reloaded.
> >>
> >> So gdb appears to be causing timer to block even if no breakpoint is set,
> >> probably signals?
> >>
> >
> > There is no reason for that. Sending "continue" to gdb is expected to
> > unblock the timers, until the code is single-stepped again (e.g. after
> > ^C or any breakpoint).
>
> gdb silently intercepts a traced program for various reasons, e.g.
> thread creation or library loading. Even if no user breakpoint is set,
> the program may briefly be stopped nevertheless. If that happens
> frequently enough, and every stop can add latencies to running timers...
We are talking about permanent freeze of timers, not transient (at least
this is what I got from the ongoing discussion).
>
> Jan
>
--
Philippe.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 14:06 ` Philippe Gerum
@ 2010-08-20 14:08 ` Jan Kiszka
2010-08-20 14:24 ` Philippe Gerum
2010-08-20 14:25 ` Herrera-Bendezu, Luis
0 siblings, 2 replies; 18+ messages in thread
From: Jan Kiszka @ 2010-08-20 14:08 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
Philippe Gerum wrote:
> On Fri, 2010-08-20 at 15:58 +0200, Jan Kiszka wrote:
>> Philippe Gerum wrote:
>>>> However, terminating gdb and restarting app outside gdb
>>>> does make RTDM task resume execution. Before, the driver had to be reloaded.
>>>>
>>>> So gdb appears to be causing timer to block even if no breakpoint is set,
>>>> probably signals?
>>>>
>>> There is no reason for that. Sending "continue" to gdb is expected to
>>> unblock the timers, until the code is single-stepped again (e.g. after
>>> ^C or any breakpoint).
>> gdb silently intercepts a traced program for various reasons, e.g.
>> thread creation or library loading. Even if no user breakpoint is set,
>> the program may briefly be stopped nevertheless. If that happens
>> frequently enough, and every stop can add latencies to running timers...
>
> We are talking about permanent freeze of timers, not transient (at least
> this is what I got from the ongoing discussion).
Yes, but what would happen if the interruption rate is higher than the
timer delay? Wouldn't we effectively end up with a permanent freeze?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 14:08 ` Jan Kiszka
@ 2010-08-20 14:24 ` Philippe Gerum
2010-08-20 14:25 ` Herrera-Bendezu, Luis
1 sibling, 0 replies; 18+ messages in thread
From: Philippe Gerum @ 2010-08-20 14:24 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
On Fri, 2010-08-20 at 16:08 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Fri, 2010-08-20 at 15:58 +0200, Jan Kiszka wrote:
> >> Philippe Gerum wrote:
> >>>> However, terminating gdb and restarting app outside gdb
> >>>> does make RTDM task resume execution. Before, the driver had to be reloaded.
> >>>>
> >>>> So gdb appears to be causing timer to block even if no breakpoint is set,
> >>>> probably signals?
> >>>>
> >>> There is no reason for that. Sending "continue" to gdb is expected to
> >>> unblock the timers, until the code is single-stepped again (e.g. after
> >>> ^C or any breakpoint).
> >> gdb silently intercepts a traced program for various reasons, e.g.
> >> thread creation or library loading. Even if no user breakpoint is set,
> >> the program may briefly be stopped nevertheless. If that happens
> >> frequently enough, and every stop can add latencies to running timers...
> >
> > We are talking about permanent freeze of timers, not transient (at least
> > this is what I got from the ongoing discussion).
>
> Yes, but what would happen if the interruption rate is higher than the
> timer delay? Wouldn't we effectively end up with a permanent freeze?
If the _signal_ rate is higher than the timer delay and continuous, then
either the guy sending ^C via the keyboard should go easier on the
coffee, or gdb has a severe problem and should be fixed, whichever comes
first.
>
> Jan
>
--
Philippe.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 14:08 ` Jan Kiszka
2010-08-20 14:24 ` Philippe Gerum
@ 2010-08-20 14:25 ` Herrera-Bendezu, Luis
2010-08-20 14:41 ` Philippe Gerum
1 sibling, 1 reply; 18+ messages in thread
From: Herrera-Bendezu, Luis @ 2010-08-20 14:25 UTC (permalink / raw)
To: Jan Kiszka, Philippe Gerum; +Cc: xenomai
>-----Original Message-----
>From: Jan Kiszka [mailto:jan.kiszka@siemens.com]
>Sent: Friday, August 20, 2010 10:09 AM
>To: Philippe Gerum
>Cc: Herrera-Bendezu, Luis; xenomai-help@gna.org
>Subject: Re: RTDM task blocks when connecting gdb to realtime task
>
>
>Philippe Gerum wrote:
>> On Fri, 2010-08-20 at 15:58 +0200, Jan Kiszka wrote:
>>> Philippe Gerum wrote:
>>>>> However, terminating gdb and restarting app outside gdb
>>>>> does make RTDM task resume execution. Before, the driver had to be reloaded.
>>>>>
>>>>> So gdb appears to be causing timer to block even if no breakpoint is set,
>>>>> probably signals?
>>>>>
>>>> There is no reason for that. Sending "continue" to gdb is expected to
>>>> unblock the timers, until the code is single-stepped again (e.g. after
>>>> ^C or any breakpoint).
>>> gdb silently intercepts a traced program for various reasons, e.g.
>>> thread creation or library loading. Even if no user breakpoint is set,
>>> the program may briefly be stopped nevertheless. If that happens
>>> frequently enough, and every stop can add latencies to running timers...
>>
>> We are talking about permanent freeze of timers, not transient (at least
>> this is what I got from the ongoing discussion).
>
>Yes, but what would happen if the interruption rate is higher than the
>timer delay? Wouldn't we effectively end up with a permanent freeze?
>
>Jan
Tracing lock_/unlock_timers() calls shows that program is frequently
stopped. I had to disable notification mechanism to report secondary
mode switch on rt tasks, rt_task_set_mode(), to get aperiodic tasks
back to rt operation when gdb resumes rt task.
Thanks,
Luis
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
2010-08-20 14:25 ` Herrera-Bendezu, Luis
@ 2010-08-20 14:41 ` Philippe Gerum
0 siblings, 0 replies; 18+ messages in thread
From: Philippe Gerum @ 2010-08-20 14:41 UTC (permalink / raw)
To: Herrera-Bendezu, Luis; +Cc: Jan Kiszka, xenomai
On Fri, 2010-08-20 at 10:25 -0400, Herrera-Bendezu, Luis wrote:
> >-----Original Message-----
> >From: Jan Kiszka [mailto:jan.kiszka@domain.hid]
> >Sent: Friday, August 20, 2010 10:09 AM
> >To: Philippe Gerum
> >Cc: Herrera-Bendezu, Luis; xenomai@xenomai.org
> >Subject: Re: RTDM task blocks when connecting gdb to realtime task
> >
> >
> >Philippe Gerum wrote:
> >> On Fri, 2010-08-20 at 15:58 +0200, Jan Kiszka wrote:
> >>> Philippe Gerum wrote:
> >>>>> However, terminating gdb and restarting app outside gdb
> >>>>> does make RTDM task resume execution. Before, the driver had to be reloaded.
> >>>>>
> >>>>> So gdb appears to be causing timer to block even if no breakpoint is set,
> >>>>> probably signals?
> >>>>>
> >>>> There is no reason for that. Sending "continue" to gdb is expected to
> >>>> unblock the timers, until the code is single-stepped again (e.g. after
> >>>> ^C or any breakpoint).
> >>> gdb silently intercepts a traced program for various reasons, e.g.
> >>> thread creation or library loading. Even if no user breakpoint is set,
> >>> the program may briefly be stopped nevertheless. If that happens
> >>> frequently enough, and every stop can add latencies to running timers...
> >>
> >> We are talking about permanent freeze of timers, not transient (at least
> >> this is what I got from the ongoing discussion).
> >
> >Yes, but what would happen if the interruption rate is higher than the
> >timer delay? Wouldn't we effectively end up with a permanent freeze?
> >
> >Jan
>
> Tracing lock_/unlock_timers() calls shows that program is frequently
> stopped.
That is expected. The application receives a substantial amount of
SIGTRAP/SIGSTOP under gdb; what saves us is that this should never be
continuous.
> I had to disable notification mechanism to report secondary
> mode switch on rt tasks, rt_task_set_mode(), to get aperiodic tasks
> back to rt operation when gdb resumes rt task.
>
> Thanks,
> Luis
--
Philippe.
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2010-08-20 14:41 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-18 16:03 [Xenomai-help] RTDM task blocks when connecting gdb to realtime task Herrera-Bendezu, Luis
2010-08-18 16:20 ` Gilles Chanteperdrix
2010-08-18 16:38 ` Philippe Gerum
2010-08-18 17:29 ` Herrera-Bendezu, Luis
2010-08-18 20:44 ` Philippe Gerum
2010-08-19 12:26 ` Herrera-Bendezu, Luis
2010-08-19 16:42 ` Philippe Gerum
2010-08-19 17:13 ` Herrera-Bendezu, Luis
2010-08-20 5:39 ` Philippe Gerum
2010-08-20 6:03 ` Philippe Gerum
2010-08-20 13:30 ` Herrera-Bendezu, Luis
2010-08-20 13:49 ` Philippe Gerum
2010-08-20 13:58 ` Jan Kiszka
2010-08-20 14:06 ` Philippe Gerum
2010-08-20 14:08 ` Jan Kiszka
2010-08-20 14:24 ` Philippe Gerum
2010-08-20 14:25 ` Herrera-Bendezu, Luis
2010-08-20 14:41 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.