headers
mjw at redhat dot com | 1 Mar 2012 17:10
Favicon

[Bug translator/13784] Cannot find a defining variable location in different CU

http://sourceware.org/bugzilla/show_bug.cgi?id=13784

--- Comment #1 from Mark Wielaard <mjw at redhat dot com> 2012-03-01 16:10:53 UTC ---
See for an extended usage (accessing vars from functions, not probes) PR11096.

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 1 Mar 2012 17:48
Favicon

[Bug testsuite/13745] memory tracepoints examples need updating

http://sourceware.org/bugzilla/show_bug.cgi?id=13745

--- Comment #2 from David Smith <dsmith at redhat dot com> 2012-03-01 16:48:17 UTC ---
Here's a list of the RHEL5 tracepoints and their current status vs RHEL6 and
upstream kernels:

- mm_anon_cow, mm_anon_fault, mm_anon_pgin, mm_anon_unmap,
mm_anon_userfree: Present in RHEL5, RHEL6 (but not upstream). Used by
mmanonpage.stp.

- mm_directreclaim_reclaimall: Present in RHEL5, RHEL6 (but not
upstream).  Used by mmreclaim.stp.

- mm_directreclaim_reclaimzone: Present in RHEL5, RHEL6 (but not
upstream).  Unused by any example script.

- mm_filemap_cow, mm_filemap_fault, mm_filemap_unmap,
mm_filemap_userunmap: Present in RHEL5, RHEL6 (but not upstream).  Used
by mmfilepage.stp.

- mm_kernel_pagefault: x86 only, present in RHEL5, RHEL6 (but not
upstream).  Unused by any example script.

- mm_kswapd_runs: Present in RHEL5.  RHEL6 has mm_kswapd_ran, which
might be an equivalent.  Unused by any example script.

- mm_page_allocation: Present in RHEL5.  RHEL6 and upstream has
mm_page_alloc.  Used by mmanonpage.stp and mmfilepage.stp.

- mm_page_free: Present in RHEL5.  RHEL6 has mm_page_free_direct.
(Continue reading)

Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 1 Mar 2012 18:01
Favicon

[Bug testsuite/13745] memory tracepoints examples need updating

http://sourceware.org/bugzilla/show_bug.cgi?id=13745

--- Comment #3 from David Smith <dsmith at redhat dot com> 2012-03-01 17:01:51 UTC ---
Here's the status of each example.  This assumes we map mm_page_allocation to
mm_page_alloc and mm_page_free to mm_page_free_direct.

- mmanonpage.stp: On RHEL6, compiles.  For upstream kernels, still missing
mm_anon_cow, mm_anon_fault, mm_anon_pgin, mm_anon_unmap, and mm_anon_userfree.

- mmfilepage.stp: On RHEL6, compiles.  For upstream kernels, still missing
mm_filemap_cow, mm_filemap_fault, mm_filemap_unmap, and mm_filemap_userunmap.

- mmreclaim.stp: On RHEL6, missing mm_pagereclaim_shrinkactive_a2a,
mm_pagereclaim_shrinkactive_a2i, mm_pagereclaim_shrinkinactive_i2a
and mm_pagereclaim_shrinkinactive_i2i.  It might be possible to rewrite the
script a bit to make those tracepoints optional, but I'm not sure how useful
the script would be at that point.

For upstream kernels, missing mm_directreclaim_reclaimall, mm_pagereclaim_free,
mm_pagereclaim_pgout, mm_pagereclaim_shrinkactive,
mm_pagereclaim_shrinkactive_a2a, mm_pagereclaim_shrinkactive_a2i,
mm_pagereclaim_shrinkinactive, mm_pagereclaim_shrinkinactive_i2a, and
mm_pagereclaim_shrinkinactive_i2i.

- mmwriteback.stp: On RHEL6 and upstream kernels, missing mm_pagereclaim_pgout,
mm_pdflush_bgwriteout, and mm_pdflush_kupdate.

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
(Continue reading)

Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 1 Mar 2012 18:28
Favicon

[Bug tapsets/13646] ipv6 tapset support

http://sourceware.org/bugzilla/show_bug.cgi?id=13646

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |13793

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 1 Mar 2012 18:28
Favicon

[Bug tapsets/13793] New: IPv6 nfs_proc.stp tapset changes needed

http://sourceware.org/bugzilla/show_bug.cgi?id=13793

             Bug #: 13793
           Summary: IPv6 nfs_proc.stp tapset changes needed
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tapsets
        AssignedTo: systemtap <at> sourceware.org
        ReportedBy: dsmith <at> redhat.com
        Depends on: 13646
    Classification: Unclassified

The nfs_proc.stp tapset is full of probes that return 'server_ip', a binary IP
address of the server.  A typical line to generate that value looks like this:

    server_ip = __i2n_ip_proto($dir,0)

That works fine for IPv4.  That binary value can be used in comparisons, as an
array index, etc.  However, the above doesn't work for IPv6.  That function (if
it supported IPv6) would return the address of a structure that holds the IPv6
address.

Those probes should be changed to return a string representation of the IP
address, which can be compared properly for both IPv4 and IPv6.

(Bug #13646 provided the base tapset IPv6 support.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
dsmith at redhat dot com | 1 Mar 2012 18:31
Favicon

[Bug tapsets/13646] ipv6 tapset support

http://sourceware.org/bugzilla/show_bug.cgi?id=13646

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from David Smith <dsmith at redhat dot com> 2012-03-01 17:31:23 UTC ---
Base IPv6 support added in commits: b88df2, d5c431, 258532, ac9732, 7447cb,
57d584, df7d21, 032226, 1ed417, 96f244, a3c777.  The tcp.stp tapset in
particular now works correctly with IPv4 and IPv6 addresses.  A testcase was
added to make sure IPv4 and IPv6 addresses are converted correctly.

(See bug #13793 for nfs_proc.stp changes split off from this bug.)

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
dsmith at redhat dot com | 1 Mar 2012 18:31
Favicon

[Bug tapsets/13793] IPv6 nfs_proc.stp tapset changes needed

http://sourceware.org/bugzilla/show_bug.cgi?id=13793

Bug 13793 depends on bug 13646, which changed state.

Bug 13646 Summary: ipv6 tapset support
http://sourceware.org/bugzilla/show_bug.cgi?id=13646

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
ch huang | 2 Mar 2012 03:28
Picon

problem in running systemtap

i compile and install the systemtap on CentOS5.7
# uname -r
2.6.18-274.17.1.el5

# yum list kernel-devel
kernel-devel.x86_64
             2.6.18-274.18.1.el5
                          installed

and make soft link on kernel-devel

# ls /usr/src/kernels/ -l
total 4
lrwxrwxrwx  1 root root   26 Mar  1 14:23 2.6.18-274.17.1.el5-x86_64
-> 2.6.18-274.18.1.el5-x86_64
drwxr-xr-x 19 root root 4096 Mar  1 11:23 2.6.18-274.18.1.el5-x86_64

here is debuginfo package i installed

# rpm -qa|grep debuginfo
kernel-debuginfo-2.6.18-274.el5
kernel-debuginfo-common-2.6.18-274.el5

and i modified the file translate.cxx to avoid the problem of release test

1 1540   o->newline() << "if (0 && strcmp (release, "
2 1541                << lex_cast_qstring (session->kernel_release) << ")) {";
3 1542   o->newline(1) << "_stp_error (\"module release mismatch (%s vs %s)\", "
(Continue reading)

Permalink | Reply | 0 comments |
headers
ch huang | 2 Mar 2012 03:38
Picon

problem in running systemtap

i compile and install the systemtap on CentOS5.7
# uname -r
2.6.18-274.17.1.el5

# yum list kernel-devel
kernel-devel.x86_64   2.6.18-274.18.1.el5    installed

and make soft link on kernel-devel

# ls /usr/src/kernels/ -l
total 4
lrwxrwxrwx  1 root root   26 Mar  1 14:23 2.6.18-274.17.1.el5-x86_64
-> 2.6.18-274.18.1.el5-x86_64
drwxr-xr-x 19 root root 4096 Mar  1 11:23 2.6.18-274.18.1.el5-x86_64

here is debuginfo package i installed

# rpm -qa|grep debuginfo
kernel-debuginfo-2.6.18-274.el5
kernel-debuginfo-common-2.6.18-274.el5

and i modified the file translate.cxx to avoid the problem of release test

1 1540   o->newline() << "if (0 && strcmp (release, "
2 1541                << lex_cast_qstring (session->kernel_release) << ")) {";
3 1542   o->newline(1) << "_stp_error (\"module release mismatch (%s vs %s)\", "

i compile systemtap use elfutils-0.145,and compile command is
./configure --prefix=/usr/local --with-elfutils=/root/package/elfutils-0.145
(Continue reading)

Permalink | Reply | 1 comment |
headers
Josh Stone | 2 Mar 2012 04:01
Picon
Favicon
Gravatar

Re: problem in running systemtap

On 03/01/2012 06:38 PM, ch huang wrote:
> i compile and install the systemtap on CentOS5.7
> # uname -r
> 2.6.18-274.17.1.el5
> 
> # yum list kernel-devel
> kernel-devel.x86_64   2.6.18-274.18.1.el5    installed
> 
> and make soft link on kernel-devel
> 
> # ls /usr/src/kernels/ -l
> total 4
> lrwxrwxrwx  1 root root   26 Mar  1 14:23 2.6.18-274.17.1.el5-x86_64
> -> 2.6.18-274.18.1.el5-x86_64
> drwxr-xr-x 19 root root 4096 Mar  1 11:23 2.6.18-274.18.1.el5-x86_64
> 
> here is debuginfo package i installed
> 
> # rpm -qa|grep debuginfo
> kernel-debuginfo-2.6.18-274.el5
> kernel-debuginfo-common-2.6.18-274.el5
> 
> and i modified the file translate.cxx to avoid the problem of release test
[...]

The "problem of release test" is serving a useful function.  For the
simple case of a begin probe, it may not matter that your running kernel
is slightly different than the -devel and -debuginfo versions.  It will
matter much more for probes that actually parse debuginfo, as you saw
with a syscall probe.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane