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

John jwd at slowblink.com
Sat Jun 11 03:47:26 UTC 2011


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

Thanks!

> 
> Index: nexus.c
> ===================================================================
> --- nexus.c	(revision 222932)
> +++ nexus.c	(working copy)
> @@ -388,6 +388,27 @@ nexus_alloc_resource(device_t bus, device_t child,
>  	if (rm == NULL)
>  		return (NULL);
>  
> +	/* XXX: Hack */
> +	if (type == SYS_RES_IOPORT && start >= 0x4000 && start <= 0x4ffff) {
> +		char *buf;
> +
> +		device_printf(bus, "allocating range %#lx-%#lx for child",
> +		    start, end);
> +		if (device_get_nameunit(child) != NULL)
> +			printf(" %s", device_get_nameunit(child));
> +		printf(" of %s\n", device_get_nameunit(
> +		    device_get_parent(child)));
> +		buf = malloc(1024, M_DEVBUF, M_WAITOK);
> +		*buf = '\0';
> +		bus_child_pnpinfo_str(dev, buf, 1024);
> +		if (*buf != '\0')
> +			printf("\t%s\n", buf);
> +		*buf = '\0';
> +		bus_child_location_str(dev, buf, 1024);
> +		if (*buf != '\0')
> +			printf("\tat %s\n", buf);
> +		free(buf, M_DEVBUF);
> +	}
>  	rv = rman_reserve_resource(rm, start, end, count, flags, child);
>  	if (rv == 0)
>  		return 0;
> 
> 
> -- 
> John Baldwin


More information about the freebsd-current mailing list