Dear gentlemen, thanks for your immediate and informed answers :-) This is awesome. So far so good, I'm now able to trace either functions or events or both (tested). I have yet to take a look at systemtap (working on several fronts). When I'm done playing with this, I intend to write a short summary (for noobs to come after me). For the problem that I'm trying to debug (possibly some user space app tweaking the system timebase, need to find out the culprit) it would be useful to reference the trace timestamps to wall time (UTC) for a later analysis. I've read about /sys/kernel/debug/tracing/trace_clock and fiddled with it, I understand that this is all I have. No problem with that, I can calculate the wall time from the time stamps e.g. using a Perl script - the condition being that I can get the current value of that timer, at the time of running the Perl script. I need to take that reference once on script startup, together with "time" = epoch value in seconds, and a couple milliseconds of systematic error don't matter. I understand that the trace timestamps are taken from some internal counter, vaguely similar to `cat /proc/timer_list | grep "now at"` but not quite the same, in my case there's a difference of about 30k seconds (8.3 hours) after 177 days of system uptime. I've tried passing other options to "trace_clock", only to find out that the default "local" clock probably makes the best sense :-) I'd love to get those trace timestamps referenced to UTC with a subsecond precision. And I don't want to reboot just to reset the counters. = is there any item under /proc or /sys that would tell me the current value of the "trace clock" ? Come to think of that, I could also pipe the "trace_pipe" straight into a Perl script that would insert UTC timestamps on its own, line after line, upon data arrival at (<>) - but the original "trace clock" time stamps are more precise, and also likely free of "system timebase frequency adjustments", which is a time domain where I'm trying to debug a problem :-) As usual, any further hints would be welcome... Frank Rysanek -- To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|