NEW_PCIB? pcib1: failed to allocate initial I/O port window:
0x4000-0x4fff
John Baldwin
jhb at freebsd.org
Tue Jun 14 17:27:13 UTC 2011
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)
@@ -151,6 +151,7 @@
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);
@@ -1855,6 +1856,13 @@
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:
@@ -2043,6 +2051,30 @@
}
/*
+ * 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)
@@ -209,38 +209,24 @@
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
More information about the freebsd-current
mailing list