On Mon, May 6, 2013 at 4:31 AM, Gavin Shan <shangw@xxxxxxxxxxxxxxxxxx> wrote: > On Sun, May 05, 2013 at 08:04:48PM -0700, Yinghai Lu wrote: >>On Sun, May 5, 2013 at 7:08 PM, Gavin Shan <shangw@xxxxxxxxxxxxxxxxxx> wrote: >>> On Sun, May 05, 2013 at 05:52:16PM +1000, Benjamin Herrenschmidt wrote: >>>>On Sun, 2013-05-05 at 00:09 -0700, Yinghai Lu wrote: > > Hi Ben/Yinghai, > > Here's what happened for the failure to allocate memory window of P2P > bridge 0001:01:00.0. > > 1. Sizing P2P bridge window. > 2. Allocated resources in sorted order for specific PCI bus. Unfortunately, > it should fail since the PCI bus doesn't IO (not MMIO) resource. So in > function __assign_resources_sorted(), those resources that have been allocated > would be released, then allocate the so-called "must-have" resources and > eventually allocate the additional size for the corresponding resource. However, > we have some conflict in the last step (the additional size). Let have one > example here. > > [0 24MB] Memory window of bus 0001:01 "ROOT" > [0 8MB] Meory window#0 of 0001:01:00.0 "WIN#0" with additional size 8MB > [0 8MB] Memory window#1 of 0001:01:00.0 "WIN#1" with additional size 0 > > If the last step (mentioned as above) fails, the resource would be allocated > in following sequence: > > WIN#0 -> WIN#1 -> WIN#0 with additional size 8MB > [0 8MB] [8MB 16MB] No available space for this one (16MB) > > The possible (temporary) fix would be checking "local_fail_head" in function > __assign_resources_sorted() and don't do reassignment if all the element in > the list is IO related. In the future, we might introduce specific flag to > indicate the PCI host can't support IO and skip all IO assignment accordingly. What exactly is the problem here? Is it just that you don't want to see the "can't assign" messages? Or is there a device with a BAR that *should* be assigned, but isn't? If so, which device is it? Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
