[ltt-dev] OMAP3/4 trace clock and lockdep tracing
compudj at krystal.dyndns.org
Wed Apr 6 12:42:29 EDT 2011
* Harald Gustafsson (hgu1972 at gmail.com) wrote:
> 2011/4/6 Mathieu Desnoyers <compudj at krystal.dyndns.org>:
> > Hrm, I should probably do this, can you try this patch out ? Can you
> > test it and report if it fixes your problem ?
> Thanks it fixes the problem. I made the corresponding changes in my
> architecture's trace-clock.h which is a copy & paste of the omap
> version. So I assume this would also work for the OMAP.
> Now I only have the clock mismatch between the cores to deal with,
> lttv complains for threads that are inserted before they are forked
> (range is 10 us - 10 ms mismatch depending on run). I think it is due
> to that the cores enters/leaves WFI unsynced and hence runs on cycle
> counter and 32kHz clock in a different pattern and I get some error
> due to this. So far I run cpufreq on performance to not introduce
> even more uncertainty. Have you tried the code on a OMAP4?
I haven't tested this on OMAP4 personally, so I'm really interested in
your feedback. I did my development on OMAP3 UP, but I designed the
trace clock to support SMP (but it's not tested by myself, others have
reported success though). You might want to try with and without:
- power management suspend/resume
- cpufreq changes
There is code in trace clock to support each of these. 10 ms offset
between the cores is way too much, so I guess there is something wrong
there. First identifying if it's suspend/resume or cpufreq that are
causing the problems would help us there.
What do you mean by "enters/leaves WFI" ? (WFI TLA means ?)
Given what you say above, cpufreq running in performance mode should
make it OK as far as cpufreq is concerned, although there might be some
discrepancy at boot time if the cpufreq mode is only changed later.
I suspect that the problem might come from that your OMAP4 architecture
does not call the trace clock resync after power management resume, like
OMAP3 is doing. You might also want to have a look at the Linaro 2.6.38
git tree, which integrates LTTng with Linaro, which might have better
support for OMAP4 suspend/resume.
I'm really interested in fixing this up, but I'll need your help for
Operating System Efficiency R&D Consultant
More information about the lttng-dev