public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Pavan Naregundi <pavan.naregundi@in.ibm.com>
To: Mark Wielaard <mjw@redhat.com>
Cc: systemtap@sourceware.org
Subject: Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
Date: Tue, 28 Apr 2009 05:11:00 -0000	[thread overview]
Message-ID: <OFA7D7C6F7.6242D507-ON652575A6.001C2DDF-652575A6.001C7F83@in.ibm.com> (raw)
In-Reply-To: <1240843370.4387.45.camel@fedora.wildebeest.org>


Mark Wielaard <mjw@redhat.com> wrote on 04/27/2009 08:12:50 PM:

> From:
>
> Mark Wielaard <mjw@redhat.com>
>
> To:
>
> Pavan Naregundi/India/IBM@IBMIN
>
> Cc:
>
> systemtap@sourceware.org
>
> Date:
>
> 04/27/2009 08:10 PM
>
> Subject:
>
> Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
>
> Hi Pavan,
>
> On Mon, 2009-04-27 at 17:17 +0530, Pavan Naregundi wrote:
> > Results of systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2
> > Arch: ppc64
> >
> > Please contact me, for any other details.
>
> Thanks for testing this combination. Which elfutils version did you use?

It is elfutils-0.141.tar.bz2..

>
> > Unexpected failures
> > =============================
> > FAIL: LOCAL1 (0)
>
> I have seen this fail sporadically, is it failing always for you?
>
> > FAIL: STRUCT1 (0)
>
> Could you post the relevant part of the testsuite/systemtap.log?
>
> > FAIL: backtrace (1 0)
> > FAIL: backtrace-unwindsyms (1 0)
>
> This is http://sourceware.org/bugzilla/show_bug.cgi?id=6961
> "backtrace from non-pt_regs probe context"
>
> > FAIL: systemtap.base/cast.stp
> > FAIL: debugpath-bad (eof)
> > FAIL: debugpath-good (eof)
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: gtod (9)
>
> This is probably http://sourceware.org/bugzilla/show_bug.cgi?id=5094
> "gtod.exp fails on ppc64/i386"
>
> > FAIL: MAXACTIVE01 compilation
> > FAIL: MAXACTIVE02 compilation
> > FAIL: conditional probes (0)
> > FAIL: OVERLOAD1 compilation
> > FAIL: OVERLOAD2 compilation
> > FAIL: OVERLOAD3 compilation
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: compiling sdt.c ""
> > FAIL: compiling sdt.c additional_flags=-std=gnu89
> > FAIL: compiling sdt.c additional_flags=-ansi
> > FAIL: compiling sdt.c additional_flags=-pedantic
> > FAIL: compiling sdt.c additional_flags=-ansi additional_flags=-pedantic
> > FAIL: compiling sdt.c additional_flags=-O2
> > FAIL: compiling sdt.c additional_flags="-O3"
> > FAIL: static_uprobes compiling C -g
>
> That probably means the sdt.h header doesn't compile on ppc.
> Could you see if testsuite/systemtap.log gives more hints about what is
> wrong? What gcc version are you using?
>
> > FAIL: stmtvars - .function
> > FAIL: system_func (0,0,0)
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: backtrace of yyy_func2 (1)
> > FAIL: print_stack of yyy_func2 (1)
> > FAIL: backtrace of yyy_func3 (1)
> > FAIL: print_stack of yyy_func3 (1)
> > FAIL: backtrace of yyy_func4 (1)
> > FAIL: print_stack of yyy_func4 (1)
>
> These might need support for the dwarf unwinder on ppc to provide more
> accurate backtraces.
> http://sourceware.org/ml/systemtap/2009-q2/msg00307.html
>
> > FAIL: integer function arguments -- numeric
> > FAIL: unsigned function arguments -- numeric
> > FAIL: long function arguments -- numeric
> > FAIL: int64 function arguments -- numeric
> > FAIL: char function arguments -- numeric
> > FAIL: string function arguments -- numeric
> > FAIL: integer function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: unsigned function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: long function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: int64 function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: char function arguments -- numeric --kelf --ignore-dwarf
> > FAIL: string function arguments -- numeric --kelf --ignore-dwarf
>
> Could you post the relevant parts of the testsuite/systemtap.log for the
> above failures?
>
> > FAIL: systemtap.examples/general/para-callgraph build
> > FAIL: systemtap.examples/general/para-callgraph run
>
> Likewise.
>
> > FAIL: buildok/maxactive01.stp
> > FAIL: buildok/signal-all-probes.stp
> > FAIL: buildok/thirteen.stp
> > FAIL: semok/thirtytwo.stp
> > FAIL: semok/twentyeight.stp
> > FAIL: semok/twentyfour.stp
> > FAIL: semok/twentynine.stp
> > FAIL: semok/twentyseven.stp
> > FAIL: systemtap.printf/bin6.stp
> > FAIL: systemtap.stress/current.stp shutdown (eof)
>
>
> Some of these might be solved with an updated elfutils (0.141). At least
> that was the case for s390.
>
> > FAIL: 64-bit acct
> > FAIL: 64-bit net1
> > FAIL: 64-bit readwrite
> > FAIL: 64-bit signal
> > FAIL: 32-bit acct
> > FAIL: 32-bit net1
> > FAIL: 32-bit readwrite
> > FAIL: 32-bit signal
> > FAIL: 32-bit statfs
>
> The net1 failures are
> http://sourceware.org/bugzilla/show_bug.cgi?id=6991
> "accept system call missed on 2.6.27"
>
> For the others look in the systemtap.log file and/or try running the
> tests in testsuite/systemtap.syscall by hand. There is a README there
> explaining how the tests work and how to use the tcl framework to see
> how things should match.
>
> Thanks,
>
> Mark
>

  reply	other threads:[~2009-04-28  5:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-27 11:49 Pavan Naregundi
2009-04-27 14:43 ` Mark Wielaard
2009-04-28  5:11   ` Pavan Naregundi [this message]
2009-04-28  6:02   ` Pavan Naregundi
2009-04-28  6:07     ` Ananth N Mavinakayanahalli
2009-04-29  9:37     ` Mark Wielaard
2009-04-29 19:01       ` Josh Stone
2009-04-29  9:41     ` Mark Wielaard
2009-04-28  6:56   ` Ananth N Mavinakayanahalli
2009-04-29  8:57     ` Mark Wielaard
2009-04-29  9:26       ` Ananth N Mavinakayanahalli
2009-04-29 12:08         ` Mark Wielaard
2009-04-29 12:21           ` Ananth N Mavinakayanahalli
2009-04-29 12:27             ` Mark Wielaard
2009-04-29 13:15           ` David Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OFA7D7C6F7.6242D507-ON652575A6.001C2DDF-652575A6.001C7F83@in.ibm.com \
    --to=pavan.naregundi@in.ibm.com \
    --cc=mjw@redhat.com \
    --cc=systemtap@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).