>-----Original Message----- >From: Jan Kiszka [mailto:[email protected]] >Sent: Friday, August 20, 2010 10:09 AM >To: Philippe Gerum >Cc: Herrera-Bendezu, Luis; [email protected] >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 _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
