This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH] tapset: add a tapset function for reading epoch time in ARM
- From: Josh Stone <jistone at redhat dot com>
- To: Jey Jay <rjayavrp2 at gmail dot com>
- Cc: systemtap at sourceware dot org
- Date: Mon, 16 Jun 2014 09:41:47 -0700
- Subject: Re: [PATCH] tapset: add a tapset function for reading epoch time in ARM
- Authentication-results: sourceware.org; auth=none
- References: <CAAKGpwRhhQAcCkATd4LAPxFnvH6M99PeCwzD33aVXpSNAmwFVg at mail dot gmail dot com> <20140612103820 dot GE30297 at redhat dot com> <5399BFCE dot 10103 at redhat dot com> <5399C2E4 dot 9080505 at redhat dot com> <5399C570 dot 9080403 at redhat dot com> <CAAKGpwR7tU7ejwEDC5s84igaaodj-TmpO9gQzqgPGiCFUygCwA at mail dot gmail dot com>
On 06/13/2014 11:14 PM, Jey Jay wrote:
> I have tested with 3.10 kernel on ARM. Till now didn't face any kernel
> panic issue.
Please try kprobes on functions called between timekeeper_seq's
write_seqcount_begin and write_seqcount_begin, and use your
getnstimeofday from those probes. I don't expect a panic, but a
read_seqcount_retry inifinite loop. If you have a watchdog, that may
notice the stall and panic though.
Note that even if we blacklisted kprobes on all such functions, it would
still be possible for a probe in interrupt code to hit during the middle
of those same write regions.
> Please guide me whether I can proceed or explore other options for
> collecting function execution time.
It looks like arm get_cycles() works since kernel commit 923df96b9f31b
(v3.6-rc1~70^2^3~1), with the export for read_current_timer added in
f3accb122f2c7 (v3.7-rc5~21^2~4^2~5).
So I'd suggest to start using that, either based on a KERNEL_VERSION
check, or better a new STAPCONF (see buildrun.cxx output_exportconf).
Josh