Hi, not worth to call it a patch, at least not when looking at the second file.
Lockdep gets unhappy when I-pipe is enabled because a) TRACE_IRQS_ON/OFF instrumentations in entry_64.S do not correlate with the root's pipeline state. Instead of fixing the latter (which costs extra cycles), the fix relaxes the sanity check. b) The exit path of __ipipe_handle_exception reenables Linux IRQs when the were not disabled. I do not understand that case fully yet, so I hacked the alarm away with that cli. Jan --- arch/x86/kernel/ipipe.c | 1 + kernel/lockdep.c | 4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) Index: b/kernel/lockdep.c =================================================================== --- a/kernel/lockdep.c +++ b/kernel/lockdep.c @@ -2028,7 +2028,7 @@ void trace_hardirqs_on(void) curr->hardirqs_enabled = 1; ip = (unsigned long) __builtin_return_address(0); - if (DEBUG_LOCKS_WARN_ON(!irqs_disabled())) + if (DEBUG_LOCKS_WARN_ON(!irqs_disabled() && !irqs_disabled_hw())) return; if (DEBUG_LOCKS_WARN_ON(current->hardirq_context)) return; @@ -2064,7 +2064,7 @@ void trace_hardirqs_off(void) if (unlikely(!debug_locks || current->lockdep_recursion)) return; - if (DEBUG_LOCKS_WARN_ON(!irqs_disabled())) + if (DEBUG_LOCKS_WARN_ON(!irqs_disabled() && !irqs_disabled_hw())) return; if (curr->hardirqs_enabled) { Index: b/arch/x86/kernel/ipipe.c =================================================================== --- a/arch/x86/kernel/ipipe.c +++ b/arch/x86/kernel/ipipe.c @@ -799,6 +799,7 @@ int __ipipe_handle_exception(struct pt_r } __ipipe_std_extable[vector](regs, error_code); + asm volatile ("cli"); local_irq_restore(flags); __fixup_if(regs); -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core