----- John Baldwin's Original Message -----
> 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:
Hi John,
Success!
I've rebooted the system a number of times, built & installed
world and everything so far seems fine.
I don't know if you consider this a "correct" fix, but it seems
to do the job. Can you possibly leave the trace statements in for
the next poor soul that runs into the issue? (which I hope won't
be me :-)
Many Thanks!
-John
> 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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
