From owner-freebsd-stable@FreeBSD.ORG Wed Sep 9 20:42:13 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2916106568B for ; Wed, 9 Sep 2009 20:42:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 73B4A8FC18 for ; Wed, 9 Sep 2009 20:42:13 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 109FB46B38; Wed, 9 Sep 2009 16:42:13 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 49E698A01B; Wed, 9 Sep 2009 16:42:12 -0400 (EDT) From: John Baldwin To: Luigi Rizzo Date: Wed, 9 Sep 2009 16:42:05 -0400 User-Agent: KMail/1.9.7 References: <20090906155154.GA8283@onelab2.iet.unipi.it> <200909091324.53668.jhb@freebsd.org> <20090909203216.GA93761@onelab2.iet.unipi.it> In-Reply-To: <20090909203216.GA93761@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909091642.06046.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 09 Sep 2009 16:42:12 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-stable@freebsd.org Subject: Re: incorrect usleep/select delays with HZ > 2500 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 20:42:13 -0000 On Wednesday 09 September 2009 4:32:16 pm Luigi Rizzo wrote: > On Wed, Sep 09, 2009 at 01:24:53PM -0400, John Baldwin wrote: > > On Tuesday 08 September 2009 5:01:00 pm Luigi Rizzo wrote: > > > On Tue, Sep 08, 2009 at 01:08:23PM -0400, John Baldwin wrote: > > > > On Sunday 06 September 2009 11:51:54 am Luigi Rizzo wrote: > > > > > [Note 3] the TSC frequency is computed reading the tsc around a > > > > > call to DELAY(1000000) and assuming that the i8254 runs > > > > > at the nominal rate, 1.193182 MHz. > > > > > From tests I have made, the measurement in init_TSC() returns > > > > > a large error when HZ is large, whereas repeating the > > measurement > > > > > at a later time returns a much more reliable value. > ... > > > > Try disabling legacy USB support in the BIOS to see if an SMI# is firing > > > > during the DELAY() causing the TSC freq to be too high. I have seen the > > USB > > > > legacy support cause this in other machines. > > > > > > Thanks, will try tomorrow. > > > Would this explain the measurement becomes better as we get > > > further into the initialization, and why high HZ values affect > > > the measurement ? > > > > It would explain why it gets better later since the uhci(4), ohci(4) and > > ehci(4) drivers disable the SMI# interrupts while attaching to the > > controllers. > > ok makes sense -- if the SMI interrupts last longer than 1/HZ > they will cause us to miss one or more wraps of the i8254 in > $ARCH/isa/clock.c::DELAY(). I suppose with a few measurements > at different HZ values and some back of the envelope calculations > one could even determine estimate the frequency and duration > of those SMI interrupts! On recent motherboards I have seen the SMI# interrupt fire every 250 ms with execution times ranging from 50 us to 1ms for the legacy USB interrupt handler. We consistently see the TSC frequency miscalculated on the motherboards with the 1ms duration interrupt. I suspect that the clock that drives the periodic SMI# interrupt is tied to the i8254 meaning that it often fires at the same time that the i8254 wraps causing the TSC frequency to often be wrong. -- John Baldwin