MacBook users: possible fix for the SMP problem

[Rui Paulo]

On 5 Nov 2007, at 18:18, Scott Long wrote:

> Rui Paulo wrote:
>> On Nov 4, 2007 11:14 PM, Rink Springer <rink at freebsd.org> 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