On 2014-11-12 18:27, Gilles Chanteperdrix wrote:
> We do not need trace_hardirqs_on and trace_hardirqs_off for the
> particular case of IRQs: they are already handled by
> __ipipe_do_sync_stage.
That was the key: Simply disabling the instrumentations in the
CONFIG_IPIPE removes all lock state inconsistencies, at least this far:
diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index d32f8bd..d8e0b2c 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -195,7 +195,7 @@
#ifdef CONFIG_IPIPE_DEBUG_INTERNAL
bl __ipipe_bugon_irqs_enabled
#endif
-#ifdef CONFIG_TRACE_IRQFLAGS
+#if defined(CONFIG_TRACE_IRQFLAGS) && !defined(CONFIG_IPIPE)
@ The parent context IRQs must have been enabled to get here in
@ the first place, so there's no point checking the PSR I bit.
bl trace_hardirqs_on
@@ -203,7 +203,7 @@
.else
@ IRQs off again before pulling preserved data off the stack
disable_irq_notrace
-#ifdef CONFIG_TRACE_IRQFLAGS
+#if defined(CONFIG_TRACE_IRQFLAGS) && !defined(CONFIG_IPIPE)
tst \rpsr, #PSR_I_BIT
bleq trace_hardirqs_on
tst \rpsr, #PSR_I_BIT
Will send a patch.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
