From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 26 18:43:37 2006 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4857C16A61B for ; Mon, 26 Jun 2006 18:43:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0B3B4483F for ; Mon, 26 Jun 2006 13:56:37 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id k5QDuZ0j083303; Mon, 26 Jun 2006 09:56:36 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-amd64@freebsd.org, Peter Seebach Date: Mon, 26 Jun 2006 09:40:48 -0400 User-Agent: KMail/1.9.1 References: <200606231908.k5NJ8DTB009354@guild.plethora.net> In-Reply-To: <200606231908.k5NJ8DTB009354@guild.plethora.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606260940.48404.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [192.168.0.1]); Mon, 26 Jun 2006 09:56:36 -0400 (EDT) X-Virus-Scanned: ClamAV 0.87.1/1563/Mon Jun 26 05:00:08 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx Cc: Subject: Re: SMP system not running SMP X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2006 18:43:37 -0000 On Friday 23 June 2006 15:08, Peter Seebach wrote: > In message <200606231315.56988.jhb@freebsd.org>, John Baldwin writes: > >Ok, when you boot in safe mode, you don't just disable ACPI, you also disable > >APIC which has the side effect of disabling SMP. Try breaking into the boot > >loader prompt at the menu and just doing: > > >'ok set hint.acpi.0.disabled=1' > >'ok boot' > > >and seeing if that gives you SMP. > > Is this at all similar to the "ACPI disabled" way of booting already provided? > > At least on my system, it has the same result; system hangs right after > acd0, during "waiting for SCSI devices to settle" or possibly immediately > after. Ok. That sounds like an interrupt routing issue. It could be that the interrupt routing info in the MP Table is incorrect. Let's stick with i386 for now (amd64 has the same code). Here's what I think is true so far: ACPI disabled, APIC enabled: - hangs at SCSI probe ACPI enabled, APIC enabled: - hangs? ACPI enabled, APIC disabled: - not tried (use just 'set hint.apic.0.disabled=1' in the loader) - would not have SMP ACPI disabled, APIC disabled (safe mode) - works as far as booting - no SMP (since no APIC) Can you capture verbose dmesg's from the 1) and 2) cases (and if you want, just try case 3) to make sure there isn't something else with ACPI that is broken). It would also be useful to include 'options DDB' in the kernel and to break into the debugger and run 'show intrcnt' when it hangs during the SCSI probe. This lets me know if one of the other interrupts is storming due to a misrouted interrupt. -- John Baldwin