This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: problems with sched tapset on ubuntu precise 3.2.0
- From: Thiago Manel <thiago dot manel at gmail dot com>
- To: David Smith <dsmith at redhat dot com>
- Cc: "systemtap at sourceware dot org" <systemtap at sourceware dot org>
- Date: Tue, 14 May 2013 16:45:47 -0300
- Subject: Re: problems with sched tapset on ubuntu precise 3.2.0
- References: <CAHiC6b0jFDRAcmkZq-KypjsoFO6kmfDH5S=64WbCbAEY0O1Obg at mail dot gmail dot com> <518947C5 dot 4020001 at redhat dot com> <CAHiC6b0hO=fvwqkfHBaMC=UzCdSA4yKEJSYji-Nk2hSVF5H5dA at mail dot gmail dot com> <518A5DF1 dot 3010207 at redhat dot com> <CAHiC6b06yQMSTh6nMtfp9MVS99+W21eO7KQ81hR2qbSQU12uDw at mail dot gmail dot com> <51915971 dot 1040802 at redhat dot com>
David, my output is
uname -a
Linux abotoado 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC
2012 x86_64 x86_64 x86_64 GNU/Linux
root@abotoado:/tmp# fgrep __tracepoint_sched /proc/kallsyms
ffffffff81cd3f80 D __tracepoint_sched_pi_setprio
ffffffff81cd3fc0 D __tracepoint_sched_stat_runtime
ffffffff81cd4000 D __tracepoint_sched_stat_iowait
ffffffff81cd4040 D __tracepoint_sched_stat_sleep
ffffffff81cd4080 D __tracepoint_sched_stat_wait
ffffffff81cd40c0 D __tracepoint_sched_process_fork
ffffffff81cd4100 D __tracepoint_sched_process_wait
ffffffff81cd4140 D __tracepoint_sched_wait_task
ffffffff81cd4180 D __tracepoint_sched_process_exit
ffffffff81cd41c0 D __tracepoint_sched_process_free
ffffffff81cd4200 D __tracepoint_sched_migrate_task
ffffffff81cd4240 D __tracepoint_sched_switch
ffffffff81cd4280 D __tracepoint_sched_wakeup_new
ffffffff81cd42c0 D __tracepoint_sched_wakeup
ffffffff81cd4300 D __tracepoint_sched_kthread_stop_ret
ffffffff81cd4340 D __tracepoint_sched_kthread_stop
ffffffffa04c2360 d __tracepoint_sched_switch [lttng_probe_sched]
ffffffffa04c2220 d __tracepoint_sched_process_wait [lttng_probe_sched]
ffffffffa04c23a0 d __tracepoint_sched_wakeup_new [lttng_probe_sched]
ffffffffa04c2120 d __tracepoint_sched_stat_iowait [lttng_probe_sched]
ffffffffa04c22e0 d __tracepoint_sched_process_free [lttng_probe_sched]
ffffffffa04c22a0 d __tracepoint_sched_process_exit [lttng_probe_sched]
ffffffffa04c20a0 d __tracepoint_sched_pi_setprio [lttng_probe_sched]
ffffffffa04c21a0 d __tracepoint_sched_stat_wait [lttng_probe_sched]
ffffffffa04c2460 d __tracepoint_sched_kthread_stop [lttng_probe_sched]
ffffffffa04c2320 d __tracepoint_sched_migrate_task [lttng_probe_sched]
ffffffffa04c2160 d __tracepoint_sched_stat_sleep [lttng_probe_sched]
ffffffffa04c2260 d __tracepoint_sched_wait_task [lttng_probe_sched]
ffffffffa04c23e0 d __tracepoint_sched_wakeup [lttng_probe_sched]
ffffffffa04c2420 d __tracepoint_sched_kthread_stop_ret [lttng_probe_sched]
ffffffffa04c20e0 d __tracepoint_sched_stat_runtime [lttng_probe_sched]
On Mon, May 13, 2013 at 6:21 PM, David Smith <dsmith@redhat.com> wrote:
> On 05/08/2013 09:56 AM, Thiago Manel wrote:
>> David,
>>
>> The first check indicates the kernel was compiled correctly
>> (CONFIG_TRACEPOINTS=y)
>>
>> cat /boot/config-`uname -r` | grep TRACE
>> CONFIG_STACKTRACE_SUPPORT=y
>> # CONFIG_RCU_TRACE is not set
>> # CONFIG_TREE_RCU_TRACE is not set
>> CONFIG_TRACEPOINTS=y
>> CONFIG_HAVE_ARCH_TRACEHOOK=y
>> CONFIG_CAN_PM_TRACE=y
>>
>> I also run the new schedtimes.stp, unfortunately I faced the error you
>> said, it was not able find the args ...
>>
>> semantic error: not accessible at this address (0xffffffff81659cc6,
>> dieoffset: 0x7bd1ea): identifier '$prev' at :35:18
>> source: previous_pid = $prev->pid;
>>
>>
>> I will downgrade to a 2.* kernel, thanks for the helping anyway.
>
> I've had another thought here. It could be that the tracepoints are
> there, but systemtap is having trouble finding them. On my system
> (3.8.11-200.fc18.x86_64), here's what the following command returns:
>
> # fgrep __tracepoint_sched /proc/kallsyms
> ffffffff81cc86e0 D __tracepoint_sched_pi_setprio
> ffffffff81cc8720 D __tracepoint_sched_stat_runtime
> ffffffff81cc8760 D __tracepoint_sched_stat_blocked
> ffffffff81cc87a0 D __tracepoint_sched_stat_iowait
> ffffffff81cc87e0 D __tracepoint_sched_stat_sleep
> ffffffff81cc8820 D __tracepoint_sched_stat_wait
> ffffffff81cc8860 D __tracepoint_sched_process_exec
> ffffffff81cc88a0 D __tracepoint_sched_process_fork
> ffffffff81cc88e0 D __tracepoint_sched_process_wait
> ffffffff81cc8920 D __tracepoint_sched_wait_task
> ffffffff81cc8960 D __tracepoint_sched_process_exit
> ffffffff81cc89a0 D __tracepoint_sched_process_free
> ffffffff81cc89e0 D __tracepoint_sched_migrate_task
> ffffffff81cc8a20 D __tracepoint_sched_switch
> ffffffff81cc8a60 D __tracepoint_sched_wakeup_new
> ffffffff81cc8aa0 D __tracepoint_sched_wakeup
> ffffffff81cc8ae0 D __tracepoint_sched_kthread_stop_ret
> ffffffff81cc8b20 D __tracepoint_sched_kthread_stop
>
> Can you try that on your 3.2.0 kernel?
>
> --
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
--
Thiago Emmanuel Pereira da Cunha Silva
-----------------------------------------------
www.lsd.ufcg.edu.br/~thiagoepdc
-----------------------------------------------