Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
(My guess is that your machine is lacking kernel-debuginfo, and the script
does not try to back down to synthetic debuginfo for the @cast operations;
@cast(data[timer], "struct work_struct", "kernel<linux/workqueue.h>")->func
and similar for task_string ("kernel<linux/sched.h>") might make it work.)
Comment 10Frank Ch. Eigler
2013-10-13 00:59:10 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.
Contact your manager or support representative in case you have further questions about the request.
With the current nightly compose it periodic.stp worked. [wcohen@dhcp129-131 profiling]$ uname -r 3.10.0-33.el7.x86_64 [wcohen@dhcp129-131 profiling]$ rpm -q systemtap systemtap-2.3-1.el7.x86_64 [wcohen@dhcp129-131 profiling]$ sudo stap -v --all-modules periodic.stpPass 1: parsed user script and 108 library script(s) using 217724virt/35096res/3024shr/32956data kb, in 120usr/10sys/437real ms. Pass 2: analyzed script: 3 probe(s), 11 function(s), 4 embed(s), 4 global(s) using 457984virt/129288res/4164shr/125676data kb, in 650usr/180sys/830real ms. Pass 3: translated to C into "/tmp/stap83LIsY/stap_73790cd0c01e134dfbc76d152c13077e_11121_src.c" using 594328virt/191192res/30324shr/125676data kb, in 3120usr/60sys/3194real ms. Pass 4: compiled C into "stap_73790cd0c01e134dfbc76d152c13077e_11121.ko" in 2520usr/240sys/2448real ms. Pass 5: starting run. #monitoring timer periods (press control-c for output) ^C#type function period(us) count kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1000 3117 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1000 3117 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1000 3117 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1000 3117 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1000 3114 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1001 3113 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1007 3095 kernel 0xffffffffa08e8f60 [stap_73790cd0c01e134dfbc76d152 1007 3094 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 9999 311 kernel 0xffffffffa08e81f0 [stap_73790cd0c01e134dfbc76d152 9999 311 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 9999 311 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 10003 310 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 10003 310 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 10000 310 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 9999 310 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 10000 310 kernel intel_pstate_timer_func+0x0/0x2c0 [kernel] 9999 310 kernel 0xffffffffa08e88a0 [stap_73790cd0c01e134dfbc76d152 20006 154 process rcu_sched(9) 426009 7 work_q vmstat_update 1000022 2 work_q vmstat_update 999963 2 work_q vmstat_update 1000001 2 work_q vmstat_update 1000005 2 work_q vmstat_update 999974 2 work_q vmstat_update 1000022 2 work_q sync_cmos_clock 999997 2 work_q vmstat_update 1000010 1 kernel tcp_write_timer+0x0/0x70 [kernel] 233907 1 kernel e1000_watchdog+0x0/0x30 [e1000e] 2000002 1 work_q vmstat_update 1000002 1 work_q disk_events_workfn 2047971 1 Pass 5: run completed in 10usr/40sys/3431real ms. [wcohen@dhcp129-131 profiling]$ However, on fedora 19 can see a failure in the same way: [wcohen@santana profiling]$ uname -r 3.11.2-201.fc19.x86_64 [wcohen@santana profiling]$ rpm -q systemtap systemtap-2.3-1.fc19.x86_64 [wcohen@santana profiling]$ sudo stap -v --all-modules periodic.stp Pass 1: parsed user script and 157 library script(s) using 377752virt/192748res/3040shr/192984data kb, in 870usr/40sys/916real ms. semantic error: while resolving probe point: identifier 'kernel' at periodic.stp:12:7 source: probe kernel.trace("timer_expire_entry") ^ semantic error: no match Pass 2: analyzed script: 2 probe(s), 145 function(s), 3 embed(s), 4 global(s) using 394620virt/207936res/5716shr/205276data kb, in 200usr/280sys/484real ms. Pass 2: analysis failed. [man error::pass2]