On 16-Oct-2002 John Baldwin wrote: > > On 16-Oct-2002 Mitsuru IWASAKI wrote: >>> > > If still NG, please try the attached patch against SupermicroP3TDE6.asl. >>> > > # _BBN is bridge bus number, my guess is 0x3. You can try to change it >>> > > # if failed. >>> > >>> > Maybe 0x2 is correct. >>> >>> I tried 2, and it seems to work correctly now. >>> >>> Thanks! >> >> Congratulations! >> >># Now we can start discussing ACPI PCI vs. legacy PCI :) >> DSDT in ACPI BIOS on Supermicro P3TDE6 has obviously wrong _BBN value, >> but previous kernel can fall back to legacy PCI bridge probing even if >> PCI bridge probing by ACPI is failed. >> >> From: "Kenneth D. Merry" <[EMAIL PROTECTED]> >> Subject: PCI problems with today's current >> Date: Thu, 3 Oct 2002 17:57:06 -0600 >> Message-ID: <[EMAIL PROTECTED]> >> >>> acpi_pcib1: <Host-PCI bridge> on acpi0 >>> acpi_pcib1: we have duplicate bus number 0 - not probing bus >> [snip] >>> pcib2: <ServerWorks host to PCI bridge> at pcibus 2 on motherboard >>> IOAPIC #1 intpin 8 -> irq 16 >>> pci2: <PCI bus> on pcib2 >>> ti0: <Netgear GA620 1000baseT Gigabit Ethernet> mem 0xfebfc000-0xfebfffff irq 16 >at device 2.0 >>> on pci2 >> >> I think that previous probing system is much more robust and safer >> in many cases, especially buggy ACPI BIOS. >> John, can we have previous PCI probing system again? > > I would rather fix ACPI to handle the bogus _BBN case by using _ADR to > read the bus number from config space. Otherwise, we won't end up with > _PRT's for non-zero host-PCI bridges, meaning that we may end up trying > to mix and match $PIR and _PRT interrupt routing for the UP case, or > trying to mix and match mptable and _PRT routing for the SMP case. We > should either let ACPI enumerate all host-PCI bridges or none.
Ugh, unlike PCI-PCI bridges, there is no standard way of reading the bus number from a host-PCI bridge. Yay. This is why _BBN exists in the first place. How helpful of BIOS writers to ignore it and/or completely misimpliment it. I have a patch that might work but it has the downside of a small bit of duplicated code. You can get it at http://www.FreeBSD.org/~jhb/patches/acpi_pci.patch. On another slightly related note: I don't think we need the pci_cfgregopen() call in the acpi_pcib_pci driver. The reason is that that function only needs to be called once, and for us to even get to the probe routine of an ACPI PCI-PCI bridge we must have succesfully probed and attached an ACPI Host-PCI bridge. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
