From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20291 invoked by alias); 29 Apr 2009 08:57:19 -0000 Received: (qmail 20281 invoked by uid 22791); 29 Apr 2009 08:57:18 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Apr 2009 08:57:09 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n3T8v5WO020448; Wed, 29 Apr 2009 04:57:05 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n3T8v4lw002037; Wed, 29 Apr 2009 04:57:04 -0400 Received: from [10.32.10.142] (vpn-10-142.str.redhat.com [10.32.10.142]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n3T8v2RK007292; Wed, 29 Apr 2009 04:57:03 -0400 Subject: Re: Systemtap snap:b6371390 test on kernel 2.6.30-rc3-git2 From: Mark Wielaard To: ananth@in.ibm.com Cc: Pavan Naregundi , systemtap@sourceware.org In-Reply-To: <20090428065617.GD1531@in.ibm.com> References: <1240843370.4387.45.camel@fedora.wildebeest.org> <20090428065617.GD1531@in.ibm.com> Content-Type: text/plain Date: Wed, 29 Apr 2009 08:57:00 -0000 Message-Id: <1240995422.2389.2.camel@fedora.wildebeest.org> Mime-Version: 1.0 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: 2009-q2/txt/msg00468.txt.bz2 On Tue, 2009-04-28 at 12:26 +0530, Ananth N Mavinakayanahalli wrote: > On Mon, Apr 27, 2009 at 04:42:50PM +0200, Mark Wielaard wrote: > > 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 > > > > > > FAIL: LOCAL1 (0) > > I've seen the above fail with LOCAL1 (2), which actually needs to be > flagged as a success. I guess the issue is with checking of rc -- down > in alternatives.exp: > > - if {$rc == 1} { pass $test } else { fail "$test ($rc)" } > + if {$rc >= 1} { pass $test } else { fail "$test ($rc)" } > > should fix the problem. Yes, that seems fine. The LOCAL1 (0) failure case is as you observed because of the syscall wrappers issue (I am thinking about the patch you proposed in PR10007 and testing it locally - x86_64 only for now though). Cheers, Mark