>-----Original Message----- >From: Philippe Gerum [mailto:r...@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:r...@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_co...@2000000_r 0 0 0 337375 0 00000000 0.2 IRQ512: [timer]
# cat /proc/xenomai/timerstat/master CPU SCHEDULED FIRED TIMEOUT INTERVAL HANDLER NAME 0 1005240 326161 1844335 - NULL [host-timer] 0 3976 3976 - - xnthread_ti intr_sim Status of application after application execution is resumed: # cat /proc/xenomai/stat CPU PID MSW CSW PF STAT %CPU NAME 0 0 0 15034 0 00400080 99.6 ROOT 0 0 0 3976 0 00000084 0.0 intr_sim 0 1261 2 2 2 00300380 0.0 ancvbirt 0 0 0 0 0 00000000 0.0 IRQ22: _vip_fpga_co...@2000000_r 0 0 0 428462 0 00000000 0.4 IRQ512: [timer] # cat /proc/xenomai/timerstat/master CPU SCHEDULED FIRED TIMEOUT INTERVAL HANDLER NAME 0 1314446 412961 410890 - NULL [host-timer] 0 3976 3976 - - xnthread_ti intr_sim 0 5 2 - - xnthread_ti AncVbiRt-in-int 0 4 1 - - xnthread_ti AncVbiRt-out-in 0 2 2 - - xnthread_ti AncVbiRt-client 0 3 1 - - xnthread_ti AncVbiRt-tsout 0 3 1 - - xnthread_ti AncVbiRt-pudi 0 1 1 - - xnthread_ti AncVbiRt-ancx 0 1 0 - - xnthread_ti AncVbiRt-vbix 0 1 0 - - xnthread_ti AncVbiRt-gpispl Notes: 1. GNU gdb Red Hat Linux (6.7-1rh) 2. GNU gdbserver Red Hat Linux (6.7-1rh) 3. set gdb to not stop/print/pass SIGXCPU signal. 4. Same behavior if program is executed within gdb and no breakpoints. Thanks, Luis _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
