lttng-ust failure on QemuPPC

lttng-ust failure on QemuPPC

[Saul Wold]

Bruce, Darren:

Can you take a look at the failure in the qemuppc build against
the lttng-ust.

Looks like the definitions for CLOCK_TRACE and CLOCK_TRACE_FREQ are not 
available for ppc?  Is this a package that should not be built for PPC?

Thanks
     Sau!

Saul Wold
Yocto Component Wrangler @ Intel
Yocto Project / Poky Build System

Re: lttng-ust failure on QemuPPC

[Bruce Ashfield]

On Sun, Feb 6, 2011 at 9:17 PM, Saul Wold <sgw@linux.intel.com> wrote:
>
> Bruce, Darren:
>
> Can you take a look at the failure in the qemuppc build against
> the lttng-ust.
>
> Looks like the definitions for CLOCK_TRACE and CLOCK_TRACE_FREQ are not
> available for ppc?  Is this a package that should not be built for PPC?

Hmmm, not much information here, is this logged somewhere that
covers basic triage ?

Has the package changed ? Was this building before and regressed ?

lttng ust is supposed to work for powerpc, but from a look at the source,
include/ust/clock.h looks wrong for powerpc, since the definitions you
mention are x86 only, but then used in an unprotected function.

commit 9c6bb08180ab0a65bbf3d47247a9d36e257fa44a in the lttng ust
tree looks to have made the change on January 12th. Which leads me
back to my 'was this building before' question .. I assume it was, which
then leads me to 'did this change' .. I see we did bump the revision
in commit e8f2bfcfdaee3cd5cbdb4cf10d48c91bfa741f00 9 days ago.

commit 9c6bb08180ab0a65bbf3d47247a9d36e257fa44a in the lttng ust
tree mentions:

    At runtime, UST checks if the LTTng clock source is available
    If not, CLOCK_MONOTONIC is the default fallback.

    This makes UST use the LTTng kernel clock source. With this
    clock support, LTTng and UST traces are perfectly synchronize.
    Traces from these two tracer can be merged for analysis.

    LTTng 0.240 or higher is needed for this new clock source.

That looks like a version mismatch. It definitely is for the 2.6.34 kernel,
and until my latest pull request is merged for the 2.6.37 kernel, its a
mismatch there as well.

A quick check with an updated 2.6.37 kernel shows that the error is
there regardless. So this just looks like a straight up issue with
the updated lttng ust.

Hope that helps,

Bruce



>
> Thanks
>    Sau!
>
> Saul Wold
> Yocto Component Wrangler @ Intel
> Yocto Project / Poky Build System
>
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: lttng-ust failure on QemuPPC

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

On Sun, Feb 6, 2011 at 10:52 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Sun, Feb 6, 2011 at 9:17 PM, Saul Wold <sgw@linux.intel.com> wrote:
>>
>> Bruce, Darren:
>>
>> Can you take a look at the failure in the qemuppc build against
>> the lttng-ust.
>>
>> Looks like the definitions for CLOCK_TRACE and CLOCK_TRACE_FREQ are not
>> available for ppc?  Is this a package that should not be built for PPC?
>
> Hmmm, not much information here, is this logged somewhere that
> covers basic triage ?
>
> Has the package changed ? Was this building before and regressed ?
>
> lttng ust is supposed to work for powerpc, but from a look at the source,
> include/ust/clock.h looks wrong for powerpc, since the definitions you
> mention are x86 only, but then used in an unprotected function.
>
> commit 9c6bb08180ab0a65bbf3d47247a9d36e257fa44a in the lttng ust
> tree looks to have made the change on January 12th. Which leads me
> back to my 'was this building before' question .. I assume it was, which
> then leads me to 'did this change' .. I see we did bump the revision
> in commit e8f2bfcfdaee3cd5cbdb4cf10d48c91bfa741f00 9 days ago.
>
> commit 9c6bb08180ab0a65bbf3d47247a9d36e257fa44a in the lttng ust
> tree mentions:
>
>    At runtime, UST checks if the LTTng clock source is available
>    If not, CLOCK_MONOTONIC is the default fallback.
>
>    This makes UST use the LTTng kernel clock source. With this
>    clock support, LTTng and UST traces are perfectly synchronize.
>    Traces from these two tracer can be merged for analysis.
>
>    LTTng 0.240 or higher is needed for this new clock source.
>
> That looks like a version mismatch. It definitely is for the 2.6.34 kernel,
> and until my latest pull request is merged for the 2.6.37 kernel, its a
> mismatch there as well.
>
> A quick check with an updated 2.6.37 kernel shows that the error is
> there regardless. So this just looks like a straight up issue with
> the updated lttng ust.


For what it is worth, I slapped together a compile tested only patch
for lttng ust 0.11.

It definitely was the update of ust that caused this problem, and this
fixes things (somewhat). Worth double checking the upstream repo
for a better/more complete fix, I didn't have time to do another cjeck
at the moment.

Cheers,

Bruce

>
> Hope that helps,
>
> Bruce
>
>
>
>>
>> Thanks
>>    Sau!
>>
>> Saul Wold
>> Yocto Component Wrangler @ Intel
>> Yocto Project / Poky Build System
>>
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
>>
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

[-- Attachment #2: 0001-ust-ifdef-CLOCK_TRACE-and-CLOCK_TRACE_FREQ-for-power.patch --]
[-- Type: text/x-patch, Size: 1827 bytes --]

From 9df1172100ceb5d65d93531399a6e15d16a73fa6 Mon Sep 17 00:00:00 2001
From: Bruce Ashfield <bruce.ashfield@windriver.com>
Date: Mon, 7 Feb 2011 13:17:47 -0500
Subject: [PATCH] ust: #ifdef CLOCK_TRACE and CLOCK_TRACE_FREQ for powerpc builds

CLOCK_TRACE and CLOCK_TRACE_FREQ are introduced for x86 and x86-64
but are used in non #ifdef'd code sections. This patch does not
attempt to extend support to powerpc for those clocks, but instead
fixes compiliation errors and makes powerpc use CLOCK_MONOTONIC as
the fallback.

Compile tested only.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 include/ust/clock.h |    2 ++
 libust/tracectl.c   |    4 ++++
 2 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/include/ust/clock.h b/include/ust/clock.h
index 04785fc..306cd7c 100644
--- a/include/ust/clock.h
+++ b/include/ust/clock.h
@@ -108,10 +108,12 @@ static __inline__ u64 trace_clock_frequency(void)
 	struct timespec ts;
 	union lttng_timespec *lts = (union lttng_timespec *) &ts;
 
+#if __i386__ || __x86_64__
 	if (likely(ust_clock_source == CLOCK_TRACE)) {
 		clock_gettime(CLOCK_TRACE_FREQ, &ts);
 		return lts->lttng_ts;
 	}
+#endif
 	return 1000000000LL;
 }
 
diff --git a/libust/tracectl.c b/libust/tracectl.c
index e877e62..2e39bdb 100644
--- a/libust/tracectl.c
+++ b/libust/tracectl.c
@@ -1269,11 +1269,15 @@ static void __attribute__((constructor)) init()
 	/* Get clock the clock source type */
 
 	/* Default clock source */
+#if __i386__ || __x86_64__
 	ust_clock_source = CLOCK_TRACE;
 	if (clock_gettime(ust_clock_source, &ts) != 0) {
 		ust_clock_source = CLOCK_MONOTONIC;
 		DBG("UST traces will not be synchronized with LTTng traces");
 	}
+#else
+	ust_clock_source = CLOCK_MONOTONIC;
+#endif
 
 	autoprobe_val = getenv("UST_AUTOPROBE");
 	if (autoprobe_val) {
-- 
1.7.0.4