public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* scsi.stp won't run
@ 2006-01-11 12:54 Martin Peschke
  2006-01-11 14:00 ` Li Guanglei
  0 siblings, 1 reply; 8+ messages in thread
From: Martin Peschke @ 2006-01-11 12:54 UTC (permalink / raw)
  To: systemtap

Hi,

I'd like to try the kernel event trace tool
(http://sourceware.org/ml/systemtap/2005-q4/msg00458.html).
When running "stap -vg -I . sample.stp" I get the following
error, and similar errors for other scsi probes:

parsed 'scsi_io_completion' -> func 'scsi_io_completion'
pattern 'scsi_mod' matches module 'scsi_mod'
focused on module 'scsi_mod' = [f8857000-f8878169, bias 0]
semantic error: cannot find module scsi_mod debuginfo: Unsupported 
relocation type
semantic error: no match for probe point
          while: resolving probe point 
module("scsi_mod").function("scsi_io_completion")
semantic error: no match for probe point
          while: resolving probe point addevent.scsi.iocompleted
semantic error: no match for probe point
          while: resolving probe point addevent.scsi

Parsing of other *.stp files seems to okay.

I have verfied that stap is working by running other simple sample 
probes successfully. kernel-debuginfo is installed and does provide
/usr/lib/debug/lib/modules/2.6.14-1.1653_FC4/kernel/drivers/scsi/scsi_mod.ko.debug
scsi_mod has been loaded as a module.

[root@dyn-9-152-230-71 guanglei]# stap -V
SystemTap translator/driver (version 0.5.2 built 2005-12-19)

Do you have got any idea what is going wrong?
Thank you.

Martin

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-11 12:54 scsi.stp won't run Martin Peschke
@ 2006-01-11 14:00 ` Li Guanglei
  2006-01-12 12:37   ` Martin Peschke
  0 siblings, 1 reply; 8+ messages in thread
From: Li Guanglei @ 2006-01-11 14:00 UTC (permalink / raw)
  To: Martin Peschke; +Cc: systemtap

Martin Peschke :
> Hi,
> 
> I'd like to try the kernel event trace tool
> (http://sourceware.org/ml/systemtap/2005-q4/msg00458.html).
> When running "stap -vg -I . sample.stp" I get the following
> error, and similar errors for other scsi probes:
> 
> parsed 'scsi_io_completion' -> func 'scsi_io_completion'
> pattern 'scsi_mod' matches module 'scsi_mod'
> focused on module 'scsi_mod' = [f8857000-f8878169, bias 0]
> semantic error: cannot find module scsi_mod debuginfo: Unsupported 
> relocation type
> semantic error: no match for probe point

I am not sure if the error you got is the same as I got before:

WARNING: cannot find module scsi_mod debuginfo: relocation refers to
undefined symbol
semantic error: no match for probe point
          while: resolving probe point

But this bug has been fixed by the elfutils-0.118-1

You can try the latest elfutils

I can sucessfully run all the tapsets with elfutils-0.118-1 & 2.6.9-27EL





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-11 14:00 ` Li Guanglei
@ 2006-01-12 12:37   ` Martin Peschke
  2006-01-12 15:25     ` Guanglei Li
  2006-01-13 10:55     ` Li Guanglei
  0 siblings, 2 replies; 8+ messages in thread
From: Martin Peschke @ 2006-01-12 12:37 UTC (permalink / raw)
  To: Li Guanglei; +Cc: systemtap

Li Guanglei wrote:
> Martin Peschke :
> 
>> Hi,
>>
>> I'd like to try the kernel event trace tool
>> (http://sourceware.org/ml/systemtap/2005-q4/msg00458.html).
>> When running "stap -vg -I . sample.stp" I get the following
>> error, and similar errors for other scsi probes:
>>
>> parsed 'scsi_io_completion' -> func 'scsi_io_completion'
>> pattern 'scsi_mod' matches module 'scsi_mod'
>> focused on module 'scsi_mod' = [f8857000-f8878169, bias 0]
>> semantic error: cannot find module scsi_mod debuginfo: Unsupported 
>> relocation type
>> semantic error: no match for probe point
> 
> 
> I am not sure if the error you got is the same as I got before:
> 
> WARNING: cannot find module scsi_mod debuginfo: relocation refers to
> undefined symbol
> semantic error: no match for probe point
>          while: resolving probe point
> 
> But this bug has been fixed by the elfutils-0.118-1
> 
> You can try the latest elfutils
> 
> I can sucessfully run all the tapsets with elfutils-0.118-1 & 2.6.9-27EL

Updating elfutils didn't do the trick for me. I have not replaced my
kernel, though.

Martin

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-12 12:37   ` Martin Peschke
@ 2006-01-12 15:25     ` Guanglei Li
  2006-01-12 15:49       ` Frank Ch. Eigler
  2006-01-13 10:55     ` Li Guanglei
  1 sibling, 1 reply; 8+ messages in thread
From: Guanglei Li @ 2006-01-12 15:25 UTC (permalink / raw)
  To: Martin Peschke; +Cc: systemtap


> Martin Peschke :
>
> Updating elfutils didn't do the trick for me. I have not replaced my
> kernel, though.
>
> Martin
>
could you tell me a little more info of your running environment? e.g. 
the kernel version, machine type(ppc or x86 etc), so that I'll try to 
reproduce your error to see what's wrong.
thanks.


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-12 15:25     ` Guanglei Li
@ 2006-01-12 15:49       ` Frank Ch. Eigler
  2006-01-13 18:22         ` Martin Peschke
  0 siblings, 1 reply; 8+ messages in thread
From: Frank Ch. Eigler @ 2006-01-12 15:49 UTC (permalink / raw)
  To: Guanglei Li; +Cc: Martin Peschke, systemtap

"Guanglei Li" <guanglei@cn.ibm.com> writes:

> > Updating elfutils didn't do the trick for me. I have not replaced my
> > kernel, though.

There are some known problems with faulty .ko / .ko.debug files being
*generated* by recent elfutils - that is, with someone replacing the
system elfutils with one of the 0.11* series, and building a new
kernel.  It seems like the most robust way to go is to leave the old
system elfutils alone, and use the "--with-elfutils=PATH" systemtap
configure option to build a private copy.

- FChE

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-12 12:37   ` Martin Peschke
  2006-01-12 15:25     ` Guanglei Li
@ 2006-01-13 10:55     ` Li Guanglei
  1 sibling, 0 replies; 8+ messages in thread
From: Li Guanglei @ 2006-01-13 10:55 UTC (permalink / raw)
  To: Martin Peschke; +Cc: systemtap

>>
>> I can sucessfully run all the tapsets with elfutils-0.118-1 & 2.6.9-27EL
> 
> 
> Updating elfutils didn't do the trick for me. I have not replaced my
> kernel, though.
> 
> Martin
> 
I also tried
    2.6.14(from kernel.org)
    elfutils-0.118-1(rpm package from 
ftp://sources.redhat.com/pub/systemtap/elfutils/)
    latest systemtap
    ppc64 platform(openpower 720)

it also worked. anyway, I will involve more testing work of this trace 
tool on more kernel versions to make it better.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-12 15:49       ` Frank Ch. Eigler
@ 2006-01-13 18:22         ` Martin Peschke
  2006-01-15 14:11           ` Li Guanglei
  0 siblings, 1 reply; 8+ messages in thread
From: Martin Peschke @ 2006-01-13 18:22 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Guanglei Li, systemtap

Frank Ch. Eigler wrote:
> There are some known problems with faulty .ko / .ko.debug files being
> *generated* by recent elfutils - that is, with someone replacing the
> system elfutils with one of the 0.11* series, and building a new
> kernel.  It seems like the most robust way to go is to leave the old
> system elfutils alone, and use the "--with-elfutils=PATH" systemtap
> configure option to build a private copy.

No success, yet. *sigh*

My latest attempt comprised:

downgrading back to elfutils-0.108-1
downloading systemtap-0.5.2-1.src.rpm
rpm -ivh SRPMS/systemtap-0.5.2-1.src.rpm
rpmbuild -ba SPECS/systemtap.spec
	(something related to elfutils-0.118 happened as well
	 during this step,
	 2 systemtap testcases failed BTW)
rpm -ivh RPMS/i386/systemtap-0.5.2-1.i386.rpm

Still, I get:

[root@dyn-9-152-230-71 guanglei]# stap -vg -I . sample.stp
[...]
parsed 'scsi_io_completion' -> func 'scsi_io_completion'
pattern 'scsi_mod' matches module 'scsi_mod'
focused on module 'scsi_mod' = [f8857000-f8877ee9, bias 0]
semantic error: cannot find module scsi_mod debuginfo: Unsupported 
relocation type
semantic error: no match for probe point
          while: resolving probe point 
module("scsi_mod").function("scsi_io_completion")
semantic error: no match for probe point
          while: resolving probe point addevent.scsi.iocompleted
semantic error: no match for probe point
          while: resolving probe point addevent.scsi
Pass 2: analyzed user script.  10 probe(s), 26 function(s), 15 global(s).
Pass 2: analysis failed.  Try again with '-v' (verbose) option.

I am not sure whether I managed to followed your advice.
Do I need to change the systemtap.spec in order to the config option
you have mentioned?

I am running a recently updated Fedora Core 4 system
(2.6.15-1.1823_FC4 #1 Fri Jan 6 17:54:53 EST 2006 i686 i686 i386).

Since the problem seems to be related to the fact that I want
to place a probe in a module, what about rebuilding the kernel
with a built-in scsi_mod (as a workaround)?
I would need to rebuild the kernel-debuginfo rpm as well. How do
I do the latter? What is about kernel-devel?

Thanks.

Martin

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: scsi.stp won't run
  2006-01-13 18:22         ` Martin Peschke
@ 2006-01-15 14:11           ` Li Guanglei
  0 siblings, 0 replies; 8+ messages in thread
From: Li Guanglei @ 2006-01-15 14:11 UTC (permalink / raw)
  To: Martin Peschke; +Cc: Frank Ch. Eigler, systemtap

> downgrading back to elfutils-0.108-1
  typo error? should be elftuls-0.118-1, right?
> downloading systemtap-0.5.2-1.src.rpm
> rpm -ivh SRPMS/systemtap-0.5.2-1.src.rpm
> rpmbuild -ba SPECS/systemtap.spec
>     (something related to elfutils-0.118 happened as well
>      during this step,
>      2 systemtap testcases failed BTW)
> rpm -ivh RPMS/i386/systemtap-0.5.2-1.i386.rpm


> I am not sure whether I managed to followed your advice.
> Do I need to change the systemtap.spec in order to the config option
> you have mentioned?
I always download the latest source codes from CVS and then make 
systemtap. Or you can just use the latest snapshot of systemtap source 
codes. The later, the fewer bugs.

> 
> I am running a recently updated Fedora Core 4 system
> (2.6.15-1.1823_FC4 #1 Fri Jan 6 17:54:53 EST 2006 i686 i686 i386).
I ran on RHEL(U2 & U3). I never tried FC4.

> Since the problem seems to be related to the fact that I want
> to place a probe in a module, what about rebuilding the kernel
> with a built-in scsi_mod (as a workaround)?
It will do. Remember to modify the scsi.stp to change 
module("scsi_mod").function("foo") to kernel.function("foo")
> I would need to rebuild the kernel-debuginfo rpm as well. How do
> I do the latter? What is about kernel-devel?
If you have the kernel src rpm package, then you can:
   1. rpm -Uvh kernel-src-.rpm
   2. vi /usr/src/redhat/SPECS/kernel-2.6.spec, uncomment unnecessary 
options, e.g:

   %define buildup 0
   %define buildsmp 1
   %define buildsource 0
   %define buildhugemem 0
   %define buildlargesmp 0
   %define builddoc 0
   %define kabi 1

   3. You may need modify /usr/src/redhat/SPECS/kernel-2.6.spec 
because of the bug 
#1966(http://sourceware.org/bugzilla/show_bug.cgi?id=1966)
   4. rpmbuild -ba /usr/src/redhat/SPECS/kernel-2.6.spec --target=i686
   5. look at /usr/src/redhat/RPMS for the devel, debuginfo and kernel 
rpm package

If you compile the kernel using mainline kernel src package for 
kernel.org, you should:
   1. enable "compile debuginfo for kernel" & "kprobe" when "make 
menuconfig"
   2. make & install the kernel
   3. cp /usr/src/linux-2.6.15/vmlinux  /boot/vmlinux-2.5.16

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-01-15 14:11 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-11 12:54 scsi.stp won't run Martin Peschke
2006-01-11 14:00 ` Li Guanglei
2006-01-12 12:37   ` Martin Peschke
2006-01-12 15:25     ` Guanglei Li
2006-01-12 15:49       ` Frank Ch. Eigler
2006-01-13 18:22         ` Martin Peschke
2006-01-15 14:11           ` Li Guanglei
2006-01-13 10:55     ` Li Guanglei

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).