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

----- 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)
> _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