From owner-freebsd-stable@FreeBSD.ORG Fri Jun 9 21:50:33 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B044C16A473 for ; Fri, 9 Jun 2006 21:50:33 +0000 (UTC) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 164B443D97 for ; Fri, 9 Jun 2006 21:50:28 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id A908C72DA1; Fri, 9 Jun 2006 14:48:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id A2A5E72D9F; Fri, 9 Jun 2006 14:48:57 -0700 (PDT) Date: Fri, 9 Jun 2006 14:48:57 -0700 (PDT) From: Doug White To: Pete French In-Reply-To: Message-ID: <20060609143941.I60598@carver.gumbysoft.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: Dual Opteron system will not run SMP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 21:50:33 -0000 On Wed, 7 Jun 2006, Pete French wrote: >> If just non-ACPI isnt sufficient, the other thing SAFE does is turn >> off disk DMA. I have an as-yet unreleased system that has this >> same type of issue, and the problem is that two PCI device ID's >> are not recognized, so maybe that will be your problem. > > So, I got around to booting the system without ACPI and there are quite > a number of 'unknown' reports at boot, viz: > > unknown: can't assign resources (memory) > unknown: can't assign resources (port) > unknown: can't assign resources (irq) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) > unknown: can't assign resources (port) These are normal motherboard resources that FreeBSD reserves via other methods. They can be safely ignored. > pciconf -l gives me 5 devices without drivers attached, these being: > > none0@pci0:7:2: class=0x0c0500 card=0x13101462 chip=0x746a1022 rev=0x02 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'AMD-8111 SMBus 2.0 Controller' > class = serial bus > subclass = SMBus You need to load a device driver to attach to this function; I believe its called amdpm. It is only needed if you want to inquiry devices on SMBus. > none1@pci0:7:3: class=0x068000 card=0x13101462 chip=0x746b1022 rev=0x05 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'AMD-8111 ACPI System Management Controller' > class = bridge > none2@pci0:10:1: class=0x080010 card=0x13101462 chip=0x74511022 rev=0x01 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'AMD-8131 PCI-X IOAPIC' > class = base peripheral > subclass = interrupt controller > none3@pci0:11:1: class=0x080010 card=0x13101462 chip=0x74511022 rev=0x01 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'AMD-8131 PCI-X IOAPIC' > class = base peripheral > subclass = interrupt controller FreeBSD detects and attaches these through ACPI and not through the PCI bus. In the non-ACPI case (which BTW is not exactly kosher for amd64, since ACPI is a required part of the platform spec), IOAPICs are enumerated and attached through MPTable. The fact that the IOAPICs have PCI bus attachments at all is an implementation detail. They didn't back in the Pentium Pro days. > none4@pci3:6:0: class=0x030000 card=0x13101462 chip=0x47521002 rev=0x27 hdr=0x00 > vendor = 'ATI Technologies Inc' > device = 'Rage XL PCI' > class = display > subclass = VGA This usually gets grabbed either by the agp driver or by the DRM (Direct Rendering Module) appropriate for the chip. The console uses generic VGA register accesses and doesn't need the PCI attachment to figure that out. If you don't run X then this is normal. My recommendation for problems with amd64 boards: 1. Upgrade to the latest release BIOS from the vendor. This is really, really, really important; the latest BIOS often has revised memory and bus timings that improve compatibility. The Tyan S2892 in particular needs it to avoid lockups if any PCI cards are installed. 2. Lockups at the SCSI detection phase are usually due to interrupt routing issues (an interrupt gets stuck on and won't clear since we can't figure out who's triggering it). If you have PCI cards installed try moving them to different slots or removing them entirely. Also disconnect any USB peripherals you may have connected. 3. You could have a defective IOAPIC, or other device, on your system board. Very rare, but possible. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org