https://bugzilla.kernel.org/show_bug.cgi?id=201001
Bug ID: 201001
Summary: System with FADT ASPM disable bit set hangs at boot
after '1302fcf PCI: Configure *all* devices, not just
hot-added ones'
Product: ACPI
Version: 2.5
Kernel Version: 4.17.0
Hardware: All
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Config-Other
Assignee: [email protected]
Reporter: [email protected]
Regression: No
Created attachment 278259
--> https://bugzilla.kernel.org/attachment.cgi?id=278259&action=edit
lspci -vvv output from affected host
This bug is filed as a follow-up to the linux-pci mailing list thread found
here:
-------------------------------------------------------------
https://www.spinics.net/lists/linux-pci/msg75104.html
Subject: Should pcie_aspm_init_link_state() run when FADT ASPM disable bit is
set?
From: Patrick Talbert <ptalbert@xxxxxxxxxx>
Date: Thu, 9 Aug 2018 09:25:20 +0200
-------------------------------------------------------------
A RHEL 7 system was found to hang at boot after a kernel update, but only when
a custom proprietary PCIE card was installed in the system. The problem was
bisected down to the following commit:
1302fcf PCI: Configure *all* devices, not just hot-added ones
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1302fcf0d03e6ea74846c7fee14736306ab2ce4b
It was further confirmed that the hang still occurred using an upstream 4.17.0
kernel.
The customer who reports this issue to RH has the ability to record PCI bus
activity. They provided this logging and I was able to correspond all the bus
activity and dmesg output directly to pci_scan_slot() activity as it descends
into pci_scan_device() and initializes the card. So with this we could confirm
everything appears to work as expected at least until pci_scan_slot() gets to:
2448 /* Only one slot has PCIe device */
2449 if (bus->self && nr)
2450 pcie_aspm_init_link_state(bus->self);
2451
2452 return nr;
2453 }
2454 EXPORT_SYMBOL(pci_scan_slot);
... which is where the dmesg output hangs and the PCI debugger output stopped.
This pointed me to a possible issue with ASPM, at which point I noticed the
system logs the following at boot ...
[ 18.347488] ACPI FADT declares the system doesn't support PCIe ASPM, so
disable it
... and we then found the system boots normally with pcie_aspm=off set.
So that brings me to the question I posed in the linux-pci mailing list email:
Should pcie_aspm_init_link_state() run when FADT ASPM disable bit is set? It
*seems* like there should be a change like the following as as when
acpi_pci_init() sees the ACPI_FADT_NO_ASPM bit set it calls pcie_no_aspm()
which sets aspm_disabled (but not !aspm_support_enabled):
diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 8b56dad..5491dbf 100644
--- a/drivers/pci/pcie/aspm.c
+++ b/drivers/pci/pcie/aspm.c
@@ -574,7 +574,7 @@ void pcie_aspm_init_link_state(struct pci_dev *pdev)
struct pcie_link_state *link;
int blacklist = !!pcie_aspm_sanity_check(pdev);
- if (!aspm_support_enabled)
+ if (!aspm_support_enabled || aspm_disabled)
return;
if (pdev->link_state)
--
You are receiving this mail because:
You are watching the assignee of the bug.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
