[ltt-dev] LTTng Build issue

Mathieu Desnoyers compudj at krystal.dyndns.org
Tue Sep 14 12:04:58 EDT 2010


* Mathieu Desnoyers (compudj at krystal.dyndns.org) wrote:
> * srimanta panda (panda_srimanta at yahoo.co.in) wrote:
> > Hi,
> >  
> > I am quite new to this LLTng.
> > I am trying to build the Kernel 2.6.34 with the ltt patch .221 for ARM platform. Its gives me link error related to the  trace-clock functionalities. 
> > I tried to figured out and found that it is not able to compile the trace-clock.c because of some flag HAVE_TRACE_CLOCK_GENERIC, which is present in the KConfig of the init folder.
> >  
> > I tried to enable the flag in the "kernel.spec", but is not able to set it because it is inside of menuconfig for CGROUPS. If I enable CGROUPS, it tells me to disable some other flags which I have no idea it is correct to do so.
> >  
> > I saw the previous patches for the kernel 2.6.33 and found that the HAVE_TRACE_CLOCK and HAVE_TRACE_CLOCK_GENERIC is added in different locations. It was not inside CGROUP menuconfig.
> >  
> > I wondering if the two flags have been added in the wrong place in the new patch .221?? 
> >  
> > Can you please help me out if I am doing any thing wrong to set the trace-clock? 
> 
> You are very certainly right. I'll look into this and come up with a
> fix.
> 
> Thanks for reporting the problem
> 
> Mathieu
> 

Can you check if this fix works for you ?

trace clock kconfig options were incorrectly in cgroups menu (rebase error)

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers at efficios.com>
---
 init/Kconfig |   70 +++++++++++++++++++++++++++++------------------------------
 1 file changed, 35 insertions(+), 35 deletions(-)

Index: linux-2.6-lttng/init/Kconfig
===================================================================
--- linux-2.6-lttng.orig/init/Kconfig
+++ linux-2.6-lttng/init/Kconfig
@@ -590,41 +590,6 @@ config CGROUP_MEM_RES_CTLR_SWAP
 	  Now, memory usage of swap_cgroup is 2 bytes per entry. If swap page
 	  size is 4096bytes, 512k per 1Gbytes of swap.
 
-#
-# Architectures with a 64-bits get_cycles() should select this.
-# They should also define
-# get_cycles_barrier() : instruction synchronization barrier if required
-# get_cycles_rate() : cycle counter rate, in HZ. If 0, TSC are not synchronized
-# across CPUs or their frequency may vary due to frequency scaling.
-#
-config HAVE_GET_CYCLES
-	def_bool n
-
-#
-# Architectures with a specialized tracing clock should select this.
-#
-config HAVE_TRACE_CLOCK
-	def_bool n
-
-config HAVE_TRACE_CLOCK_GENERIC
-	bool
-	default y if (!HAVE_TRACE_CLOCK)
-	default n if HAVE_TRACE_CLOCK
-	select HAVE_TRACE_CLOCK_32_TO_64 if (!64BIT)
-
-#
-# Architectures with only a 32-bits clock source should select this.
-#
-config HAVE_TRACE_CLOCK_32_TO_64
-	def_bool n
-
-#
-# Architectures which need to dynamically detect if their TSC is unsynchronized
-# across cpus should select this.
-#
-config HAVE_UNSYNCHRONIZED_TSC
-	def_bool n
-
 menuconfig CGROUP_SCHED
 	bool "Group CPU scheduler"
 	depends on EXPERIMENTAL && CGROUPS
@@ -683,6 +648,41 @@ config DEBUG_BLK_CGROUP
 
 endif # CGROUPS
 
+#
+# Architectures with a 64-bits get_cycles() should select this.
+# They should also define
+# get_cycles_barrier() : instruction synchronization barrier if required
+# get_cycles_rate() : cycle counter rate, in HZ. If 0, TSC are not synchronized
+# across CPUs or their frequency may vary due to frequency scaling.
+#
+config HAVE_GET_CYCLES
+	def_bool n
+
+#
+# Architectures with a specialized tracing clock should select this.
+#
+config HAVE_TRACE_CLOCK
+	def_bool n
+
+config HAVE_TRACE_CLOCK_GENERIC
+	bool
+	default y if (!HAVE_TRACE_CLOCK)
+	default n if HAVE_TRACE_CLOCK
+	select HAVE_TRACE_CLOCK_32_TO_64 if (!64BIT)
+
+#
+# Architectures with only a 32-bits clock source should select this.
+#
+config HAVE_TRACE_CLOCK_32_TO_64
+	def_bool n
+
+#
+# Architectures which need to dynamically detect if their TSC is unsynchronized
+# across cpus should select this.
+#
+config HAVE_UNSYNCHRONIZED_TSC
+	def_bool n
+
 config MM_OWNER
 	bool
 


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




More information about the lttng-dev mailing list