From owner-freebsd-current@FreeBSD.ORG Thu Oct 16 16:52:17 2008 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 446C910656AB; Thu, 16 Oct 2008 16:52:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id ED8C38FC1A; Thu, 16 Oct 2008 16:52:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9GGn1r8014970; Thu, 16 Oct 2008 10:49:01 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Oct 2008 10:50:02 -0600 (MDT) Message-Id: <20081016.105002.-1975970550.imp@bsdimp.com> To: taku@tackymt.homeip.net From: "M. Warner Losh" In-Reply-To: <20081017013946.3534221e.taku@tackymt.homeip.net> References: <48F75773.7030100@FreeBSD.org> <20081016.092844.-1548243521.imp@bsdimp.com> <20081017013946.3534221e.taku@tackymt.homeip.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mav@FreeBSD.org, freebsd-mobile@FreeBSD.org, stas@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-current@FreeBSD.org, zbeeble@gmail.com Subject: Re: RFC: PCI SD host controller driver & mmc/mmcsd modules improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2008 16:52:17 -0000 In message: <20081017013946.3534221e.taku@tackymt.homeip.net> Taku YAMAMOTO writes: : On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) : "M. Warner Losh" wrote: : : > In message: <48F75773.7030100@FreeBSD.org> : > Alexander Motin writes: : > : No, it's opposite. With lower frequency I have proportionally smaller : > : delays (more loop iterations). I don't remember exact numbers now, but : > : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - : > : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor : > : my eyes saw any visible delay there. : > : > You have more iterations. I'd have expected less. This doesn't say : > anything at all about DELAY, per se. If you are waiting for 1M cycles : > at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is : > implemented by reading a counter in the 8254 that's been calibrated. : > So unless the clock that's clocking it is running FASTER, delay won't : > be the source of additional iterations. : > : > Hmmm, looking at the i386 delay code, it looks like it depends on : > tsc_frequency being right when tsc isn't broken. If that's set : > bogusly, that could cause DELAY to be slower... : : I have a Core 2 Duo whose TSC ticks regardless of how EST is set. : In conjunction of tsc_freq_changed() function defined in tsc.c, : tsc_freq becomes lower than actual, thus shorter DELAY(). : : Maybe his machine has the same. That would cause the problem. If we're bogusly adjusting tsc_freq we should fix that... Warner