We have a few reports of sound devices not working because the BIOS didn't
assign space for the device and the PCI core put it at an address that
doesn't work.
The Foxconn system has two PCI host bridges, and without the information
from _CRS, the PCI core assigns space under the wrong bridge.
We also have reports from pre-2008 systems (where we normally ignore _CRS)
that support more than 32 physical address bits. After d56dbf5bab8c ("PCI:
Allocate 64-bit BARs above 4G when possible"), we prefer to use that high
space when we can, but it seems the host bridge doesn't respond to it.
_CRS tells us how to avoid both problems, so these patches enable it for
these cases.
---
Bjorn Helgaas (2):
x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A
x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing
arch/x86/pci/acpi.c | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign
resources correctly without the information from _CRS that tells us which
address ranges are claimed by which bridge. In the bugs mentioned below,
we incorrectly assign a sound card address (this example is from 1033299):
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored)
pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored)
pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored)
ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])
pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored)
pci 0000:80:01.0: [1106:3288] type 0 class 0x000403
pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit]
pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff]
pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit]
BUG: unable to handle kernel paging request at ffffc90000378000
IP: [<ffffffffa0345f63>] azx_create+0x37c/0x822 [snd_hda_intel]
Turn on pci=use_crs automatically for this system.
Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368
Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299
Signed-off-by: Bjorn Helgaas <[email protected]>
---
arch/x86/pci/acpi.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index e469598..d8e2258 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -81,6 +81,17 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = {
DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
},
},
+ /* https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368 */
+ /* https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299 */
+ {
+ .callback = set_use_crs,
+ .ident = "Foxconn K8M890-8237A",
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Foxconn"),
+ DMI_MATCH(DMI_BOARD_NAME, "K8M890-8237A"),
+ DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
+ },
+ },
/* Now for the blacklist.. */
We enable _CRS on all systems from 2008 and later. On older systems, we
ignore _CRS and assume the whole physical address space (excluding RAM and
other devices) is available for PCI devices, but on systems that support
physical address spaces larger than 4GB, it's doubtful that the area above
4GB is really available for PCI.
After d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible"), we
try to use that space above 4GB *first*, so we're more likely to put a
device there.
Several people have reported sound problems related to putting a device
above 4GB. This could happen with any device; I assume it's more likely
for sound devices because the BIOS is more likely to leave them unassigned.
Keep _CRS enabled even on pre-2008 systems if they support physical address
space larger than 4GB.
Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible")
Reported-by: dayer <[email protected]>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=99221
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=907092
Signed-off-by: Bjorn Helgaas <[email protected]>
---
arch/x86/pci/acpi.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index d8e2258..2ae7ce2 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -132,8 +132,10 @@ void __init pci_acpi_crs_quirks(void)
{
int year;
- if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008)
- pci_use_crs = false;
+ if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008) {
+ if (iomem_resource.end <= 0xffffffff)
+ pci_use_crs = false;
+ }
dmi_check_system(pci_crs_quirks);
On Tue, Jun 16, 2015 at 11:55 AM, Bjorn Helgaas <[email protected]> wrote:
> We have a few reports of sound devices not working because the BIOS didn't
> assign space for the device and the PCI core put it at an address that
> doesn't work.
>
> The Foxconn system has two PCI host bridges, and without the information
> from _CRS, the PCI core assigns space under the wrong bridge.
>
> We also have reports from pre-2008 systems (where we normally ignore _CRS)
> that support more than 32 physical address bits. After d56dbf5bab8c ("PCI:
> Allocate 64-bit BARs above 4G when possible"), we prefer to use that high
> space when we can, but it seems the host bridge doesn't respond to it.
>
> _CRS tells us how to avoid both problems, so these patches enable it for
> these cases.
>
> ---
>
> Bjorn Helgaas (2):
> x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A
> x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing
I applied both patches to pci/resource for v4.2.