[[e-mail]:,[Bug,216217] New: PCI e820 got screwed up, some systems completely fail to boot.]

Commit Message

Bjorn Helgaas July 7, 2022, 10:21 p.m. UTC

----- Forwarded message from [e-mail] -----

Date: Thu, 07 Jul 2022 21:10:55 +0000
From: [e-mail]
To: [e-mail]
Subject: [Bug 216217] New: PCI e820 got screwed up, some systems completely
	fail to boot.
Message-ID: <[e-mail]/>

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

            Bug ID: 216217
           Summary: PCI e820 got screwed up, some systems completely fail
                    to boot.
           Product: Drivers
           Version: 2.5
    Kernel Version: 5.19-rc4
          Hardware: AMD
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: high
          Priority: P1
         Component: PCI
          Assignee: [e-mail]
          Reporter: [e-mail]
        Regression: No

In last few recent mainline kernels something got completely screwed up in
regard of e820 vs PCI on one of computer systems.

Kernels up to 5.16 booting just fine on mentioned system. However, around
approx kernel 5.17 something changed in regard how PCI handles e820.
Unfortunately it completely broken mentioned system to extent it FAILS TO BOOT
with recent kernels.

It looks like if PCI woefully fails resources reservations or so, this in turn
results in failing to initialize numerous devices, ranging from GPU to
networking, so overall system gets stuck without graphics (!!!) and generally
stuck in the middle of boot.

Details:
Investigation shown commit around a2b36ffbf5b6ec301e61249c8b09e610bc80772f
hints there were some changes on how PCI vs e820 handled and some bool boot
parameter has been added to control PCI e820 behavior. Unfortunately with it
default state kernels BACKFIRE on mentioned system and COMPLETELY FAIL TO BOOT.
Which isn't anyhow acceptable state of things.

I had to use "pci=no_e820" kernel command line as hinted, this restores sane
PCI behavior so system could boot properly.

Boot log upon use of this override suggests I should report this condition so
future kernels suxx a bit less.

Just in case... 
[    0.000000] DMI: Gigabyte Technology Co., Ltd. GA-990FXA-UD5/GA-990FXA-UD5,
BIOS F5 08/29/2011

...

[    2.534896] ACPI: Interpreter enabled
[    2.534919] ACPI: PM: (supports S0 S3 S4 S5)
[    2.534921] ACPI: Using IOAPIC for interrupt routing
[    2.534960] PCI: Using host bridge windows from ACPI; if necessary, use
"pci=nocrs" and report a bug
[    2.534961] PCI: Ignoring E820 reservations for host bridge windows
[    2.534962] PCI: Please notify [e-mail] so future kernels
can this automatically
[    2.535123] ACPI: Enabled 9 GPEs in block 00 to 1F
[    2.539860] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    2.539867] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM
Segments MSI EDR HPX-Type3]
[    2.540155] PCI host bridge to bus 0000:00

I could collect other details if necessary.

Patch

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index a4f43054bc79..04396dbdd1c5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -190,6 +190,18 @@  static const struct dmi_system_id pci_crs_quirks[] __initconst = {
 			DMI_MATCH(DMI_BOARD_NAME, "X170KM-G"),
 		},
 	},
+
+	/*
+	 * See https://bugzilla.kernel.org/show_bug.cgi?id=216217
+	 */
+	{
+		.callback = set_no_e820,
+		.ident = "Gigabyte GA-990FXA-UD5",
+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Gigabyte Technology Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "GA-990FXA-UD5"),
+		},
+	},
 	{}
 };
 
@@ -246,7 +258,7 @@  void __init pci_acpi_crs_quirks(void)
 	printk(KERN_INFO "PCI: %s E820 reservations for host bridge windows\n",
 	       pci_use_e820 ? "Using" : "Ignoring");
 	if (pci_probe & (PCI_NO_E820 | PCI_USE_E820))
-		printk(KERN_INFO "PCI: Please notify [e-mail] so future kernels can this automatically\n");
+		printk(KERN_INFO "PCI: Please notify [e-mail] so future kernels can do this automatically\n");
 }
 
 #ifdef	CONFIG_PCI_MMCONFIG