Re: (Re)assignment of PCI BARs

From: Jesse Barnes
Date: Thu Aug 27 2009 - 19:19:49 EST


On Thu, 27 Aug 2009 19:49:32 +0800
Beng Tan <bengtan1@xxxxxxxxx> wrote:
> The symptom I'm seeing is that the card has BAR 0 unassigned ...
>
> Region 0: Memory at <unassigned> (64-bit, prefetchable) [disabled]
>
> and indeed, the kernel reports this through dmesg ...
>
> [ 6.147093] PCI: Failed to allocate mem resource
> #0:10000000@e0000000 for 0000:0d:00.0
>
> Full logs are available at:
>
> http://208.100.55.9/coldboot_20090827/dmesg.txt
> http://208.100.55.9/coldboot_20090827/iomem.txt
> http://208.100.55.9/coldboot_20090827/lspci_vv.txt
>
> Doesn't the kernel reassign PCI resources if the BIOS doesnt do a good
> enough job? Or is that not the case in my old kernel (2.6.24)?

A newer kernel could help, there have been some resource related fixes
since 2.6.24.

> Is it possible to force a reassignment of the impacted BAR? For
> example, I wrote a small module which wrote to the device's PCI
> configuration registers to explcitly reassign BAR 0 to 0xc00000000
> (and also bit bashed the connecting bridge to do the same) but ... I'm
> not sure if I'm doing it correctly.

There are some PCI calls you can use to assign space, e.g.
pci_bus_alloc_resource, but really the kernel should try to get this
right. In your case, it looks like the BIOS isn't giving the bus with
your card a large enough window (256M BAR on your card vs. a 2M windows
on the bus).

--
Jesse Barnes, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/