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

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to