[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