http://blog.gmane.org/gmane.linux.systemtap hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.systemtap/10392 A new automated systemtap source snapshot is available ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20081129.tar.bz2 1089973 bytes, fd2aeae9e2d04d2cf417a32f98257041e8ff0e2c tag See also ftp://sources.redhat.com/pub/systemtap/snapshots/ fche< at >sourceware.org 2008-11-29T14:27:07 http://comments.gmane.org/gmane.linux.systemtap/10382 Hello, I tried to run sleeptime.stp script from http://sourceware.org/systemtap/wiki/ScriptsTools on maemo platform (diablo version). Running stap -vvv sleeptime.stp I've got the following Running /usr/bin/staprun -v -v /var/tmp/stapqX8ReO/stap_07ac9da65fb9eda7439c65904e2b95 60_12133.ko staprun:main:249 modpath="/var/tmp/stapqX8ReO/stap_07ac9da65fb9eda7439c65904e2b9560_12133.ko", modname="stap_07ac9da65fb9eda7439c65904e2b9560_12133" staprun:init_staprun:207 init_staprun staprun:insert_module:47 inserting module staprun:insert_module:66 module options: _stp_bufsize=0 Error inserting module '/var/tmp/stapqX8ReO/stap_07ac9da65fb9eda7439c65904e2b9560_12133.ko': Unknown symbol in module Pass 5: run completed in 10usr/120sys/210real ms. Pass 5: run failed. Try again with more '-v' (verbose) options. dmesg command says: [ 6783.937500] stap_07ac9da65fb9eda7439c65904e2b9560_12133: Unknown symbol relay_open [ 6783.937500] stap_07ac9da65fb9eda7439c65904e2b9560_12133: Unknown symbol relay_buf_full [ 6783.94 Dmitry Malichenko 2008-11-27T17:28:01 http://comments.gmane.org/gmane.linux.systemtap/10368 probe never {p <<< 1} global p results in ERROR: empty aggregate near identifier 'p' at <input>:1:28 but should result in p < at >count=0x0 fche at redhat dot com 2008-11-25T19:19:45 http://comments.gmane.org/gmane.linux.systemtap/10365 I think we could branch git tree only for upstream kernel. that is good for upstream kernel developers. In this branch, we should; - remove all autoconf-*. - use new kernel functions/macros. Then, it could be easy to port upstream kernel. mhiramat at redhat dot com 2008-11-25T17:57:07 http://comments.gmane.org/gmane.linux.systemtap/10363 ksebasti found several issues with this widget: printf ("%n%4d", 0) prints 0x04 0x00 0x00 0x00 0x00 printf ("%n%n%n") prints junk printf ("%n") prints junk If we keep %n around at all, it needs to compose sensibly. We could make it mean "total record length", so that the previous three cases would print printf ("%n%4d", 0) would print 0x05 0x00 0x00 0x00 0x00 printf ("%n%n%n") would print 0x03 0x03 0x03 printf ("%n") would print 0x01 fche at redhat dot com 2008-11-25T16:48:29 http://comments.gmane.org/gmane.linux.systemtap/10362 In most of our kernel-side code, translator-generated or runtime, we use the kosher smp_processor_id function to get the cpu number. Considering that we always disable preemption, it seems useful to switch to raw_smp_processor_id() in several spots, which would exclude the redundant runtime checks compiled into the plain variant. fche at redhat dot com 2008-11-25T15:57:33 http://comments.gmane.org/gmane.linux.systemtap/10352 Current checks in tapsets.cxx:validate_module_elf do not consider the valid possibility of probing an x86 binary on an x86-64 kernel, and unfairly rejects debuginfo/elf processing for them. (The same problem probably exists on ppc.) fche at redhat dot com 2008-11-24T15:57:52 http://comments.gmane.org/gmane.linux.systemtap/10350 My systemtap is the latest: git describe release-0.7-521-g01b05e2 I have been getting the following errors throughout the whole of last week, not sure what is the status: In file included from /tmp/stapJzFK4J/stap_7146.c:46: /usr/local/share/systemtap/runtime/stat.c: In function '_stp_stat_get': /usr/local/share/systemtap/runtime/stat.c:213: error: incompatible type for argument 2 of 'cpumask_next' _stp_stat_clear /usr/local/share/systemtap/runtime/stat.c: In function '_stp_stat_clear': /usr/local/share/systemtap/runtime/stat.c:248: error: incompatible type for argument 2 of 'cpumask_next' task_nsproxy put_nsproxy get_nsproxy ns_cgroup_clone get_uts_ns put_uts_ns copy_utsname utsname init_utsname pagefault_disable pagefault_enable function__dwarf_tvar_get_size_0 function_exit probe_1386 probe_1387 probe_1388 enter_begin_probe enter_end_probe enter_error_probe enter_kprobe_probe enter_kretprobe_probe enter_hrtimer_probe systemtap_module_init systemtap_module_exit probe_start probe_exit Execution times (s Peter Teoh 2008-11-24T03:44:25 http://comments.gmane.org/gmane.linux.systemtap/10348 A new automated systemtap source snapshot is available ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20081122.tar.bz2 1066088 bytes, 7320987632c7029c3b351b9ff8e5118d18979693 tag See also ftp://sources.redhat.com/pub/systemtap/snapshots/ fche< at >sourceware.org 2008-11-22T14:27:10 http://comments.gmane.org/gmane.linux.systemtap/10345 Support unified trace buffer instead of relayfs, since relay will be replaced by it. see kernel/trace/ring_buffer.c. mhiramat at redhat dot com 2008-11-21T13:31:07 http://comments.gmane.org/gmane.linux.systemtap/10343 They requires more explicit commitments to upstream kernel. - refine their requirements - picking up previous mails. - ask them what we can do for them. - better integration with upstream kernel - merging minimum runtime. - merging minimum systemtap(or systemtap like scriptable tracer). - easy to use of systemtap on upstream kernel - no-dwarf(debuginfo) mode by default. - porting tapsets to upstream kernel. This entry is a meta entry, please list up your ideas. mhiramat at redhat dot com 2008-11-21T13:24:46 http://comments.gmane.org/gmane.linux.systemtap/10333 Hi All, If you are like Roland and looking for a newer version of the Systemtap RPMs for Fedora, you are in luck. The newer Systemtap 0.8 RPMs are now available for testing on Fedora 8 and Fedora 9. There is also a request for Fedora 10 but the rpms haven't been pushed to the F10 repository: https://admin.fedoraproject.org/updates/F8/FEDORA-2008-9787 https://admin.fedoraproject.org/updates/F9/FEDORA-2008-9695 https://admin.fedoraproject.org/updates/systemtap-0.8-1.fc10 The RPMs can be installed on a fedora 8/9 machines with: yum install --enablerepo=updates-testing-newkey systemtap Or the RPMs can upgraded with: yum upgrade --enablerepo=updates-testing-newkey "systemtap*" Please check to see that the newer version of systemtap works as expected and report your results on the update URLs towards the top of this email. -Will William Cohen 2008-11-19T19:41:32 http://comments.gmane.org/gmane.linux.systemtap/10328 It looks like for_each_cpu() interface has changed again on tip.git, breaking stp_for_each_cpu. The error I get when compiling a stap module here is: /usr/local/share/systemtap/runtime/stat.c: In function ‘_stp_stat_get’: /usr/local/share/systemtap/runtime/stat.c:213: error: incompatible type for argument 2 of ‘cpumask_next’ Using for_each_possible_cpu() should be equivalent to for_each_cpu(cpu, cpu_possible_map), but its interface didn't change like for_each_cpu() did. I kept the 2.6.28 #ifdef just in case, but for_each_possible_cpu() should work even on older kernels. Signed-off-by: Eduardo Habkost <ehabkost< at >redhat.com> --- runtime/runtime.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/runtime/runtime.h b/runtime/runtime.h index 7507e59..90113b6 100644 --- a/runtime/runtime.h +++ b/runtime/runtime.h < at >< at > -41,7 +41,7 < at >< at > #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28) #ifndef stp_for_each_cpu -#define stp_for_each_cpu(cpu) for_each_cpu((cpu), cpu_possible_map) Eduardo Habkost 2008-11-19T14:03:32 http://comments.gmane.org/gmane.linux.systemtap/10327 Hi, These are test results on 2.6.28-rc5 from labrat. ------------------------------------------------------------------------------ Package: systemtap_snapshot (0.8/0.131-master(a6ce1707)-2.6.28_rc5-snapshot) Previous build: 2008/11/11 02:25:03 - 2008/11/11 02:25:03 Current build: 2008/11/17 04:53:56 - 2008/11/17 04:53:56 Host: rctest-32 Platform: Linux 2.6.28-rc5 i386 (EL4U6) (before: Linux 2.6.28-rc4 i386 (EL4U6)) URL: http://build.alchar.org/cgi/showBuild?host=rctest-32&pkg=systemtap_snapshot&date=20081117-045356 First failure: test Test result: 823: 760 +, 34 -, 29 S, 0 E Old -> New Test ----- ----- ---------------------------------- FAIL -> PASS test - systemtap.syscall/syscall.exp(32-bit alarm) PASS -> FAIL test - systemtap.syscall/syscall.exp(32-bit uid16) PASS -> FAIL test - systemtap.syscall/syscall.exp(32-bit sendfile) PASS -> FAIL test - systemtap.syscall/syscall.exp(32-bit unlink) PASS -> FAIL test - systemtap.base/global_e Wenji Huang 2008-11-19T07:03:16 http://comments.gmane.org/gmane.linux.systemtap/10310 This is wrong: % stap -r /sdfijsdfoidf -L 'kernel.function("*")' % echo $? 0 This is more like it, though the "pass 2..." line is probably unhelpful. % stap -r /sdfijsdfoidf -e 'probe kernel.function("*") {}' semantic error: libdwfl failure (missing kernel /sdfijsdfoidf x86_64 debuginfo): No such file or directory while resolving probe point kernel.function("*") semantic error: no probes found Pass 2: analysis failed. Try again with more '-v' (verbose) options. % echo $? 1 fche at redhat dot com 2008-11-17T14:25:14 http://comments.gmane.org/gmane.linux.systemtap/10308 A new automated systemtap source snapshot is available ftp://sources.redhat.com/pub/systemtap/snapshots/systemtap-20081115.tar.bz2 1059250 bytes, 3ca1f6524b3592b377b1f9ad19bdae6eaa511bc4 tag See also ftp://sources.redhat.com/pub/systemtap/snapshots/ fche< at >sourceware.org 2008-11-15T14:27:09 http://comments.gmane.org/gmane.linux.systemtap/10306 Currently, systemtap locks whole of a probe handler which uses global variables. However, I think translator can shrink the locking region to the best size. { (lock(a) and lock(b)) ... a = xxx <- only here, we actually needs a's lock. ... if (yyy) b = zzz <- only here, we actually needs b's lock. ... (unlock(a) and unlock(b)) } mhiramat at redhat dot com 2008-11-14T23:26:34 http://comments.gmane.org/gmane.linux.systemtap/10299 This patch will change for_each_cpu macro definition to avoid name collusion in 2.6.28-rc4. See mainline commit: cb56d98e2a7530615899597551db685d68a2e852. --- runtime/counter.c | 4 ++-- runtime/map-stat.c | 4 ++-- runtime/map.c | 14 +++++++------- runtime/pmap-gen.c | 6 +++--- runtime/runtime.h | 10 ++++++++-- runtime/stat.c | 6 +++--- runtime/transport/procfs.c | 6 +++--- 7 files changed, 28 insertions(+), 22 deletions(-) diff --git a/runtime/counter.c b/runtime/counter.c index d037654..a3c3669 100644 --- a/runtime/counter.c +++ b/runtime/counter.c < at >< at > -58,7 +58,7 < at >< at > Counter _stp_counter_init (void) #if NEED_COUNTER_LOCKS == 1 { int i; -for_each_cpu(i) { +stp_for_each_cpu(i) { Counter c = per_cpu_ptr (cnt, i); spin_lock_init(c->lock); } < at >< at > -119,7 +119,7 < at >< at > int64_t _stp_counter_get (Counter cnt, int clear) int i; int64_t sum = 0; -for_each_cpu(i) { +stp_for_each_cpu(i) { Coun Wenji Huang 2008-11-14T07:07:12 http://comments.gmane.org/gmane.linux.systemtap/10295 Hi, These are test results on 2.6.28-rc4 from labrat. In fact, stap couldn't work on 2.6.28-rc4 due to kernel change in include/linux/cpumask.h. +#define for_each_cpu(cpu, mask) \ + for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask) in commit cb56d98e2a7530615899597551db685d68a2e852. Unfortunately, Stap has own for_each_cpu macro in runtime/runtime.h The conflict will cause compilation error even the simplest script like 'probe begin{}'. To make test running, I temporarily disabled kernel for_each_cpu macro. Maybe this will affect test results. Anyway, the problem needs a long term solution. Maybe we can get rid of for_each_cpu, use for_each_cpu_mask directed. Regards, Wenji ------------------------------------------------------------------------------ Package: systemtap_snapshot (0.7.1/0.131-master(589db2fc)-2.6.28_rc4-snapshot) Previous build: 2008/11/03 09:15:54 - 2008/11/03 09:15:54 Current build: 2008/11/11 02:25:03 - 2008/11/11 02:25:03 Host: rctes Wenji Huang 2008-11-14T02:32:46 http://comments.gmane.org/gmane.linux.systemtap/10285 __group_send_sig_info and specific_send_sig_info seem to be inlined in 2.6.27 kernels. __group_send_sig_info and specific_send_sig_info are now just wrapper functions for send_signal. Though this issue has been talked in http://sources.redhat.com/bugzilla/show_bug.cgi?id=1155, we could fix this by make changes in signal.stp to refer to send_signal rather than __group_send_sig_info and specific_send_sig_info. Currently the failure message when running sig-by-pid.stp on 2.6.26+ kernel: stap sig-by-pid.stp semantic error: failed to retrieve location attribute for local 'sig' (dieoffset: 0x4e01ef): identifier '$sig' at /usr/share/systemtap/tapset/signal.stp:92:11 semantic error: failed to retrieve location attribute for local 't' (dieoffset: 0x4e01e5): identifier '$t' at :93:12 semantic error: failed to retrieve location attribute for local 'sig' (dieoffset: 0x4e031b): identifier '$sig' at :92:11 semantic error: failed to retrieve location attribute for local 't' (dieoffset: 0x4e0311): identifier '$t' at :9 srikar at linux dot vnet dot ibm dot com 2008-11-13T08:33:30 http://comments.gmane.org/gmane.linux.systemtap/10272 Here is an implementation of statically defined user probes which use uprobes probes. The test, testsuite/systemtap.base/sduprobes.{c,stp} give a brief synopsis of the user interface. (sduprobes.exp is not completely fleshed out yet.) Currently STAP_PROBE_START turns on probing and STAP_PROBEN define probe points. STAP_PROBEN are defined the same as DTRACE_PROBEN and give the name of the probe and the arguments to the probe. These macros are defined in sduprobes.h. The name of the probe given to STAP_PROBEN is the label given to process(PROC).mark("LABEL"). Currently the landing pad for the probes is in sduprobes.c; this routine is built with debugging turned on and is in the library libsduprobes.a. The goal, ultimately, is for this to be a shared library. There can be a many to one relationship between the STAP_PROBEN probes and the landing pad, so a .probes section is created which stap uses to determine the proper corresponding probe point. For example there may be multiple uses of STAP_PROBE2, whi Stan Cox 2008-11-12T03:40:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.systemtap