I see two problems in the initial report from FichdlMaa:
1) Linux ignores ACPI _CRS information and consequently assigns addresses to the 80:01.0 device that may not work.
2) The page fault: "BUG: unable to handle kernel paging request at ffffc90000378000"
Booting with "pci=use_crs" should work around the first problem. This is only a workaround, not a real fix because we don't expect users to have to use that option.
If "pci=use_crs" makes a difference, and if it still fixes a problem in the current upstream kernel (v4.0-rcX), please open a bug report at http://bugzilla.kernel.org (in drivers/pci category), attaching a complete dmesg log, and we can add a quirk to turn on that option automatically.
I don't have a theory about the page fault problem.
Details about the _CRS problem:
bus: 00 index 2 [mem 0x80000000-0xfcffffffff]
The range above is from amd_bus.c. Note that it covers the mem windows for both PCI0 and PCI1 below.
The initial configuration from BIOS (above) looks correct. The 80:01.0 BAR 0 is inside the PCI1 host bridge window reported by ACPI _CRS.
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]
But we're ignoring _CRS and using the information from amd_bus.c, so we think there's a conflict with the PCI0 window. We reassign 80:01.0 to an address that is under PCI0, not PCI1. If the ACPI _CRS description is correct, this means MMIO accesses intended for 80:01.0 will never reach the device.
I see two problems in the initial report from FichdlMaa:
1) Linux ignores ACPI _CRS information and consequently assigns addresses to the 80:01.0 device that may not work.
2) The page fault: "BUG: unable to handle kernel paging request at ffffc90000378000"
Booting with "pci=use_crs" should work around the first problem. This is only a workaround, not a real fix because we don't expect users to have to use that option.
If "pci=use_crs" makes a difference, and if it still fixes a problem in the current upstream kernel (v4.0-rcX), please open a bug report at http:// bugzilla. kernel. org (in drivers/pci category), attaching a complete dmesg log, and we can add a quirk to turn on that option automatically.
I don't have a theory about the page fault problem.
Details about the _CRS problem:
bus: 00 index 2 [mem 0x80000000- 0xfcffffffff]
The range above is from amd_bus.c. Note that it covers the mem windows for both PCI0 and PCI1 below.
PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug 0xbfefffff] (ignored) 0xdfffffff] (ignored) 0xfebfffff] (ignored) 0x000bffff] (ignored) 0xbfffffff] (ignored) 0xbfffffff 64bit]
ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
pci_root PNP0A08:00: host bridge window [mem 0x80000000-
pci_root PNP0A08:00: host bridge window [mem 0xc0000000-
pci_root PNP0A08:00: host bridge window [mem 0xf0000000-
ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])
pci_root PNP0A08:01: host bridge window [mem 0x000a0000-
pci_root PNP0A08:01: host bridge window [mem 0xbff00000-
pci 0000:80:01.0: [1106:3288] type 0 class 0x000403
pci 0000:80:01.0: reg 10: [mem 0xbfffc000-
The initial configuration from BIOS (above) looks correct. The 80:01.0 BAR 0 is inside the PCI1 host bridge window reported by ACPI _CRS.
pci 0000:80:01.0: address space collision: [mem 0xbfffc000- 0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000- 0xfcffffffff] 0xfd00003fff 64bit]
pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-
But we're ignoring _CRS and using the information from amd_bus.c, so we think there's a conflict with the PCI0 window. We reassign 80:01.0 to an address that is under PCI0, not PCI1. If the ACPI _CRS description is correct, this means MMIO accesses intended for 80:01.0 will never reach the device.