Jan Kiszka wrote:

my colleagues and I need some hint where to continue our search for the
cause of a weird cleanup issue:

An application of our robotics framework sometimes terminates (though
successfully) in a way that the system timer IRQ no longer arrives
afterwards or no re-program takes place anymore.

Assuming that the APIC is disabled in the kernel configuration, so that there could be an issue with the nucleus host timer, I would try to look at the state of this timer (XNTIMER_DEQUEUED?) right after the cleanup. I would also try to store a copy of the last timer object seen by xntimer_next_local_shot(), so that the timer id (htimer or not basically) and the programmed tick date could be looked at after the cleanup phase. Normally, if no other application timer is active, the host timer should be the only one to tick periodically until xnpod_shutdown is called, and thus should keep on being reprogrammed by xntimer_next_local_shot().

If xnpod_shutdown is called, then this is another story, and rthal_timer_release() should be inspected instead.

 All other Linux IRQs
are fine (Ethernet, keyboard, etc.). I cannot provide an easy test case
yet as besides the framework some expensive gyroscope and the 16550A
driver are involved.

Fortunately, we found a clean way of stabilising the application by
fixing our broken code :) and improving the serial driver (RTIOC_PURGE),
so that the original problem is solved now (unreliable startup and
cleanup). Anyway, the stopped timer is not yet explainable, and that's
why we plan to dig deeper.



Xenomai-core mailing list



Xenomai-core mailing list

Reply via email to