From owner-freebsd-current@FreeBSD.ORG Mon Nov 5 23:38:12 2007 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 2D2A616A419; Mon, 5 Nov 2007 23:38:12 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id BC7F913C48D; Mon, 5 Nov 2007 23:38:11 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.0.3] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id lA5NGgMP013568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 15:16:44 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <472FA3B1.1070902@FreeBSD.org> Date: Mon, 05 Nov 2007 15:13:53 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Rui Paulo References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, freebsd-i386@FreeBSD.org Subject: Re: MacBook users: possible fix for the SMP problem 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: Mon, 05 Nov 2007 23:38:12 -0000 I've just tested it on my 1st gen MacBook Pro. Yes, indeed, it solves both problems - one with CPU frequency detection and another one with the AP startup. Thanks! -Maxim Rui Paulo wrote: > Hi, > I've been contacted by Marco Trillo and I think he has found the > source of the SMP problem. > The problem seems to rely on Intel ICH7. Basically we need to disable > the "LEGACY_USB" bit before we calibrate the clocks. > "LEGACY_USB", according to Marco (I don't have the ICH7 spec at hand), > "causes legacy USB circuit to generate SMIs". > > Please try the following patch: > --- sys/amd64/isa/clock.c.orig 2007-11-04 20:31:09.000000000 +0000 > +++ sys/amd64/isa/clock.c 2007-11-04 20:34:59.000000000 +0000 > @@ -577,6 +577,8 @@ startrtclock() > writertc(RTC_STATUSA, rtc_statusa); > writertc(RTC_STATUSB, RTCSB_24HR); > > + outl(0x430, inl(0x430) & ~0x8); > + > freq = calibrate_clocks(); > #ifdef CLK_CALIBRATION_LOOP > if (bootverbose) { > --- sys/i386/isa/clock.c.orig 2007-11-04 20:34:03.000000000 +0000 > +++ sys/i386/isa/clock.c 2007-11-04 20:34:30.000000000 +0000 > @@ -621,6 +621,8 @@ startrtclock() > writertc(RTC_STATUSA, rtc_statusa); > writertc(RTC_STATUSB, RTCSB_24HR); > > + outl(0x430, inl(0x430) & ~0x8); > + > freq = calibrate_clocks(); > #ifdef CLK_CALIBRATION_LOOP > if (bootverbose) { > > > This should probably fix two issues: > 1) The second core should start without any trick (e.g. key press) > 2) We should be able to run with HZ=1000 (the default) without any > problem. To check if this is indeed the case, try booting with HZ=1000 > (loader.conf variable kern.hz) and check if your CPU clock shows up > correctly in the dmesg. After that, please also check if 'time sleep > 1' takes one second (not more and not less). > > Also, please test if there are any USB problems. > > 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. > > Regards. >