Re: Are these MTRR settings correct?

From: Bjorn Helgaas
Date: Tue Dec 15 2009 - 11:55:16 EST


On Monday 14 December 2009 06:42:11 pm Yinghai Lu wrote:
> Robert Hancock wrote:
> > Something else isn't quite right. It looks like MMCONFIG area should be
> > reserved:
> >
> > [ 0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been
> > reserved
> >
> > but the code didn't seem to detect that. In fact there doesn't seem to
> > be any output about whether it was or wasn't reserved, which from the
> > code it seems there should be.
> >
> > Maybe because of that ACPI method execution error?
>
> could be sth pnpacpi brokenness?

Robert, I assume you're referring to this from Tvrtko's post
(http://lkml.org/lkml/2009/12/13/90):

[ 0.000000] BIOS-e820: 00000000dffd0000 - 00000000e0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
...
[ 0.250088] PCI: Found AMD Family 10h NB with MMCONFIG support.
[ 0.250091] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[ 0.250092] PCI: Not using MMCONFIG.
...
[ 0.253491] ACPI Error (psargs-0359): [ECEN] Namespace lookup failure, AE_NOT_FOUND
[ 0.253495] ACPI Error (psparse-0537): Method parse/execution failed [\] (Node ffffffff81656ab0), AE_NOT_FOUND
...
[ 0.308434] system 00:0c: iomem range 0xe0000000-0xefffffff has been reserved

I think we're rejecting MMCONFIG in the early call to
pci_mmcfg_reject_broken(), when we check only E820 resources, not
ACPI resources. And indeed, the 0xe0000000-0xefffffff range is
not mentioned in E820. Which output did you expect to see?

I am uncomfortable with this early/late checking and looking at both
E820 and ACPI. It just feels hacky and error-prone. I'm not happy about
adding Yinghai's special-case "if we found AMD Fam10h, don't check for
reservations" patch either.

I assume that Windows runs on this box without requiring per-machine
hacks in the kernel. Linux should be able to do the same, and the fact
that we can't is telling us we're doing somethign wrong. We should fix
whatever's wrong rather than papering over it.

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/