From: "Herrera-Bendezu, Luis" <lherrera@domain.hid>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] RTDM task blocks when connecting gdb to realtime task
Date: Thu, 19 Aug 2010 08:26:54 -0400 [thread overview]
Message-ID: <6FCCA913376DD7488F4139A4D11B8F4801465B76@domain.hid> (raw)
In-Reply-To: <1282164261.1730.359.camel@domain.hid>
>-----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
next prev parent reply other threads:[~2010-08-19 12:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6FCCA913376DD7488F4139A4D11B8F4801465B76@domain.hid \
--to=lherrera@domain.hid \
--cc=rpm@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.