On 05/12/2014 02:37 PM, Petr Cervenka wrote:
Od: Philippe Gerum <r...@xenomai.org>Thanks. Could you drop the previous instrumentation patches, and give a try at this one? It fixes a flaw in the logic for maintaining the thread information bits, which may have caused the issue you observed: diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c index 0a2ee19..22fa91d 100644 --- a/ksrc/nucleus/pod.c +++ b/ksrc/nucleus/pod.c @@ -1391,7 +1391,8 @@ void xnpod_suspend_thread(xnthread_t *thread, xnflags_t mask, } #endif /* CONFIG_XENO_OPT_PERVASIVE */ - xnthread_clear_info(thread, XNRMID | XNTIMEO | XNBREAK | XNWAKEN | XNROBBED); + xnthread_clear_info(thread, XNRMID | XNTIMEO | XNBREAK | \ + XNWAKEN | XNROBBED | XNKICKED); } /* Don't start the timer for a thread indefinitely delayed byI applied the new patch and I was not able to reproduce the -EINTR problem to this moment. But one of the machines I tried during long term test over the weekend got frozen. But it could be also from different reason. What do you think?
Could you enable all debug features (CONFIG_XENO_OPT_DEBUG), and particularly CONFIG_XENO_OPT_WATCHDOG? The system will be significantly slowed down due to the consistency checks on all internal lists (i.e. DEBUG_QUEUES), but this may give us some hints about the freeze.
-- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
