Failure to get past a PCI bridge

[John Baldwin]

On Friday 05 June 2009 5:17:25 am Josef Moellers wrote:
> Difficult, since I can't boot properly.
> However, I have managed to get the dsdt using a SuSE Linux and have run 
> that through acpidump -d on a 7.2 running on a XEN virtual machine. 
> Here's the result.

Hmm, your BIOS is certainly hosed.  First, it does have separate processor
objects:

    Scope (\_PR)
    {
        Processor (PR00, 0x00, 0x00000000, 0x00) {}
        Processor (PR01, 0x08, 0x00000000, 0x00) {}
        Processor (PR02, 0x01, 0x00000000, 0x00) {}
        Processor (PR03, 0x09, 0x00000000, 0x00) {}
        Processor (PR04, 0x02, 0x00000000, 0x00) {}
        Processor (PR05, 0x0A, 0x00000000, 0x00) {}
        Processor (PR06, 0x03, 0x00000000, 0x00) {}
        Processor (PR07, 0x0B, 0x00000000, 0x00) {}
        Processor (PR10, 0x04, 0x00000000, 0x00) {}
        Processor (PR11, 0x0C, 0x00000000, 0x00) {}
        Processor (PR12, 0x05, 0x00000000, 0x00) {}
        Processor (PR13, 0x0D, 0x00000000, 0x00) {}
        Processor (PR14, 0x06, 0x00000000, 0x00) {}
        Processor (PR15, 0x0E, 0x00000000, 0x00) {}
        Processor (PR16, 0x07, 0x00000000, 0x00) {}
        Processor (PR17, 0x0F, 0x00000000, 0x00) {}
    }

However, \_SB_.CPU0 and \_SB_.CPU1 are listed as Host-PCI bridge devices, not
CPUs (CPUs are enumerated in ACPI as Processor() objects, not Device()'s, and
certainly not with the _HID == Host-PCI bridge):

        Device (CPU0)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_UID, 0x01)
	    Name (_BBN, 0xFF)

...

        Device (CPU1)
        {
            Name (_HID, EisaId ("PNP0A03"))
            Name (_UID, 0x02)
            Name (_BBN, 0xFE)

...

        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A08"))
            Name (_CID, 0x030AD041)
            Name (_UID, 0x00)
            Name (_BBN, 0x00)
            Method (_INI, 0, NotSerialized)
            {
                \OSCK ()
            }

Hmm, it does have a valid _BBN value for your actual PCI bus.  Not sure why
it is using a bus number of 2.  Ahh, ok.  Hmm, so some machines with multipe
busses would set _BBN to 0 for all busses, so we don't trust a _BBN of 0 for
non-pcib0.  However, I think what we want to do is not trust a _BBN of 0 if
we already have a PCI bus 0 (in your case, pcib0 has PCI bus 255, pcib1 has
PCI bus 254, and pcib2 has PCI bus 0).  Try this:

--- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib_acpi.c	2009/02/05 18:45:20
+++ //depot/user/jhb/acpipci/dev/acpica/acpi_pcib_acpi.c	2009/06/05 14:28:27
@@ -146,6 +146,7 @@
 {
     struct acpi_hpcib_softc	*sc;
     ACPI_STATUS			status;
+    static int bus0_seen = 0;
     u_int addr, slot, func, busok;
     uint8_t busno;
 
@@ -156,6 +157,21 @@
     sc->ap_handle = acpi_get_handle(dev);
 
     /*
+     * Get our segment number by evaluating _SEG
+     * It's OK for this to not exist.
+     */
+    status = acpi_GetInteger(sc->ap_handle, "_SEG", &sc->ap_segment);
+    if (ACPI_FAILURE(status)) {
+	if (status != AE_NOT_FOUND) {
+	    device_printf(dev, "could not evaluate _SEG - %s\n",
+		AcpiFormatException(status));
+	    return_VALUE (ENXIO);
+	}
+	/* If it's not found, assume 0. */
+	sc->ap_segment = 0;
+    }
+
+    /*
      * Get our base bus number by evaluating _BBN.
      * If this doesn't work, we assume we're bus number 0.
      *
@@ -169,8 +185,10 @@
      * XXX invoke _REG on this for the PCI config space address space?
      * XXX It seems many BIOS's with multiple Host-PCI bridges do not set
      *     _BBN correctly.  They set _BBN to zero for all bridges.  Thus,
-     *     if _BBN is zero and pcib0 already exists, we try to read our
+     *     if _BBN is zero and PCI bus 0 already exists, we try to read our
      *     bus number from the configuration registers at address _ADR.
+     *     We only do this for domain/segment 0 in the hopes that this is
+     *     only needed for old single-domain machines.
      */
     status = acpi_GetInteger(sc->ap_handle, "_BBN", &sc->ap_bus);
     if (ACPI_FAILURE(status)) {
@@ -185,11 +203,11 @@
     }
 
     /*
-     * If the bus is zero and pcib0 already exists, read the bus number
-     * via PCI config space.
+     * If this is segment 0, the bus is zero, and PCI bus 0 already
+     * exists, read the bus number via PCI config space.
      */
     busok = 1;
-    if (sc->ap_bus == 0 && devclass_get_device(pcib_devclass, 0) != dev) {
+    if (sc->ap_segment == 0 && sc->ap_bus == 0 && bus0_seen) {
 	busok = 0;
 	status = acpi_GetInteger(sc->ap_handle, "_ADR", &addr);
 	if (ACPI_FAILURE(status)) {
@@ -226,20 +244,9 @@
 	device_printf(dev, "trying bus number %d\n", sc->ap_bus);
     }
 
-    /*
-     * Get our segment number by evaluating _SEG
-     * It's OK for this to not exist.
-     */
-    status = acpi_GetInteger(sc->ap_handle, "_SEG", &sc->ap_segment);
-    if (ACPI_FAILURE(status)) {
-	if (status != AE_NOT_FOUND) {
-	    device_printf(dev, "could not evaluate _SEG - %s\n",
-		AcpiFormatException(status));
-	    return_VALUE (ENXIO);
-	}
-	/* If it's not found, assume 0. */
-	sc->ap_segment = 0;
-    }
+    /* If this is bus 0 on segment 0, note that it has been seen already. */
+    if (sc->ap_segment == 0 && sc->ap_bus == 0)
+	    bus0_seen = 1;
 
     return (acpi_pcib_attach(dev, &sc->ap_prt, sc->ap_bus));
 }


-- 
John Baldwin