From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9292 invoked by alias); 22 Oct 2008 12:56:46 -0000 Received: (qmail 9282 invoked by uid 22791); 22 Oct 2008 12:56:45 -0000 X-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_20,J_CHICKENPOX_63,KAM_MX,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Oct 2008 12:56:10 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m9MCu8nH007585 for ; Wed, 22 Oct 2008 08:56:08 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m9MCu74p032233 for ; Wed, 22 Oct 2008 08:56:08 -0400 Received: from [10.32.4.55] (vpn-4-55.str.redhat.com [10.32.4.55]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id m9MCu6Ha012436 for ; Wed, 22 Oct 2008 08:56:07 -0400 Subject: make installcheck results From: Mark Wielaard To: systemtap@sources.redhat.com Content-Type: text/plain Date: Wed, 22 Oct 2008 12:56:00 -0000 Message-Id: <1224680166.3266.30.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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: 2008-q4/txt/msg00173.txt.bz2 Hi, I have been working on getting the number of known failures in the make installcheck as close to zero as possible. We are almost there for at least one architecture, 2.6.18/86_64/el5 kernel, but others are still some way off. Here is an overview of the machines I tested on. The only downside of doing a full make installcheck is that it takes about an hour on some machines. But it often catches regressions. So I would encourage people to run it occasionally when adding patches. All results were against git master of this morning (commit dd09ee8f) with elfutils 0.137 + two patches (see bug #6928). - 2.6.18-92.1.13.el5 x86_64 # of expected passes 621 # of unexpected failures 4 # of unexpected successes 8 # of expected failures 200 # of unknown successes 2 # of known failures 5 # of untested testcases 24 # of unsupported tests 3 FAIL: systemtap.base/stmt_rel.stp FAIL: buildok/twentyfive.stp FAIL: buildok/vfs-all-probes.stp FAIL: buildok/vfs_testcase.stp stmt_rel.stp seems to be either an optimisation or missing debug line info in the function being tested (the tests expects to hit 4 different lines, but only hits 3). twentyfive.stp seems to be an elfutils regression. Tracked in bug #6950. Needs a simpler reproducer. The vfs tests have a pending patch in bug #6972. - 2.6.18-92.1.13.el5 # of expected passes 583 # of unexpected failures 14 # of unexpected successes 8 # of expected failures 200 # of unknown successes 2 # of known failures 5 # of untested testcases 24 # of unsupported tests 1 FAIL: bad kprobe registration (eof) FAIL: systemtap.base/global_init.stp shutdown (eof) FAIL: systemtap.base/if.stp shutdown (eof) FAIL: systemtap.base/inc.stp shutdown (eof) FAIL: systemtap.base/not.stp shutdown (eof) FAIL: systemtap.base/print.stp shutdown (eof) FAIL: systemtap.base/stmt_rel.stp FAIL: systemtap.base/tri.stp shutdown (eof) FAIL: buildok/twentyfive.stp FAIL: buildok/vfs-all-probes.stp FAIL: buildok/vfs_testcase.stp FAIL: gtod (228) FAIL: 32-bit futimes FAIL: 32-bit stat The (oef) test failures might be test harness glitches. gtod needs investigation. The 32-bit futimes and stat produce the wrong time because the argument is shorter than expected (64-bit). Rest same as above. - 2.6.26.5-45.fc9.x86_64 # of expected passes 632 # of unexpected failures 14 # of unexpected successes 8 # of expected failures 200 # of known failures 7 # of untested testcases 4 # of unsupported tests 2 FAIL: bz6850 -p4 FAIL: bz6850 -p5 FAIL: systemtap.base/stmt_rel.stp FAIL: uprobes -p4 FAIL: uprobes -p5 (0) FAIL: systemtap.examples/process/sig_by_pid build FAIL: systemtap.examples/process/sig_by_pid run FAIL: systemtap.examples/process/sig_by_proc build FAIL: systemtap.examples/process/sig_by_proc run FAIL: systemtap.examples/process/sigkill build FAIL: systemtap.examples/process/sigkill run FAIL: systemtap.examples/process/sigmon build FAIL: systemtap.examples/process/sigmon run FAIL: buildok/signal-all-probes.stp This kernel doesn't support uprobes yet, causing the bz6850 and uprobes failures. All the signal related failures seem to come down to a gcc inline optimization described in bug #1155 Rest as above. - 2.6.26.5-28.fc8 i386 # of expected passes 581 # of unexpected failures 17 # of unexpected successes 8 # of expected failures 200 # of unknown successes 1 # of known failures 6 # of untested testcases 24 FAIL: bad kprobe registration (eof) FAIL: bz6850 -p4 FAIL: bz6850 -p5 FAIL: systemtap.base/stmt_rel.stp FAIL: uprobes -p4 FAIL: uprobes -p5 (0) FAIL: backtrace of yyy_func2 (2) FAIL: print_stack of yyy_func2 (2) FAIL: backtrace of yyy_func3 (2) FAIL: print_stack of yyy_func3 (2) FAIL: backtrace of yyy_func4 (2) FAIL: print_stack of yyy_func4 (2) FAIL: buildok/twentyfive.stp FAIL: semok/twenty.stp FAIL: systemtap.printf/memory1.stp FAIL: 32-bit futimes FAIL: 32-bit stat The el5 kernels don't have CONFIG_FRAME_POINTER defined, the fedora kernels do have it defined for x86. Which seem to cause the backtrace mismatches. I'll investigate whether my unwind based backtrace work can give better results here. The twenty.stp and memory1.stp need investigation. Rest as above.