Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Nov 2002 21:47:16 +0100
From:      Martin Nilsson <martin@gneto.com>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Wilko Bulte <wkb@freebie.xs4all.nl>, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/dev/acpica acpi_pcib_acpi.c
Message-ID:  <3DDFE954.9070405@gneto.com>
References:  <XFMail.20021122160804.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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:<martin@gneto.com> Work:<martin@svenskabutiker.se>
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDFE954.9070405>