* Harald Gustafsson ([email protected]) 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 ([email protected]) 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 <[email protected]> --- 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 _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
