From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3276 invoked by alias); 13 Jun 2003 19:47:30 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 3183 invoked from network); 13 Jun 2003 19:47:29 -0000 Received: from unknown (HELO Cantor.suse.de) (213.95.15.193) by sources.redhat.com with SMTP; 13 Jun 2003 19:47:29 -0000 Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136]) by Cantor.suse.de (Postfix) with ESMTP id 119FF1483A; Fri, 13 Jun 2003 21:47:29 +0200 (MEST) Received: from aj by arthur.inka.de with local (Exim 4.12) id 19QuFb-0004IW-00; Fri, 13 Jun 2003 21:30:15 +0200 To: Steve Munroe Cc: libc-hacker@sources.redhat.com, libc-alpha@sources.redhat.com Subject: Re: tst-nanosleep, tst-clock_nanosleep Failures References: From: Andreas Jaeger Date: Fri, 13 Jun 2003 19:47:00 -0000 In-Reply-To: (Steve Munroe's message of "Fri, 13 Jun 2003 14:15:19 -0500") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00023.txt.bz2 Steve Munroe writes: > Is anyone else seeing make check failures in tst-nanosleep and > tst-clock_nanosleep? > > I see these fail at various times (7.5%+ failure rate) on PPC64 (both 2.4 > and 2.5) kernels running either PPC32 or PPC64 applications. These are all > SMP machines. In each case the measured time averages 0.5 jiffies less > than 1 second! > > The nanosleep code is in the kernel is arch independent so I would expect > this test to fail on the SMP platforms? Perhaps your clock is going wrong? The time keeping code is architecture dependend... Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj