* Mathieu Desnoyers ([email protected]) wrote:
> * srimanta panda ([email protected]) 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 <[email protected]>
---
 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

_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

Reply via email to