[ltt-dev] CONFIG_HAVE_TRACE_CLOCK_GENERIC timestamp problem on PXA255

[Mathieu Desnoyers]

* Steve Langstaff (steve.langstaff at pebblebay.com) wrote:
> > From: Steve Langstaff [mailto:steve.langstaff at pebblebay.com]
> 
> > > From: Mathieu Desnoyers [mailto:compudj at krystal.dyndns.org]
> 
> > > This kind of time-stamping issue is usually within the trace clock
> > > infrastructure.
> > 
> > I'm pretty sure that I am running the stock generic trace clock code
> > but
> > I'll keep looking.
> 
> Solved! My mistake.
> 
> I hadn't correctly applied the *whole* of
> trace-clock-rename-generic-identifier.patch, so my implementation of:
> 
> static inline u32 trace_clock_read32(void)
> {
> 	return (u32)atomic_long_add_return(1, &trace_clock_var);
> }
> 
> Was still coded as:
> 
> static inline u32 trace_clock_read32(void)
> {
> 	return (u32)atomic_long_add_return(1, &trace_clock);
> }
> 
> No wonder the timestamps were hovering round a strange value.
> 

Ah ! Yes, that makes sense.

I'm glad it works. BTW the latest LTTng have this patch applied.

Thanks,

Mathieu

> 
> 
> _______________________________________________
> ltt-dev mailing list
> ltt-dev at lists.casi.polymtl.ca
> http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68