diff options
| author | Bjorn Helgaas <bjorn.helgaas@hp.com> | 2010-07-23 12:53:27 -0600 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@suse.de> | 2010-08-13 13:30:38 -0700 |
| commit | 4fbb306c756c548a75d480141e327111e4d94d20 (patch) | |
| tree | 9f7a777ea5760670864a1207a266b1e3783d1da5 /arch/x86 | |
| parent | 97537a758d5d29534ec0b280403c182fe5155ee5 (diff) | |
x86/PCI: use host bridge _CRS info on ASRock ALiveSATA2-GLAN
commit 2491762cfb475dbdfa3db11ebea6de49f58b7fac upstream.
This DMI quirk turns on "pci=use_crs" for the ALiveSATA2-GLAN because
amd_bus.c doesn't handle this system correctly.
The system has a single HyperTransport I/O chain, but has two PCI host
bridges to buses 00 and 80. amd_bus.c learns the MMIO range associated
with buses 00-ff and that this range is routed to the HT chain hosted at
node 0, link 0:
bus: [00, ff] on node 0 link 0
bus: 00 index 1 [mem 0x80000000-0xfcffffffff]
This includes the address space for both bus 00 and bus 80, and amd_bus.c
assumes it's all routed to bus 00.
We find device 80:01.0, which BIOS left in the middle of that space, but
we don't find a bridge from bus 00 to bus 80, so we conclude that 80:01.0
is unreachable from bus 00, and we move it from the original, working,
address to something outside the bus 00 aperture, which does not work:
pci 0000:80:01.0: reg 10: [mem 0xfebfc000-0xfebfffff 64bit]
pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit]
The BIOS told us everything we need to know to handle this correctly,
so we're better off if we just pay attention, which lets us leave the
80:01.0 device at the original, working, address:
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
pci_root PNP0A03:00: host bridge window [mem 0x80000000-0xff37ffff]
ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])
pci_root PNP0A08:00: host bridge window [mem 0xfebfc000-0xfebfffff]
This was a regression between 2.6.33 and 2.6.34. In 2.6.33, amd_bus.c
was used only when we found multiple HT chains. 3e3da00c01d050, which
enabled amd_bus.c even on systems with a single HT chain, caused this
failure.
This quirk was written by Graham. If we ever enable "pci=use_crs" for
machines from 2006 or earlir, this quirk should be removed.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16007
Reported-by: Graham Ramsey <ramsey.graham@ntlworld.com>
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'arch/x86')
| -rw-r--r-- | arch/x86/pci/acpi.c | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c index 2ec04c424a62..15466c096ba5 100644 --- a/arch/x86/pci/acpi.c +++ b/arch/x86/pci/acpi.c @@ -34,6 +34,15 @@ static const struct dmi_system_id pci_use_crs_table[] __initconst = { DMI_MATCH(DMI_PRODUCT_NAME, "x3800"), }, }, + /* https://bugzilla.kernel.org/show_bug.cgi?id=16007 */ + /* 2006 AMD HT/VIA system with two host bridges */ + { + .callback = set_use_crs, + .ident = "ASRock ALiveSATA2-GLAN", + .matches = { + DMI_MATCH(DMI_PRODUCT_NAME, "ALiveSATA2-GLAN"), + }, + }, {} }; |