http://permalink.gmane.org/gmane.linux.systemtap hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.systemtap/19365 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14137 Bug #: 14137 Summary: buildok/netfilter02.stp not ok Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: translator AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: mjw&lt; at &gt;redhat.com CC: cmeek&lt; at &gt;redhat.com, smakarov&lt; at &gt;redhat.com Classification: Unclassified Host: Linux toonder.wildebeest.org 3.3.6-3.fc16.x86_64 #1 SMP Wed May 16 21:43:01 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Snapshot: version 1.8/0.153 commit release-1.7-249-g57db0e6 GCC: 4.6.3 [gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)] Distro: Fedora release 16 (Verne) Running /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp starting /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp spawn1 stap -p4 /home/mark/src/systemtap/testsuite/buildok/netfilter02.stp spawn stap -p4 /home/mark/src/systemtap/testsuite/buildok/netfilter02</pre> mjw at redhat dot com 2012-05-23T11:30:27 http://permalink.gmane.org/gmane.linux.systemtap/19364 <pre> Does it make sense then ? In case of low throughput use cases, we have been for a long time dumping buffers only every few s isntead of 200us at the cost of printing latency. Rare cases but needed. Regards Fred Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 </pre> Turgis, Frederic 2012-05-22T17:53:37 http://permalink.gmane.org/gmane.linux.systemtap/19363 <pre>Here's what I'm getting with the latest run of the inode-uprobes code: === systemtap Summary === # of expected passes3087 # of unexpected failures136 # of unexpected successes7 # of expected failures246 # of unknown successes1 # of known failures42 # of untested testcases83 # of unsupported tests2 Not too shabby. A good number of the failures, 73, comes from the fact that the inode-uprobes code doesn't have return probes yet and that the systemtap code doesn't support .absolute probes with inode-uprobes since there is no (semi-easy) way to turn a raw address into file inode+offset. Note that it is possible that the failures related to process.return and process.absolute probes are masking other problems. - Tests failing because of the lack of process.return probes (and the number of failures in parens): systemtap.base/at_var.exp (1) systemtap.base/bz10078.exp (2) systemtap.base/bz6850.exp (2) systemtap.base/global_var.exp (6) systemtap.base/library.exp (8) systemtap.base/process_by_cmd</pre> David Smith 2012-05-21T18:58:56 http://permalink.gmane.org/gmane.linux.systemtap/19362 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 Mark Wielaard &lt;mjw at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #6 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-21 11:01:19 UTC --- Not really "fixed", but with the proper kernel patch, see comment #5, this should just work. Added a testcase to check the system is behaving properly. commit 07c9d78ebb28b888f01aed9c206e724f0e72db25 Author: Mark Wielaard &lt;mjw&lt; at &gt;redhat.com&gt; Date: Mon May 21 12:57:41 2012 +0200 Add testcase for PR14107 Bad user unwinding from kernel fatal signal handler This is really a kernel bug, see bug report, when the CFI for the assembly code is missing we cannot properly recover the register state for the user process and might give a bad/missing user backtrace. </pre> mjw at redhat dot com 2012-05-21T11:01:19 http://permalink.gmane.org/gmane.linux.systemtap/19361 <pre>A new automated systemtap source snapshot is available ftp://sourceware.org/pub/systemtap/snapshots/systemtap-20120519.tar.bz2 1966866 bytes, 4e8c027 tag See also ftp://sourceware.org/pub/systemtap/snapshots/ </pre> fche< at >sourceware.org 2012-05-19T14:27:23 http://permalink.gmane.org/gmane.linux.systemtap/19360 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=10607 Frank Ch. Eigler &lt;fche at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|need way to disable |need way to protect |global-setting module |sensitive tapset globals |params | --- Comment #1 from Frank Ch. Eigler &lt;fche at redhat dot com&gt; 2012-05-16 15:53:27 UTC --- Note that it's not sufficient to just disable -G foo=bar. An end-user script could equivalently include probe begin(1) { tapset_global = naughty_value } to mess with this. So we'd need a more general mechanism to protect tapset internal globals, whose change could cause problems. </pre> fche at redhat dot com 2012-05-16T15:53:27 http://permalink.gmane.org/gmane.linux.systemtap/19359 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=13745 --- Comment #6 from David Smith &lt;dsmith at redhat dot com&gt; 2012-05-15 19:41:20 UTC --- (In reply to comment #5) Originally it worked for me with 2.6.32-220.7.1.el6.x86_64. I just upgraded to 2.6.32-220.13.1.el6.x86_64 and it still works fine. </pre> dsmith at redhat dot com 2012-05-15T19:41:20 http://permalink.gmane.org/gmane.linux.systemtap/19358 <pre> I'm missing something. Why does the second item not moot the first? IOW, if we poll with a 5s timeout, why wouldn't the timer.s(1) reports wake up the ppoll() to avoid waiting till 5s? [FT] ppoll() wakes-up only when 1 buffer is full. timer.s(1) wakes-up whatever kernel thread (by the way, I should check that with contextswitch trace) but trace throughput is very low. After 5 seconds, ppoll time-outs and the 5 traces done by timer.s(1) at every second are dumped. When I say "do not use", it is really for interactivity with terminal. People may want to get some small metric every s, but 5 metrics will be displayed every 5s. Of course, for a log read later, you don't care. So, yes, people should be cautious with this but well, this is for embedded platforms and this is really our goal. - FChE Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 </pre> Turgis, Frederic 2012-05-15T15:29:38 http://permalink.gmane.org/gmane.linux.systemtap/19357 <pre> Hi, Frederic - f-turgis wrote: I'm missing something. Why does the second item not moot the first? IOW, if we poll with a 5s timeout, why wouldn't the timer.s(1) reports wake up the ppoll() to avoid waiting till 5s? - FChE </pre> Frank Ch. Eigler 2012-05-15T14:24:48 http://permalink.gmane.org/gmane.linux.systemtap/19356 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #5 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-15 14:14:41 UTC --- Looks like the RHEL6 kernel is missing this: commit 9e565292270a2d55524be38835104c564ac8f795 Author: Roland McGrath &lt;roland&lt; at &gt;redhat.com&gt; Date: Thu May 13 21:43:03 2010 -0700 x86: Use .cfi_sections for assembly code The newer assemblers support the .cfi_sections directive so we can put the CFI from .S files into the .debug_frame section that is preserved in unstripped vmlinux and in separate debuginfo, rather than the .eh_frame section that is now discarded by vmlinux.lds.S. Signed-off-by: Roland McGrath &lt;roland&lt; at &gt;redhat.com&gt; LKML-Reference: &lt;20100514044303.A6FE7400BE&lt; at &gt;magilla.sf.frob.com&gt; Signed-off-by: H. Peter Anvin &lt;hpa&lt; at &gt;zytor.com&gt; </pre> mjw at redhat dot com 2012-05-15T14:14:41 http://permalink.gmane.org/gmane.linux.systemtap/19355 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #4 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-15 14:07:27 UTC --- The problem isn't the CFI for do_page_fault, but that there is no CFI for page_fault. Nor does there seem to be any CFI for any assembly symbol defined in entry_64.S. Which explains why unwinding to the kernel/user space barrier just fails. No idea yet, why the CFI isn't included in /usr/lib/debug/lib/modules/*/vmlinux for the RHEL6 kernel, it certainly is there in entry_64.S source code. And it also is in the fedora version $ eu-readelf --debug-dump=frames /usr/lib/debug/lib/modules/3.3.5-2.fc16.x86_64/vmlinux | grep -B2 -A1 page_fault [ 7ae0] FDE length=68 cie=[ 6da8] CIE_pointer: 28072 initial_location: 0xffffffff815f4850 &lt;page_fault&gt; address_range: 0x2a </pre> mjw at redhat dot com 2012-05-15T14:07:27 http://permalink.gmane.org/gmane.linux.systemtap/19354 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14110 --- Comment #2 from william.jon.mccann at gmail dot com 2012-05-15 13:24:27 UTC --- Yeah. Those are the system data dirs. Now we need support for the per-user directories. </pre> william.jon.mccann at gmail dot com 2012-05-15T13:24:27 http://permalink.gmane.org/gmane.linux.systemtap/19353 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=13745 Frank Ch. Eigler &lt;fche at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fche at redhat dot com --- Comment #5 from Frank Ch. Eigler &lt;fche at redhat dot com&gt; 2012-05-15 12:44:23 UTC --- The new mmwriteback.stp gives an semantic_error for kernel.trace("mm_pdflush_kupdate") on 2.6.32-246.el6. What kernel version did that work for you with? </pre> fche at redhat dot com 2012-05-15T12:44:23 http://permalink.gmane.org/gmane.linux.systemtap/19352 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14110 Mark Wielaard &lt;mjw at redhat dot com&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mjw at redhat dot com --- Comment #1 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-15 11:32:04 UTC --- There seems to be already some support for XDG: commit 6ac63adf14504a7a3fd156a5c274c5aa53cbdec0 Author: Lukas Berk &lt;lukas&lt; at &gt;toomuchcaffeine.(none)&gt; Date: Tue Jun 8 15:10:19 2010 -0400 added the XDG_DATA_DIRS to session.cxx and the corresponding man changes as specified in bug #11455 </pre> mjw at redhat dot com 2012-05-15T11:32:04 http://permalink.gmane.org/gmane.linux.systemtap/19351 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14110 Bug #: 14110 Summary: Use XDG dirs instead of $HOME Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: william.jon.mccann&lt; at &gt;gmail.com Classification: Unclassified Seems to currently use ~/.systemtap. It would be better to use the locations defined in the XDG Base Directory specification. https://live.gnome.org/GnomeGoals/XDGConfigFolders </pre> william.jon.mccann at gmail dot com 2012-05-15T00:01:38 http://permalink.gmane.org/gmane.linux.systemtap/19350 <pre>Hi, Here is proposal for this tunable. I tested on OMAP with value X=50ms, 200ms, 345ms, 1s, 5s, 10s: - for low throughput trace, stapio wakes up precisely every X ms (scheduler switch probe + awk post-processing). Wakes-up every 200ms if option is not used - with high value such as 5 seconds, low throughput trace is dumped only every 5s. So of course, do not use probe timer.s(1) to get trace dumped every s on command line, you will have 5 correct infos in 1 shot every 5s. - no impact in performance, when trace throughput is high, ppoll() returns before timeout expires. For example, an Android video playback fills a buffer in 2 or 3s (scheduler contextswitch + irqs + workqueue monitoring) so 5s timeout expiration is not occuring. From f70a4385fd709af0079b293f27617e0c2968ae03 Mon Sep 17 00:00:00 2001 From: Frederic Turgis &lt;f-turgis&lt; at &gt;ti.com&gt; Date: Tue, 15 May 2012 04:56:14 +0200 Subject: [PATCH] Allow tuning of reader thread ppoll timeout value Default value of 200ms causes too many wake-ups for embedded </pre> Turgis, Frederic 2012-05-14T23:59:15 http://permalink.gmane.org/gmane.linux.systemtap/19349 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #3 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-14 22:22:51 UTC --- And we do actually go trough do_page_fault just before this frame: _stp_get_uregs:194: unwind levels: 17, ret: 0, pc=0xffffffff814f253e unwind:1452: pc=ffffffff814f253d, ffffffff814f253e unwind:1492: trying debug_frame set_no_state_rule:375: reg=10, where=1 _stp_search_unwind_hdr:777: binary search for ffffffff814f253d _stp_search_unwind_hdr:839: fde off=26520 _stp_search_unwind_hdr:849: returning fde=ffffffffa14be360 startLoc=ffffffff814f 2500 unwind_frame:1184: kernel: fde=ffffffffa14be360 unwind_frame:1189: kernel: cie=ffffffffa14bde28 parse_fde_cie:282: map retAddrReg value 16 to reg_info idx 16 unwind_frame:1203: startLoc: ffffffff814f2500, endLoc: ffffffff814f2597 unwind_frame:1251: cie=ffffffffa14bde28 fde=ffffffffa14be360 startLoc=ffffffff81 4f2500 endLoc=ffffffff814f2597, pc=ffffffff814f253d unwind_frame:1271: processCFI for CIE [...] unwind_frame:1426: returni</pre> mjw at redhat dot com 2012-05-14T22:22:51 http://permalink.gmane.org/gmane.linux.systemtap/19348 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #2 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-14 22:16:13 UTC --- (In reply to comment #1) According to /proc/kallsyms: ffffffff814ef8d0 T page_fault ffffffff814ef900 T machine_check </pre> mjw at redhat dot com 2012-05-14T22:16:13 http://permalink.gmane.org/gmane.linux.systemtap/19347 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 --- Comment #1 from Mark Wielaard &lt;mjw at redhat dot com&gt; 2012-05-14 15:47:52 UTC --- The issue is that on x86_64 (it doesn't happen on i686) stap tries to recover the user space registers by unwinding the kernel stack. This succeeds on the f16 kernel and then the unwinder takes those recovered registers to do the user space unwind. But it fails on the rhel6 kernel. See -DDEBUG_UNWIND=99 output: _stp_get_uregs:194: unwind levels: 15, ret: -5, pc=0xffffffff814ef8f5 _stp_get_uregs:209: failed to recover user reg state And the for user space the unwinder has to do with partial register values and fails... </pre> mjw at redhat dot com 2012-05-14T15:47:52 http://permalink.gmane.org/gmane.linux.systemtap/19346 <pre>http://sourceware.org/bugzilla/show_bug.cgi?id=14107 Bug #: 14107 Summary: Bad user unwinding from kernel fatal signal handler for some x86_64 kernels Product: systemtap Version: unspecified Status: NEW Severity: normal Priority: P2 Component: runtime AssignedTo: systemtap&lt; at &gt;sourceware.org ReportedBy: mjw&lt; at &gt;redhat.com CC: atomlin&lt; at &gt;redhat.com, bmr&lt; at &gt;redhat.com Classification: Unclassified The following program: int func (void) { int *foo = (void *) 0x1234; *foo = 0x12345; return 0; } int main (void) { return func (); } compiled with gcc -o bad_code bad_code.c and the following stap script: probe kernel.function("show_signal_msg") { /*(PF_USER | PR_WRITE) */ if (execname() == "bad_code") { if ($error_code &amp; 0x6) { printf ("\nUser mode process %s [pid: %d] received a SIGSEGV - error_code: 0</pre> mjw at redhat dot com 2012-05-14T15:39:55 http://permalink.gmane.org/gmane.linux.systemtap/19345 <pre> Thanks, that is much nicer than the scattered #if defined(DEBUG_TASK_FINDER_VMA) throughout the source. Pushed. There is also the plain DEBUG_TASK_FINDER (all non-vma stuff) that could be done in the same way. Thanks, Mark </pre> Mark Wielaard 2012-05-14T10:15:53 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.systemtap