Re: [GIT PULL] PCI fixes for v3.19

[Bjorn Helgaas]

On Mon, Jan 26, 2015 at 9:55 PM, Yinghai Lu <yinghai@xxxxxxxxxx> wrote:
> On Mon, Jan 26, 2015 at 3:53 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>> On Mon, Jan 26, 2015 at 01:24:51PM -0800, Tony Luck wrote:
>>> On Mon, Jan 26, 2015 at 1:02 PM, Bjorn Helgaas <bhelgaas@xxxxxxxxxx> wrote:
>>> > Sorry for the inconvenience.  Can you collect a complete dmesg log and
>>> > "lspci -vv" output, too (from the kernel with the reverted commit)?
>>> > That will have more useful information than just /proc/iomem.
>>>
>>> Full dmesg, lspci -vv, and bonus .config (CONFIG_PCI_IOV is indeed
>>> not set)
>>
>> The ROM part is something we should fix:
>>
>>   pci 0000:01:00.1: can't claim BAR 6 [mem 0xfffe0000-0xffffffff pref]: no compatible bridge window
>>
>> The ROM BAR is probably disabled, and we shouldn't complain about this if
>> it's disabled.  Yinghai?
>
> original ia64 code, has extra checking to hide the warning
>
> -static int is_valid_resource(struct pci_dev *dev, int idx)
>  {
> -       unsigned int i, type_mask = IORESOURCE_IO | IORESOURCE_MEM;
> -       struct resource *devr = &dev->resource[idx], *busr;
>
>         if (!dev->bus)
> -               return 0;
> -
> -       pci_bus_for_each_resource(dev->bus, busr, i) {
> -               if (!busr || ((busr->flags ^ devr->flags) & type_mask))
> -                       continue;
> -               if ((devr->start) && (devr->start >= busr->start) &&
> -                               (devr->end <= busr->end))
> -                       return 1;
> -       }
> -       return 0;
> -}
>
> also that is used to skip pci_claim_resource calling for invalid ...
>
> so the root resource is totally wrong from ACPI.

Yes, ACPI is clearly missing some information.

Just to make sure we're planning the same thing, I expect that we will
fix or workaround both issues so it works just as well as v3.18 by the
time v3.19 is released.  This is a system in the field, and we should
be able to figure out how to deal with the broken firmware.  Asking
users to upgrade their firmware is not the solution I'm looking for.

There is nothing ia64-specific about this issue, so we should be able
to do this in some generic way.

Bjorn
--
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/