From owner-freebsd-smp@FreeBSD.ORG Fri May 11 00:20:47 2007 Return-Path: X-Original-To: freebsd-smp@freebsd.org Delivered-To: freebsd-smp@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3548816A404 for ; Fri, 11 May 2007 00:20:47 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by mx1.freebsd.org (Postfix) with ESMTP id 9442813C44C for ; Fri, 11 May 2007 00:20:46 +0000 (UTC) (envelope-from rpaulo@fnop.net) Received: from core.fnop.net (mx.fnop.net [82.102.11.82]) by core.fnop.net (Postfix) with ESMTP id E130069092E for ; Fri, 11 May 2007 01:03:57 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 9DAE869097F; Fri, 11 May 2007 01:03:57 +0100 (WEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on core.fnop.net X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,RCVD_IN_SORBS_DUL autolearn=no version=3.1.7 Received: from epsilon.local.fnop.net (87-196-119-163.net.novis.pt [87.196.119.163]) by core.fnop.net (Postfix) with ESMTP id 2837969092E for ; Fri, 11 May 2007 01:03:57 +0100 (WEST) Date: Fri, 11 May 2007 01:03:58 +0100 Message-ID: <86sla45iq9.wl%rpaulo@fnop.net> From: Rui Paulo To: freebsd-smp@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: ClamAV using ClamSMTP Subject: Fixing SMP on MacBooks X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 00:20:47 -0000 Hi, I would like to bring this discussion to a wider audicence. So, here's the problem: As some of you already know, the second core on Apple's MacBooks fails to start. There are two nasty tricks to make it start (both involve interactivity from the user) that I know of. They are: 1) Press the power button during the IPI timeout; 2) Press a key [1] before the IPIs are sent *OR* during the IPI timeout. [1] This is really an interrupt. Pressing the Fn key doesn't work because the Fn key doesn't generate an interrupt. There tricks don't work on the MacBook Pro. While the source of the problem might be the same, it's not clear why the tricks work. Some ideas (came up during discussion with Scott Long) 1) Update EFI -- I have the latest updates from Apple and the AP doesn't start. 2) The trampoline isn't being set correctly -- if that was the case, the tricks wouldn't really work 3) Check what kind of interrupt is generated by the USB controller 4) The LAPIC is not being set correctly -- I've been reading the Linux code on this matter and I don't see any relevant difference 5) The boot loader is doing something legacy only [2] [2] This was true for cdboot, at least. Either way, an interrupt is (it seems): 1) triggering a (re)configuration of something; or 2) enabling another interrupt(s) Anyone has any other ideas on how to better debug this ? Thanks in advance.