Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Jul 2011 17:04:18 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        freebsd-stable@FreeBSD.org
Cc:        Attilio Rao <attilio@freebsd.org>, Callum Gibson <callumgibson@optusnet.com.au>, freebsd-amd64@freebsd.org, Jeremy Chadwick <freebsd@jdc.parodius.com>, John Baldwin <jhb@freebsd.org>
Subject:   Re: powernow regression in 8-STABLE
Message-ID:  <201107251704.20389.jkim@FreeBSD.org>
In-Reply-To: <20110723084721.GA7931@icarus.home.lan>
References:  <20110719112033.GA51765@omma.gibson.athome> <20110723081304.GA14172@omma.gibson.athome> <20110723084721.GA7931@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201107251704.20389.jkim>