On Thu, Jul 10, 2014 at 7:01 PM, Philippe Gerum <[email protected]> wrote:
> On 07/10/2014 12:00 PM, Henri Roosen wrote: > >> >> FIQ's should be disabled by the additional call to >> local_fiq_disable_hw() we added. Or is there an >> ipipe_stall_pipeline_xxxx() function that should be called for that >> instead? >> >> > FIQ control is not part of the generic i-pipe API. > > > Anyway, you could double-check that the Xenomai timer is involved by >> enabling the nucleus but leaving all API skins unloaded/disabled. In >> that case, Xenomai 2.x does not grab the host timer, so it won't >> emulate the host kernel tick. >> >> >> Based on your suggestion I did more tests. The problem triggers only >> when a Xenomai module is loaded. Without the module loaded there is no >> problem. I stripped down the module, it now only calls rt_task_create() >> and rt_task_set_periodic() at module init, rt_task_delete() at module >> exit. This reproduces the problem. However, if we leave out the call >> to rt_task_set_periodic() the problem cannot be reproduced. >> >> So does the rt_task_set_periodic() call lead to grabbing the host timer? >> > > This is done earlier when turning on the services of the first API to > connect to the system (posix, native etc.) So this happens upon modprobing > the fist API module, or during the machine boot up if such API is built in > the kernel. > > If the Xenomai system timer is different from the regular kernel clock > event source, then calling rt_task_set_periodic() causes a stream of IRQs > different from the host timer IRQ to arrive. > > You can check the Xenomai system timer state and source looking at > /proc/xenomai/timer. > > It's definitely related to the timer irq triggering; a simple module that uses only rtdm to trigger a timer using rtdm_timer_start_in_handler() in the handler reproduces the problem, > Any hints on how to workaround this problem when going into >> suspend-to-RAM? >> > > Why some IRQ would still be pending while reaching WFI is unclear to me > (read: I have no idea why), but maybe you could try checking the current > assumptions by disabling the Xenomai time source very impolitely, by > calling xnpod_disable_timesource(), then switching it back using > xnpod_enable_timesource() when exiting the suspended state. > > No guarantee that this will work flawlessly around a suspended state, as a > matter of fact these services are currently used only during Xenomai boot > up and shutdown phases. I suspect that if Xenomai does not share the clock > chip with the host kernel, Xenomai software timers depending on this clock > event source will remain stuck. You could probably work around this by > calling ipipe_trigger_irq(XNARCH_TIMER_IRQ) right after > xnpod_enable_timesource() though. > > In short, the corresponding and simplified sequence would be: > > xnpod_disable_timesource(); > hard_local_irq_disable(); > wfi > xnpod_enable_timesource(); > ipipe_trigger_irq(XNARCH_TIMER_IRQ); Unfortunately this doesn't work. Enabling the timesource after the wfi leads to some kind of strange lockup of the system when trying to wake up, where it seems to be stuck at some cpu_idle loop. Any suggestions for steps to try or debug this? > > -- > Philippe. > _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
