[ltt-dev] CONFIG_HAVE_TRACE_CLOCK_GENERIC timestamp problem on PXA255

[Steve Langstaff]

> From: Mathieu Desnoyers [mailto:compudj at krystal.dyndns.org]


> * Steve Langstaff (steve.langstaff at pebblebay.com) wrote:
> > > From: Mathieu Desnoyers [mailto:compudj at krystal.dyndns.org]
> >
> > > * Steve Langstaff (steve.langstaff at pebblebay.com) wrote:
> > > > I am having trouble with the timestamps that are logged in the
> traces
> > > - they
> > > > don't seem to 'tick' at the right rate.
> >
> > > Hrm, this should at least follow the correct tick rate.
> >
> > > A few things to check :
> > >
> > > - if your system is in NO_HZ
> > > - your HZ value
> > > - if the timer handler trace_clock_timer_fct is called (try adding
> a
> > >   printk in there)
> > > - If the timer frequency reported by trace_clock_frequency() is
> > > correct.
> >
> > I don't have NO_HZ defined.
> > My HZ value is 100.
> > The trace_clock_timer_fct function is called.
> > The trace_clock_frequency() function returns 819200.
> >
> > I wonder whether the problem I am seeing is not with the LTTng
> tracing, but
> > with the LTTV trace decoder...
> >
> > When I run lttv 0.12.14 with the "-v -d -e" options it fails to parse
> the
> > trace, which is strange because the description for those options
> only
> > mentions changes to what it prints, and instead reports the
> following:
> >
> 
> 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.

> The -e option enables the filter. The warnings below come from the
> filter code.

It turns out that I get radically different results depending on the
presence and ordering of my -v, -d and -e options relative to my -m option.
Worth making a note of somewhere, I guess.