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

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

[Bjorn Helgaas]

On Wed, Nov 7, 2012 at 7:55 PM, Peter Hurley <peter@hurleysoftware.com> 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@google.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: H. Peter Anvin <hpa@zytor.com>
> Cc: x86@kernel.org
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
> ---
>  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
>

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

[Peter Hurley]

On Sat, 2012-11-10 at 14:52 -0700, Bjorn Helgaas wrote:
> On Wed, Nov 7, 2012 at 7:55 PM, Peter Hurley <peter@hurleysoftware.com> 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?

I presume so.

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

Correct. There is no fix; only a diagnostic warning.

The warning is also a 'red flag' that, on this machine, it might be
better to boot the kernel with the "pci=nocrs" option.

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

(note: I included a link below to the defect report which has
the /proc/iomem, dmesg & dmidecode)

The situation is this:

The adjacent resources (northbridge & southbridge) are not defined by
ACPI, but rather reserved with an e820 address descriptor from
[0xfe000000-0xfeffffff], so strictly speaking there is no overlapping
ACPI resource.

The e820 descriptor is bumped out to [0xf0000000-0xfeffffff] and the
malformed host bridge window is reparented to it.

At this point in the boot, there is no resource conflict.

Later in the boot, the i5k_amb driver tries to map
[0xfe000000-0xfe01ffff] which is the FB-DIMM AMB register window on the
Intel 5400 MCH and is rejected. The request is rejected because the
requested range does not map completely to a single parent and this is
not allowed. (The i5k_amb driver exposes the FB-DIMM temperature sensors
through sysfs).

There is no problem in Windows because no driver attempts to allocate
[0xfe000000-0xfe01ffff]. However, I doubt the PNP Manager would allow
another bus pdo to claim an overlapping resource with PCI bus 0. I
suspect the offending device would yellow bang. (That would be an
interesting experiment...)

> 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?

Auto-fixing this seems problematic because it's essentially impossible
to determine if the resource length or the resource end or both is
wrong.

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

https://bugzilla.kernel.org/show_bug.cgi?id=50161

Regards,
Peter Hurley

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

[Peter Hurley]

Ping?

On Sun, 2012-11-11 at 09:49 -0500, Peter Hurley wrote:
> On Sat, 2012-11-10 at 14:52 -0700, Bjorn Helgaas wrote:
> > On Wed, Nov 7, 2012 at 7:55 PM, Peter Hurley <peter@hurleysoftware.com> 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?
> 
> I presume so.
> 
> > > 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.
> 
> Correct. There is no fix; only a diagnostic warning.
> 
> The warning is also a 'red flag' that, on this machine, it might be
> better to boot the kernel with the "pci=nocrs" option.
> 
> > 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.
> 
> (note: I included a link below to the defect report which has
> the /proc/iomem, dmesg & dmidecode)
> 
> The situation is this:
> 
> The adjacent resources (northbridge & southbridge) are not defined by
> ACPI, but rather reserved with an e820 address descriptor from
> [0xfe000000-0xfeffffff], so strictly speaking there is no overlapping
> ACPI resource.
> 
> The e820 descriptor is bumped out to [0xf0000000-0xfeffffff] and the
> malformed host bridge window is reparented to it.
> 
> At this point in the boot, there is no resource conflict.
> 
> Later in the boot, the i5k_amb driver tries to map
> [0xfe000000-0xfe01ffff] which is the FB-DIMM AMB register window on the
> Intel 5400 MCH and is rejected. The request is rejected because the
> requested range does not map completely to a single parent and this is
> not allowed. (The i5k_amb driver exposes the FB-DIMM temperature sensors
> through sysfs).
> 
> There is no problem in Windows because no driver attempts to allocate
> [0xfe000000-0xfe01ffff]. However, I doubt the PNP Manager would allow
> another bus pdo to claim an overlapping resource with PCI bus 0. I
> suspect the offending device would yellow bang. (That would be an
> interesting experiment...)
> 
> > 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?
> 
> Auto-fixing this seems problematic because it's essentially impossible
> to determine if the resource length or the resource end or both is
> wrong.
> 
> > Is there a bugzilla or a complete dmesg log to look at?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=50161
> 
> Regards,
> Peter Hurley
> 
>