From owner-freebsd-smp@FreeBSD.ORG Fri May 11 00:20:47 2007 Return-Path: X-Original-To: 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 35FB916A405 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 A016813C457 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 8AA8A68FEBB for ; Fri, 11 May 2007 00:47:46 +0100 (WEST) Received: by core.fnop.net (Postfix, from userid 1015) id 31A51690924; Fri, 11 May 2007 00:47:46 +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 8AC8F68FEBB for ; Fri, 11 May 2007 00:47:45 +0100 (WEST) Date: Fri, 11 May 2007 00:47:44 +0100 Message-ID: <86y7jw5jhb.wl%rpaulo@fnop.net> From: Rui Paulo To: 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 Cc: 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 ?