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

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

[Herrera-Bendezu, Luis]

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

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

[Gilles Chanteperdrix]

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.

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

[Philippe Gerum]

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.

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

[Herrera-Bendezu, Luis]

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

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

[Philippe Gerum]

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.

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

[Herrera-Bendezu, Luis]

>-----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

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

[Philippe Gerum]

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.

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

[Herrera-Bendezu, Luis]

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.
>

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

[Philippe Gerum]

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.

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

[Philippe Gerum]

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.

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

[Herrera-Bendezu, Luis]

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.
>

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

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

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

[Philippe Gerum]

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.

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

[Jan Kiszka]

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

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

[Philippe Gerum]

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.

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

[Herrera-Bendezu, Luis]

>-----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

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

[Philippe Gerum]

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.