Re: [PATCH 4/5] x86: acpi: Print warning for malformed host bridge resources

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 7, 2012 at 7:55 PM, Peter Hurley <peter@xxxxxxxxxxxxxxxxxx> wrote:
> An incorrectly specified host bridge window may prevent
> other devices from claiming assigned resources. For example,
> this flawed _CRS resource descriptor from a Dell T5400:
>      DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
>          0x00000000,         // Granularity
>          0xF0000000,         // Range Minimum
>          0xFE000000,         // Range Maximum
>          0x00000000,         // Translation Offset
>          0x0E000000,         // Length
>          ,, , AddressRangeMemory, TypeStatic)

I think the problem here is that the Range Maximum should be
0xFDFFFFFF, not 0xFE000000, right?

> prevents the adjacent device from claiming [mem 0xfe0000000-0xfe01ffff]
>
> Sanity check that the resource at least conforms to a valid
> PCI BAR; if not, emit a diagnostic warning.
>
> Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> Cc: H. Peter Anvin <hpa@xxxxxxxxx>
> Cc: x86@xxxxxxxxxx
> Signed-off-by: Peter Hurley <peter@xxxxxxxxxxxxxxxxxx>
> ---
>  arch/x86/pci/acpi.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 192397c..3468d16 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -298,6 +298,10 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
>                         "host bridge window [%#llx-%#llx] "
>                         "([%#llx-%#llx] ignored, not CPU addressable)\n",
>                         start, orig_end, end + 1, orig_end);
> +       } else if (flags & IORESOURCE_MEM && (start & 0x0f || ~end & 0x0f)) {
> +               dev_warn(&info->bridge->dev,
> +                        "invalid host bridge window [%#llx-%#llx]\n",
> +                        start, end);

We didn't actually *fix* anything here, so I guess we're just pointing
out the reason for a subsequent failure to claim the adjacent
resource.

As far as I know, the spec doesn't actually require resources of ACPI
devices to be non-overlapping.  Windows accepts overlapping resources,
and I think Linux probably should, too, but right now we trip over
this.

In the meantime (until we figure out how to handle overlapping
resources better), can we do something to actually fix this?  Maybe we
should truncate the end of the range to 0xFDFFFFFF like we do for
non-addressable parts of the range?

Is there a bugzilla or a complete dmesg log to look at?

Bjorn

>         }
>
>         res = &info->res[info->res_num];
> --
> 1.7.12.3
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux