From owner-freebsd-hardware@FreeBSD.ORG Mon Nov 5 19:26:05 2007 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54D9616A469 for ; Mon, 5 Nov 2007 19:26:05 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.186]) by mx1.freebsd.org (Postfix) with ESMTP id B46A113C4B7 for ; Mon, 5 Nov 2007 19:26:04 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by mu-out-0910.google.com with SMTP id i10so1950728mue for ; Mon, 05 Nov 2007 11:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; bh=9NG9iplxgrl1+uC8iZYnW69jHGkLc/lMEtQarxTwxvk=; b=IlNusnbw+1t+n7ESQQ/yMlviDp3pawNShYYvZyb/MN2qjiTV/XBJ58Ohkw1cwin28vvUfR3GatXaRblhoKgi7lWhyd7UvupSDm62AjR1vcdhj4cX93/qkN1z8Fo9qDoAxptiIhZU10hOkP635OoYgV+Q+ts6+3eFe9guQZbmSgk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:cc:message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer:sender; b=G23Sd8eaasrZHoClmVSmbBA6VlDhRyXGo/ceD4+P/jJId5n4hWFTke1JGe92NDNeawTphQwxgcE6TlGlTGkUfnBqIIT/DPkxN6t6+pGGqh+VQwuoa2C+QKYt9iXTZEe9aijndNRyuWqExwfBmKyhj75sqmW2hfLXxgscnJ9bdzc= Received: by 10.86.74.15 with SMTP id w15mr3658424fga.1194290753057; Mon, 05 Nov 2007 11:25:53 -0800 (PST) Received: from ?172.17.14.191? ( [193.136.24.218]) by mx.google.com with ESMTPS id 28sm12858940fkx.2007.11.05.11.25.50 (version=SSLv3 cipher=OTHER); Mon, 05 Nov 2007 11:25:51 -0800 (PST) Message-Id: <60C64C73-A019-4C01-85E1-80DF4C76B1AF@freebsd.org> From: Rui Paulo To: Scott Long In-Reply-To: <472F5E62.4080406@samsco.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Mon, 5 Nov 2007 19:25:48 +0000 References: <4A5A9C78-22AC-4480-BDEB-A72F6CF472DB@fnop.net> <20071104231422.GA82337@rink.nu> <472F5E62.4080406@samsco.org> X-Mailer: Apple Mail (2.912) Sender: Rui Paulo Cc: Rink Springer , freebsd-current@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: MacBook users: possible fix for the SMP problem X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 19:26:05 -0000 On 5 Nov 2007, at 18:18, Scott Long wrote: > Rui Paulo wrote: >> On Nov 4, 2007 11:14 PM, Rink Springer wrote: >>> Hi Rui, >>> >>> On Sun, Nov 04, 2007 at 08:59:28PM +0000, Rui Paulo wrote: >>>> Note: this is still a hack. I'm still thinking about a way to >>>> correctly identify on which systems we need to apply this fix. >>> This indeed looks hackikly - I don't know whether it's possible to >>> distinguish between a 'normal' PC or a MacBook - but if this is not >>> possible, maybe a kernel option is in order? >> It's possible to distinguish between a MacBook and a PeeCee via >> smbios >> vendor strings. >> But what I actually wanted was something more general. >> Regards. > > Turning this on universally should only affect USB keyboard > operation in > KDB early in boot (or if the USB drivers were omitted during boot). Hmm. I was never able to interact with DDB early on boot. Only after USB gets probed. > It sounds like this affects clock calibration on other systems, not > just > Macs. So I'd vote for this being made into a negative option, i.e. > > options ENABLE_ICH_USB_LEGACY > > That'll at least let people boot with a GENERIC kernel and then decide > for themselves if they want it enabled or disabled. It could also be > made into tunable and set via the loader menu, but I'd only advocate > that if there were found to be other side effects that prevented some > users from booting with GENERIC. I think a loader variable is the best way to go. As I really don't know how if this will affect negatively other systems I was planning to produce a patch that does something like: usb_legacy = getenv("hw.ich.usb_legacy"); if (!usb_legacy) usb_legacy = 0; usb_legacy_activated = read_bit_from_SMI_EN; // SMI Control and Enable Register if (usb_legacy_activated && usb_legacy == "0") { disable SMI interrupt with USB; } What do you think? > Anyways, good job figuring this out. Talk about an obscure problem. > Now I don't feel so bad about spending days in vain going line-by-line > through the AP startup code looking for the problem. Well, don't thank me. As I said in the first email, someone else working on NetBSD found this issue, not me. Regards. -- Rui Paulo