Re: NEW_PCIB? pcib1: failed to allocate initial I/O port window: 0x4000-0x4fff

On Saturday, June 11, 2011 1:05:18 am John wrote:
> ----- John's Original Message -----
> > ----- John Baldwin's Original Message -----
> > > On Friday, June 10, 2011 11:00:15 am John wrote:
> > > > ----- John Baldwin's Original Message -----
> > > > > On Thursday, June 09, 2011 2:11:16 am Andriy Gapon wrote:
> > > > > > on 09/06/2011 01:30 John said the following:
> > > > > > > Sorry John, here's the verbose dmesg output with your patch applied.
> > > > > > > 
> > > > > > > This is at the tail of the console:
> > > > > > > 
> > > > > > > pcib1: allocated memory range (0xf6000000-0xf6ffffff) for rid 10 of pci0:1:3:0
> > > > > > >         map[14]: type I/O Port, range 32, base 0x4400, size  8, enabled
> > > > > > > pcib1: failed to allocate initial I/O port window (0x4000-0x4fff,0x1000)
> > > > > > >         map[18]: type Memory, range 32, base 0xf5ff0000, size 12, enabled
> > > > > > > 
> > > > > > > 
> > > > > > > Output ends with a single 'M', not MCA as earlier.
> > > > > > 
> > > > > > 
> > > > > > Just a wild guess - what happens if you revert r222537 (you might need to revert
> > > > > > r222804 first)?
> > > > > 
> > > > > I think he's getting a MCA due to writing to a bad address and getting a
> > > > > PCI-e target abort equivalent and that the screen output is broken
> > > > > because the VGA device is what is probably getting hosed by the pcib driver.
> > > > > 
> > > > > Given that, I doubt the printf changes are related.
> > > > 
> > > > Just for grins, I decided to completely remove usb from the kernel
> > > > to see if it might help. Nolonger prints the MCA and/or M, just
> > > > hangs while printing out the no driver attached messages. Still
> > > > prints out the failed to allocate messages... 
> > > 
> > > Hmmm.  Your case is a bit different.  PCI-PCI bridges have to allocate I/O
> > > space on 4KB boundarys, so the smallest chunk it can allocate for the
> > > resources behind your bridge is 0x4000-0x4fff which is what keeps failing.
> > > 
> > > Hmm, it's claiming that brgphy1 has some I/O ports that conflict allocated.
> > > That makes no sense.  brgphy devices have no I/O port resources.  I think
> > > the device_t got reused.
> > > 
> > > Can you try this perhaps to get started relative to sys/x86/x86/nexus.c:
> > 
> > In the following line, did by chance you want 'child' instead of dev?
> > 
> > bus_child_pnpinfo_str(dev, buf, 1024);
> > 
> > /usr/src.2011-06-10_22.00_EST/sys/x86/x86/nexus.c: In function 'nexus_alloc_resource':
> > /usr/src.2011-06-10_22.00_EST/sys/x86/x86/nexus.c:403: error: 'dev' undeclared (first use in this function)
> > /usr/src.2011-06-10_22.00_EST/sys/x86/x86/nexus.c:403: error: (Each undeclared identifier is reported only once
> > /usr/src.2011-06-10_22.00_EST/sys/x86/x86/nexus.c:403: error: for each function it appears in.)
> > 
> 
>    boot -v output below. Two areas which appear to have the
> overlapping and dealt with from your patch:
> 
> acpi0: Power Button (fixed)
> nexus0: allocating range 0x4800-0x48fe for child of acpi0
>         _HID=none _UID=0
>         at handle=\_SB_.CFG0.PCI0.GROM
> nexus0: allocating range 0x4900-0x4907 for child of acpi0
>         _HID=none _UID=0
>         at handle=\_SB_.CFG0.PCI0.GROM

Hmm, this devices is a "base peripheral" PCI device.  It really has no
business allocating resources this way.  I think we can ignore these
resources for now.  Can you try this patch:

Index: acpi.c
===================================================================
--- acpi.c	(revision 223082)
+++ acpi.c	(working copy)
_at__at_ -151,6 +151,7 _at__at_
 static ACPI_STATUS acpi_EnterSleepState(struct acpi_softc *sc, int state);
 static void	acpi_shutdown_final(void *arg, int howto);
 static void	acpi_enable_fixed_events(struct acpi_softc *sc);
+static BOOLEAN	acpi_has_hid(ACPI_HANDLE handle);
 static int	acpi_wake_sleep_prep(ACPI_HANDLE handle, int sstate);
 static int	acpi_wake_run_prep(ACPI_HANDLE handle, int sstate);
 static int	acpi_wake_prep_walk(int sstate);
_at__at_ -1855,6 +1856,13 _at__at_
 		break;
 	    if (acpi_parse_prw(handle, &prw) == 0)
 		AcpiSetupGpeForWake(handle, prw.gpe_handle, prw.gpe_bit);
+
+	    /*
+	     * Ignore devices that do not have a _HID or _CID.  They should
+	     * be discovered by other buses (e.g. the PCI bus driver).
+	     */
+	    if (!acpi_has_hid(handle))
+		break;
 	    /* FALLTHROUGH */
 	case ACPI_TYPE_PROCESSOR:
 	case ACPI_TYPE_THERMAL:
_at__at_ -2043,6 +2051,30 _at__at_
 }
 
 /*
+ * Returns true if a device has at least one valid device ID.
+ */
+static BOOLEAN
+acpi_has_hid(ACPI_HANDLE h)
+{
+    ACPI_DEVICE_INFO	*devinfo;
+    BOOLEAN		ret;
+
+    if (h == NULL ||
+	ACPI_FAILURE(AcpiGetObjectInfo(h, &devinfo)))
+	return (FALSE);
+
+    ret = FALSE;
+    if ((devinfo->Valid & ACPI_VALID_HID) != 0)
+	ret = TRUE;
+    else if ((devinfo->Valid & ACPI_VALID_CID) != 0)
+	if (devinfo->CompatibleIdList.Count > 0)
+	    ret = TRUE;
+
+    AcpiOsFree(devinfo);
+    return (ret);
+}
+
+/*
  * Match a HID string against a handle
  */
 BOOLEAN
Index: acpi_pci.c
===================================================================
--- acpi_pci.c	(revision 223082)
+++ acpi_pci.c	(working copy)
_at__at_ -209,38 +209,24 _at__at_
 	device_t child;
 
 	/*
-	 * Lookup and remove the unused device that acpi0 creates when it walks
-	 * the namespace creating devices.
+	 * Occasionally a PCI device may show up as an ACPI device
+	 * with a _HID.  (For example, the TabletPC TC1000 has a
+	 * second PCI-ISA bridge that has a _HID for an
+	 * acpi_sysresource device.)  In that case, leave ACPI-CA's
+	 * device data pointing at the ACPI-enumerated device.
 	 */
 	child = acpi_get_device(handle);
 	if (child != NULL) {
-		if (device_is_alive(child)) {
-			/*
-			 * The TabletPC TC1000 has a second PCI-ISA bridge
-			 * that has a _HID for an acpi_sysresource device.
-			 * In that case, leave ACPI-CA's device data pointing
-			 * at the ACPI-enumerated device.
-			 */
-			device_printf(child,
-			    "Conflicts with PCI device %d:%d:%d\n",
-			    pci_get_bus(pci_child), pci_get_slot(pci_child),
-			    pci_get_function(pci_child));
-			return;
-		}
 		KASSERT(device_get_parent(child) ==
 		    devclass_get_device(devclass_find("acpi"), 0),
 		    ("%s: child (%s)'s parent is not acpi0", __func__,
 		    acpi_name(handle)));
-		device_delete_child(device_get_parent(child), child);
+		return;
 	}
 
 	/*
 	 * Update ACPI-CA to use the PCI enumerated device_t for this handle.
 	 */
-	status = AcpiDetachData(handle, acpi_fake_objhandler);
-	if (ACPI_FAILURE(status))
-		printf("WARNING: Unable to detach object data from %s - %s\n",
-		    acpi_name(handle), AcpiFormatException(status));
 	status = AcpiAttachData(handle, acpi_fake_objhandler, pci_child);
 	if (ACPI_FAILURE(status))
 		printf("WARNING: Unable to attach object data to %s - %s\n",

-- 
John Baldwin