From owner-freebsd-stable@FreeBSD.ORG Mon Jul 25 21:04:33 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id BB13A106566C; Mon, 25 Jul 2011 21:04:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-stable@FreeBSD.org Date: Mon, 25 Jul 2011 17:04:18 -0400 User-Agent: KMail/1.6.2 References: <20110719112033.GA51765@omma.gibson.athome> <20110723081304.GA14172@omma.gibson.athome> <20110723084721.GA7931@icarus.home.lan> In-Reply-To: <20110723084721.GA7931@icarus.home.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201107251704.20389.jkim@FreeBSD.org> Cc: Attilio Rao , Callum Gibson , freebsd-amd64@freebsd.org, Jeremy Chadwick , John Baldwin Subject: Re: powernow regression in 8-STABLE 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: Mon, 25 Jul 2011 21:04:33 -0000 On Saturday 23 July 2011 04:47 am, Jeremy Chadwick wrote: > On Sat, Jul 23, 2011 at 06:13:04PM +1000, Callum Gibson wrote: > > On 22Jul11 08:16, John Baldwin wrote: > > }The problem is that we calibrate the TSC using this algorithm: > > } > > } - grab the TSC > > } - spin on the ISA timer waiting for it to run for a second > > } - grab the TSC > > } > > }The issue is that the SMI# fires at the same time we want to be > > execuiting }step 3, and step 3 is deferred while the SMI# handler > > runs. As a result, the }TSC delta ends up being "1 second + time > > of an SMI# to poll USB". We have a }hack fix for this at work > > that originally came from Attilio Rao. This is a }patch for it > > relative to 8. It disables interrupt generation for the ISA > > }timer while we calibrate the TSC (which disables the SMI# > > temporarily): > > > > Thanks, John. The hack works as intended, but I guess it's not a > > "real" solution which is why you haven't committed it? > > This sort of thing is going to have to get dealt with officially > sooner or later, hack-fix or elegant solution either way[1]. > > More and more systems are using native USB keyboards, and most > system BIOSes I've seen (from multiple vendors, specifically > Supermicro, Lenovo, Asus, Dell, HP, and Gigabyte[2]) are defaulting > to having these options enabled (and rightfully so). > > If the hack-fix has repercussions, it would be helpful to know what > those are or how those might manifest themselves. Otherwise, has > anyone taken a look at how Linux addresses this problem? To my > knowledge GRUB and similar bootstraps do not have a native USB > stack, so I'm left wondering how they deal with this. > > [1]: I'm in no way saying "Hey! Fix this! {contributes nothing}", > I'm simply pointing out that we're at a point where we really don't > have much of a choice. The more I read technical explanations from > John the more hate x86 architecture. ;-) > > [2]: On a couple Gigabyte boards I have the default values for said > option is enabled (for both keyboard and mouse). It is really annoying problem and it has to be fixed *properly*. Previously, we dealt with similar SMI# problem per platform, e.g., http://svnweb.freebsd.org/base?view=revision&revision=174557 This quirk table matches 6 platforms now: if (strncmp(sysenv, "MacBook1,1", 10) == 0 || strncmp(sysenv, "MacBook3,1", 10) == 0 || strncmp(sysenv, "MacBookPro1,1", 13) == 0 || strncmp(sysenv, "MacBookPro1,2", 13) == 0 || strncmp(sysenv, "MacBookPro3,1", 13) == 0 || strncmp(sysenv, "Macmini1,1", 10) == 0) { if (bootverbose) printf("Disabling LEGACY_USB_EN bit on " "Intel ICH.\n"); outl(ICH_SMI_EN, inl(ICH_SMI_EN) & ~0x8); } ... We definitely need to generalize it as soon as possible. Jung-uk Kim