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
