Skip to contentSkip to conversation

Unfreeze timers when debugged target exits

PATCH In review Jan Kiszka 3 participants 9 messages May 9, 2008

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

PATCH 1/1 Unfreeze timers when debugged target exits

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(+)
ksrc/nucleus/shadow.c +3 -0
Index: 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);
Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
#1 lore raw

ksrc/nucleus/shadow.c static inline void do_taskexit_event(str · line 2153

Quoted 3 lines · Jan Kiszka
ksrc/nucleus/shadow.c +3 -0
+       if (xnthread_test_info(thread, XNDEBUG))
+               unlock_timers();
+

Will this work if several threads are currently being debugged ?

Signature · 1 line
 Gilles
author
#2 lore raw
Quoted 6 lines · Gilles Chanteperdrix

ksrc/nucleus/shadow.c static inline void do_taskexit_event(str · line 2153

Quoted 3 lines · Jan Kiszka
ksrc/nucleus/shadow.c +3 -0
+       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

author
#3 lore raw
Quoted 5 lines · Jan Kiszka
Quoted 4 lines · Gilles Chanteperdrix
Quoted 3 lines · Jan Kiszka
ksrc/nucleus/shadow.c +3 -0
+       if (xnthread_test_info(thread, XNDEBUG))
+               unlock_timers();
+
Quoted 8 lines
Quoted 1 line

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

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
#4 lore raw
In reply to Gilles Chanteperdrix
Quoted 7 lines · Gilles Chanteperdrix

ksrc/nucleus/shadow.c static inline void do_taskexit_event(str · line 2153

Quoted 3 lines · Jan Kiszka
ksrc/nucleus/shadow.c +3 -0
+       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.

Signature · 1 line
Philippe.
#5 lore raw
In reply to Jan Kiszka
Quoted 1 line · Jan Kiszka

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.

Quoted 21 lines

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

ksrc/nucleus/shadow.c static inline void do_taskexit_event(str · line 2156

Quoted 9 lines
ksrc/nucleus/shadow.c +3 -0
@@ -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.

Signature · 1 line
Philippe.
#6 lore raw
Quoted 7 lines · Philippe Gerum
Quoted 1 line · Jan Kiszka

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.

Signature · 1 line
 Gilles
nucleus/timer.h +1 -0
Index: include/nucleus/timer.h
===================================================================
@@ -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
nucleus/timer.c +2 -1
Index: ksrc/nucleus/timer.c
===================================================================
@@ -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 ||
#7 lore raw
Quoted 10 lines · Gilles Chanteperdrix
Quoted 6 lines · Philippe Gerum
Quoted 1 line · Jan Kiszka

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.

Signature · 1 line
Philippe.
#8 lore raw
Quoted 9 lines · Philippe Gerum
Quoted 8 lines · Gilles Chanteperdrix
Quoted 6 lines · Philippe Gerum
Quoted 1 line · Jan Kiszka

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.

Quoted 6 lines
Quoted 2 lines

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.

Signature · 1 line
 Gilles