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

["Herrera-Bendezu, Luis" <lherrera@domain.hid>]

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