[Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Jan Kiszka]

I expressed my skepticism about this global timer freeze before :->, and
now it hit me unpleasantly (Customer: "Is it normal that Xenomai stops
working after the gdb session?" Jan [scratching head]: "Hmm, no...").

After more scratching I think I found the reason: The target decided to
die after some fault, but Xenomai missed to unfreeze the timers. Patch
below fixes that.

Without hearing complains, this also goes into trunk/2.4.x later today.

Jan

---
 ksrc/nucleus/shadow.c |    3 +++
 1 file changed, 3 insertions(+)

Index: b/ksrc/nucleus/shadow.c
===================================================================
--- a/ksrc/nucleus/shadow.c
+++ b/ksrc/nucleus/shadow.c
@@ -2148,6 +2148,9 @@ static inline void do_taskexit_event(str
 	if (!thread)
 		return;
 
+	if (xnthread_test_info(thread, XNDEBUG))
+		unlock_timers();
+
 	if (xnpod_shadow_p())
 		xnshadow_relax(0);
 

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Gilles Chanteperdrix]

On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
> +       if (xnthread_test_info(thread, XNDEBUG))
> +               unlock_timers();
> +

Will this work if several threads are currently being debugged ?

-- 
 Gilles

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Jan Kiszka]

Gilles Chanteperdrix wrote:
> On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> +       if (xnthread_test_info(thread, XNDEBUG))
>> +               unlock_timers();
>> +
> 
> Will this work if several threads are currently being debugged ?

Not better or worse than with the current code. The whole approach is
not fixed by this patch, just some collateral damage is reduced.

Well, maybe some counter should be used to track the number of XNDEBUG
bits in the system and unfreeze the timers when that becomes zero. Will
look into this.

Jan

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Jan Kiszka]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>> +       if (xnthread_test_info(thread, XNDEBUG))
>>> +               unlock_timers();
>>> +
>> Will this work if several threads are currently being debugged ?
> 
> Not better or worse than with the current code. The whole approach is
> not fixed by this patch, just some collateral damage is reduced.
> 
> Well, maybe some counter should be used to track the number of XNDEBUG
> bits in the system and unfreeze the timers when that becomes zero. Will
> look into this.

Correction: that counter already exists in nkpod->timerlck. So it should
work even if other threads still have XNDEBUG set.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Fri, May 9, 2008 at 11:29 AM, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>> +       if (xnthread_test_info(thread, XNDEBUG))
>> +               unlock_timers();
>> +
> 
> Will this work if several threads are currently being debugged ?
> 

Yes, because we freeze timers when a thread receives a ptracing signal, so any
remaining thread entering a breakpoint/stepping next will trigger a freeze anew.

-- 
Philippe.

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Philippe Gerum]

Jan Kiszka wrote:
> I expressed my skepticism about this global timer freeze before :->, and

Just try debugging periodic code without it...

We should have an opt-out mechanism to hide timers from the auto-freeze feature,
 that is the real issue yet to be fixed.

> now it hit me unpleasantly (Customer: "Is it normal that Xenomai stops
> working after the gdb session?" Jan [scratching head]: "Hmm, no...").
> 
> After more scratching I think I found the reason: The target decided to
> die after some fault, but Xenomai missed to unfreeze the timers. Patch
> below fixes that.
> 
> Without hearing complains, this also goes into trunk/2.4.x later today.
> 
> Jan
> 
> ---
>  ksrc/nucleus/shadow.c |    3 +++
>  1 file changed, 3 insertions(+)
> 
> Index: b/ksrc/nucleus/shadow.c
> ===================================================================
> --- a/ksrc/nucleus/shadow.c
> +++ b/ksrc/nucleus/shadow.c
> @@ -2148,6 +2148,9 @@ static inline void do_taskexit_event(str
>  	if (!thread)
>  		return;
>  
> +	if (xnthread_test_info(thread, XNDEBUG))
> +		unlock_timers();
> +
>  	if (xnpod_shadow_p())
>  		xnshadow_relax(0);
>  
> 

This should be ok.


-- 
Philippe.

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Fri, May 9, 2008 at 11:44 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> Jan Kiszka wrote:
>> I expressed my skepticism about this global timer freeze before :->, and
>
> Just try debugging periodic code without it...
>
> We should have an opt-out mechanism to hide timers from the auto-freeze feature,
>  that is the real issue yet to be fixed.

Here is a patch I use at work.

-- 
 Gilles

[-- Attachment #2: xeno-timer-nolock.diff --]
[-- Type: application/octet-stream, Size: 950 bytes --]

Index: include/nucleus/timer.h
===================================================================
--- include/nucleus/timer.h	(révision 6608)
+++ include/nucleus/timer.h	(révision 6609)
@@ -33,6 +33,7 @@
 
 #define XNTIMER_DEQUEUED  0x00000001
 #define XNTIMER_KILLED    0x00000002
+#define XNTIMER_NOLOCK    0x00000004
 
 /* These flags are available to the real-time interfaces */
 #define XNTIMER_SPARE0  0x01000000
Index: ksrc/nucleus/timer.c
===================================================================
--- ksrc/nucleus/timer.c	(révision 6608)
+++ ksrc/nucleus/timer.c	(révision 6609)
@@ -210,7 +210,8 @@ static void xntimer_do_tick_aperiodic(vo
 		xntimer_dequeue_aperiodic(timer);
 
 		if (timer != &nkpod->htimer) {
-			if (!testbits(nkpod->status, XNTLOCK)) {
+			if (!testbits(nkpod->status, XNTLOCK)
+			    || testbits(timer->status, XNTIMER_NOLOCK)) {
 				timer->handler(timer);
 
 				if (timer->interval == XN_INFINITE ||

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Philippe Gerum]

Gilles Chanteperdrix wrote:
> On Fri, May 9, 2008 at 11:44 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>> Jan Kiszka wrote:
>>> I expressed my skepticism about this global timer freeze before :->, and
>> Just try debugging periodic code without it...
>>
>> We should have an opt-out mechanism to hide timers from the auto-freeze feature,
>>  that is the real issue yet to be fixed.
> 
> Here is a patch I use at work.
> 

Please merge this one (v2.4 and trunk). At some point (i.e. asap), we will need
an interface to set the NOLOCK bit on the thread's ptimer. The *_set_mode()
calls are good candidates to support that feature.

-- 
Philippe.

Re: [Xenomai-core] [PATCH] Unfreeze timers when debugged target exits

[Gilles Chanteperdrix]

On Fri, May 9, 2008 at 12:06 PM, Philippe Gerum <rpm@xenomai.org> wrote:
> Gilles Chanteperdrix wrote:
>> On Fri, May 9, 2008 at 11:44 AM, Philippe Gerum <rpm@xenomai.org> wrote:
>>> Jan Kiszka wrote:
>>>> I expressed my skepticism about this global timer freeze before :->, and
>>> Just try debugging periodic code without it...
>>>
>>> We should have an opt-out mechanism to hide timers from the auto-freeze feature,
>>>  that is the real issue yet to be fixed.
>>
>> Here is a patch I use at work.
>>
>
> Please merge this one (v2.4 and trunk). At some point (i.e. asap), we will need
> an interface to set the NOLOCK bit on the thread's ptimer. The *_set_mode()
> calls are good candidates to support that feature.

It was already in the trunk but not yet in v2.4.

-- 
 Gilles