On 07/08/2015 02:24 PM, Jan Kiszka wrote: > On 2015-07-08 13:56, Philippe Gerum wrote: >> On 07/08/2015 12:31 PM, Jan Kiszka wrote: >>> On 2015-07-07 14:53, Philippe Gerum wrote: >>>> On 07/07/2015 11:27 AM, Philippe Gerum wrote: >>>>> I tested the patch on ARM. Enabling IPIPE_DEBUG_INTERNAL there reveals a >>>>> bug with the mayday handler now turning hw IRQs on, as a result of >>>>> relaxing over the low level IRQ trampoline, which makes some I-pipe call >>>>> in the irq_handler boilerplate code unhappy. The very same issue is >>>>> looming on x86, with an unprotected call to __ipipe_root_p from >>>>> __ipipe_handle_irq(). Disabling IRQs before leaving the mayday handler >>>>> is required at the very least. >>>>> >>>> >>>> Looking further, ARM is affected because it does not invoke >>>> __ipipe_call_mayday() for triggering the mayday trap, but still uses the >>>> open-coded method. This routine preserves the current hw state across >>>> the trap, which should make x86 safe in the end. >>> >>> Which kernel version are you testing? It's not reproducing on 3.14 for >>> Cortex-A7/15 targets at least. And I find __ipipe_call_mayday in both >>> 3.14 and 3.18 (fastcall_exit_check). >>> >> >> Looking at the code, any kernel version since 3.10 will have the same >> issue, older ones likely too, tested on 3.18.12. This does not depend on >> the ARM target. >> >> irq_handler from entry-armv.S: >> => __ipipe_grab_irq (or indirecty via ipipe_handle_multi_irq with >> MULTI_IRQ enabled) >> => __ipipe_exit_irq (open coded __ipipe_notify_trap(MAYDAY), >> xnthread_relax() re-enables hw IRQs) >> => __ipipe_check_root_interruptible (from irq_handler) >> BAD: __ipipe_root_p tested with CPU migration enabled >> > > Maybe [1] makes the difference here? I think I had to fix this for a > different reason. >
Yes, that would make a significant difference, although the core issue would remain. -- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://xenomai.org/mailman/listinfo/xenomai
