[ltt-dev] OMAP3/4 trace clock and lockdep tracing

[Mathieu Desnoyers]

* Harald Gustafsson (hgu1972 at gmail.com) wrote:
> Hi,
> 
> I'm currently porting the higher precision OMAP3/4 trace clock aka
> non-generic to another dual-core ARMv7 architecture. The port is not
> fully debugged yet but I discovered one strange thing that I wonder if
> anyone have experienced on the OMAP3/4 as well. If I use the
> non-generic trace clock and have lockdep tracing turned on the system
> freezes (no output) but the soft lockup cleaner kills of a process
> each 61 seconds and dumps its output. Without the non-generic clock I
> don't have this problem and without the lockdep tracing I don't have
> this problem even when using the non-generic clock. To clarify it is
> the lockdep tracing that show the problem, if I only have lockdep
> configured it is no problem.
> 
> Have anyone run lockdep tracing on the OMAP3/4 using the non-generic
> trace clock (i.e. normal LTTng config) and had this problem? This
> would help me understand if it is only a porting issue or if there is
> some deeper bug to find.
> 
> I use a 2.6.34 kernel (with LOCKDEP, LOCKDEP_DEBUG, DEBUG_LOCK_ALLOC,
> PROVE_LOCKING, DEBUG_SPINLOCK, LOCK_STAT, and DEBUG_TRACE_CLOCK on)
> with lttng 0.221 currently for compatibility with other SW and HW.

Hrm, I should probably do this, can you try this patch out ? Can you
test it and report if it fixes your problem ?


ARM omap trace clock notrace

* Harald Gustafsson (hgu1972 at gmail.com) wrote:
> Hi,
> 
> I'm currently porting the higher precision OMAP3/4 trace clock aka
> non-generic to another dual-core ARMv7 architecture. The port is not
> fully debugged yet but I discovered one strange thing that I wonder if
> anyone have experienced on the OMAP3/4 as well. If I use the
> non-generic trace clock and have lockdep tracing turned on the system
> freezes (no output) but the soft lockup cleaner kills of a process
> each 61 seconds and dumps its output. Without the non-generic clock I
> don't have this problem and without the lockdep tracing I don't have
> this problem even when using the non-generic clock. To clarify it is
> the lockdep tracing that show the problem, if I only have lockdep
> configured it is no problem.
>
[...]
> I use a 2.6.34 kernel (with LOCKDEP, LOCKDEP_DEBUG, DEBUG_LOCK_ALLOC,
> PROVE_LOCKING, DEBUG_SPINLOCK, LOCK_STAT, and DEBUG_TRACE_CLOCK on)

Let's make sure the trace lock read primitive don't call into lockdep.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
---
 arch/arm/plat-omap/include/plat/trace-clock.h |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Index: linux-2.6-lttng/arch/arm/plat-omap/include/plat/trace-clock.h
===================================================================
--- linux-2.6-lttng.orig/arch/arm/plat-omap/include/plat/trace-clock.h
+++ linux-2.6-lttng/arch/arm/plat-omap/include/plat/trace-clock.h
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2009 Mathieu Desnoyers
+ * Copyright (C) 2009, 2010, 2011 Mathieu Desnoyers
  *
  * Trace clock ARM OMAP3 definitions.
  */
@@ -122,12 +122,12 @@ static inline u64 trace_clock_read64(voi
 #ifdef CONFIG_DEBUG_TRACE_CLOCK
 	unsigned long flags;
 
-	local_irq_save(flags);
+	raw_local_irq_save(flags);
 	per_cpu(last_clock_nest, smp_processor_id())++;
 	barrier();
 #endif
 
-	preempt_disable();
+	preempt_disable_notrace();
 	pm_count = &per_cpu(pm_save_count, smp_processor_id());
 	if (likely(pm_count->fast_clock_ready)) {
 		cf = &pm_count->cf[ACCESS_ONCE(pm_count->index)];
@@ -136,12 +136,12 @@ static inline u64 trace_clock_read64(voi
 	} else
 		val = _trace_clock_read_slow();
 	trace_clock_debug(val);
-	preempt_enable();
+	preempt_enable_notrace();
 
 #ifdef CONFIG_DEBUG_TRACE_CLOCK
 	barrier();
 	per_cpu(last_clock_nest, smp_processor_id())--;
-	local_irq_restore(flags);
+	raw_local_irq_restore(flags);
 #endif
 	return val;
 }


-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com