From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7133 invoked by alias); 1 Dec 2006 00:25:10 -0000 Received: (qmail 7074 invoked by uid 22791); 1 Dec 2006 00:25:09 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from rwcrmhc14.comcast.net (HELO rwcrmhc14.comcast.net) (204.127.192.84) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 01 Dec 2006 00:25:04 +0000 Received: from [192.168.1.8] (midgel.hsd1.ma.comcast.net[24.147.246.42]) by comcast.net (rwcrmhc14) with SMTP id <20061201002501m1400c52epe>; Fri, 1 Dec 2006 00:25:01 +0000 Subject: Re: Instrumenting context switches From: Dave Sperry Reply-To: dave_sperry@ieee.nospam.dot.org To: perryche@us.ibm.com Cc: systemtap@sourceware.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 01 Dec 2006 03:14:00 -0000 Message-Id: <1164932700.8146.22.camel@fc6-rt> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 (2.8.1.1-3.fc6) Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00568.txt.bz2 Hi Perry, I did not have to do anything to tell stap where to find the symbols. One thing you can check is that the debug symbols are located where the src/README file suggests. I also had to modify tapsets.cxx file to fix some rt Enums --- src_orig/tapsets.cxx 2006-11-17 15:35:47.000000000 -0500 +++ src/tapsets.cxx 2006-11-19 19:09:02.000000000 -0500 @@ -4332,13 +4332,13 @@ hrtimer_derived_probe_group::emit_module s.op->newline() << "for (i=0; i<" << probes.size() << "; i++) {"; s.op->newline(1) << "struct stap_hrtimer_probe* stp = & stap_hrtimer_probes [i];"; - s.op->newline() << "hrtimer_init (& stp->hrtimer, CLOCK_MONOTONIC, HRTIMER_REL);"; - s.op->newline() << "stp->hrtimer.function = & enter_hrtimer_probe;"; + s.op->newline() << "hrtimer_init (& stp->hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);"; + s.op->newline() << "stp->hrtimer.function = (void *)(& enter_hrtimer_probe);"; // There is no hrtimer field to identify *this* (i-th) probe handler // callback. So instead we'll deduce it at entry time. s.op->newline() << "(void) hrtimer_start (& stp->hrtimer, "; emit_interval (s.op); - s.op->line() << ", HRTIMER_REL);"; + s.op->line() << ", HRTIMER_MODE_REL);"; // Note: no partial failure rollback is needed: hrtimer_start only // "fails" if the timer was already active, which cannot be. s.op->newline(-1) << "}"; // for loop The other thing I do when thing behave strangely is flush the systemtap cache "rm -rf /root/.systemtap/cache/*" Dave > > > Hi Dave, > > I was using version 0.4 and have upgraded to version 0.5.11 like you > (mine's from today though and not 11/20). > However, the new stap can't find the probe points. I suspect that it is > not locating the kernel symbols file. > Do you know how to get the info out of the old /usr/bin/stap and give it > to the new /usr/local/bin/stap? > > > Perry > > > systemtap-owner@sourceware.org wrote on 11/30/2006 05:01:25 PM: > > > Perry, > > I had no problem running your systemtap scripts on my AMD-686 SMP box > > running the same kernel as you list below. > > > > I did a stap perry.stp -vvvv -g &>perryFoo.txt and it worked just fine. > > You can see the log at: > > > > http://toomanyprojects.org:2000/outbound/perry/perryFoo.txt > > > > > > The version of systemtap I used is: > > > > SystemTap translator/driver (version 0.5.11 built 2006-11-20) > > (Using Red Hat elfutils 0.124 libraries.) > > Copyright (C) 2005-2006 Red Hat, Inc. and others > > This is free software; see the source for copying conditions. > > > > > > Dave > > > > > Perry Cheng > > > > > com> To > > > Sent by: Martin Hunt , > > > > systemtap-owner@s systemtap@sourceware.org > > > ourceware.org cc > > > > > > Subject > > > 11/30/2006 03:29 Re: Instrumenting context > switches > > > PM > > > > > > The following even simpler program also dies and rules out > gettimeofday or > > > accessing a global variable as possible causes. The crash happens on > both > > > an intel-686 and AMD-686 both running a modified version of 2.6.16. I > > > don't know the details of the modifications but they are generally > used to > > > support real-time features and include the hrt and rt-prio patches. > The > > > src is at ftp://linuxpatch.ncsa.uiuc.edu/rt-linux/rhel4u2/R1-iFix1. > > > > > > If I replace __switch_to with context_switch or finish_task_switch, > the > > > failure still occurs. However, if I switch to set_task_comm, then > things > > > seem ok. > > > > > > probe kernel.function("__switch_to") > > > { > > > foobar() > > > } > > > > > > function foobar() > > > %{ > > > _stp_printf("foobar\n"); > > > %} > > > > > > Perry > > > > > > > > > systemtap-owner@sourceware.org wrote on 11/30/2006 10:31:10 AM: > > > > > > > On Wed, 2006-11-29 at 18:25 -0500, Perry Cheng wrote: > > > > > > > > > probe kernel.function("__switch_to") > > > > > { > > > > > doSwitchTo(gettimeofday_us(), $prev_p, $next_p); > > > > > } > > > > > > > > > > function doSwitchTo(timeus:long, prev:long, next:long) > > > > > %{ > > > > > _stp_printf("SWITCHCOUNT = %ld\n", switchCount); > > > > > <------------------------------ BAD LINE > > > > > switchCount++; > > > > > }% > > > > > > > > Obviously the code fragment above is not exactly what you are using > to > > > > reproduce the bug. (You can't use keywords as parameter names, > > > > uninitialized switchCount, "}%", etc). I tried the following and > did > > > > not see any problems. Can you give more details (arch, OS, etc) on > how > > > > to reproduce? > > > > > > > > %{ > > > > long switchCount = 1000000; > > > > %} > > > > > > > > function doSwitchTo (t:long, p:long, n:long) %{ > > > > _stp_printf("SWITCHCOUNT = %ld\n", switchCount); > > > > switchCount++; > > > > %} > > > > > > > > probe kernel.function("__switch_to") > > > > { > > > > doSwitchTo(gettimeofday_us(), $prev_p, $next_p); > > > > } > > > > > > > > > > > > > > > > > > > > > >