From owner-cvs-all Sat Nov 23 12:43:42 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2429737B401; Sat, 23 Nov 2002 12:43:40 -0800 (PST) Received: from platon.gneto.com (as6-1-5.kr.m.bonet.se [217.215.84.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CF9E43E6E; Sat, 23 Nov 2002 12:43:28 -0800 (PST) (envelope-from martin@gneto.com) Received: from gneto.com (temp5.gneto.com [192.168.1.125]) by platon.gneto.com (Postfix) with ESMTP id 6E6034D22; Sat, 23 Nov 2002 21:43:16 +0100 (CET) Message-ID: <3DDFE954.9070405@gneto.com> Date: Sat, 23 Nov 2002 21:47:16 +0100 From: Martin Nilsson Organization: Martins home control User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin Cc: Wilko Bulte , cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/sys/dev/acpica acpi_pcib_acpi.c References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG John Baldwin wrote: > No. All this fixes is people on -current who "lose" PCI busses when > using ACPI. -stable doesn't use the ACPI PCI code because the PCI code= > in -stable is very different from the PCI code in -current. This fixed the missing 64-bit/66MHz bus on my Supermicro P3TDE6, thanks. CURRENT feels more and more like a real operating system every time I=20 update it. /Martin >>>jhb 2002/11/22 10:11:13 PST >>> >>> Modified files: >>> sys/dev/acpica acpi_pcib_acpi.c=20 >>> Log: >>> According to the ACPI spec, the bus number of the child PCI bus of a= host >>> to PCI bridge can be read be evaluating the _BBN method of the host = to PCI >>> device. Unfortunately, there appear to be some lazy/ignorant/moroni= c/ >>> whatever BIOS writers that return 0 for _BBN for all host to PCI bri= dges in >>> the system. On a system with a single host to PCI bridge this is no= t a >>> problem as the child bus of that single bridge will be bus 0 anyway.= >>> However, on systems with multiple host to PCI bridges and l/i/m/w BI= OS >>> writers this is a major problem resulting in all but the first host = to >>> PCI bridge failing to attach. So, this adds a workaround. >>> =20 >>> If the _BBN of a host to PCI bridge is zero and pcib0 already exists= >>> and is not us, the we use _ADR to look up our PCI function and slot >>> (we currently assume we are on bus 0) and use that to call >>> host_pcib_get_busno() to try and extract our bus number from config >>> registers on the host to PCI bridge device. If that fails, then we = make >>> an evil assumption that ACPI's _SB_ namespace lays out the host to P= CI >>> bridges in ascending order and use our pcib unit number as our bus >>> number. >>> =20 >>> Approved by: re >>> =20 >>> Revision Changes Path >>> 1.26 +52 -7 src/sys/dev/acpica/acpi_pcib_acpi.c >> >>---end of quoted text--- >> >>--=20 >>| / o / /_ _ wilko@FreeBSD.org >>|/|/ / / /( (_) Bulte Arnhem, the Neth= erlands >=20 >=20 --=20 Martin Nilsson - Home: Work: UNIX & Webb programmer/architect Malm=F6, Sweden FreeBSD - The power to serve. http://www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message