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.

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

Reply via email to