From: Feng Tang <feng.tang@linux.alibaba.com>
To: Bjorn Helgaas <bhelgaas@google.com>,
Lukas Wunner <lukas@wunner.de>,
Sathyanarayanan Kuppuswamy
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Liguang Zhang <zhangliguang@linux.alibaba.com>,
Guanghui Feng <guanghuifeng@linux.alibaba.com>,
rafael@kernel.org
Cc: Markus Elfring <Markus.Elfring@web.de>,
lkp@intel.com, Jonathan Cameron <Jonathan.Cameron@huawei.com>,
ilpo.jarvinen@linux.intel.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org,
Feng Tang <feng.tang@linux.alibaba.com>
Subject: [PATCH v3 4/4] PCI: Disable PCIe hotplug interrupts early when msi is disabled
Date: Mon, 24 Feb 2025 11:45:00 +0800 [thread overview]
Message-ID: <20250224034500.23024-5-feng.tang@linux.alibaba.com> (raw)
In-Reply-To: <20250224034500.23024-1-feng.tang@linux.alibaba.com>
There was an irq storm bug when testing "pci=nomsi" case, and the root
cause is: 'nomsi' will disable MSI and let devices and root ports use
legacy INTX interrupt, and likely make several devices/ports share one
interrupt. In the failure case, BIOS doesn't disable the PCIe hotplug
interrupts, and the command-complete interrupt was actually asserted.
So the timeline is:
1. pciehp's CCIE/HPIE enabled and command-complete interrupts asserted
2. the interrupt is shared by PCIe root port and nvme/nic device
3. nvme/nic driver's probe function enables the interrupt line
4. pciehp driver is loaded later or never loaded
And the "nobody cared irq storm" happens between 3 and 4. This is not
an issue for normal MSI case, as each interrupt is controlled by its own
driver. When the driver is not loaded, the interrupt won't get fired
to kernel even if it is physically asserted.
So disable the PCIe hotplug CCIE/HPIE interrupt in early boot phase when
MSI is not enabled.
Signed-off-by: Feng Tang <feng.tang@linux.alibaba.com>
---
drivers/pci/probe.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 246744d8d268..ffea7851366a 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1665,6 +1665,15 @@ void set_pcie_hotplug_bridge(struct pci_dev *pdev)
pcie_capability_read_dword(pdev, PCI_EXP_SLTCAP, ®32);
if (reg32 & PCI_EXP_SLTCAP_HPC)
pdev->is_hotplug_bridge = 1;
+
+ /*
+ * When MSI is disabled, root port will use legacy INTX, and likely
+ * share INTX interrupt line with other devices like NIC/NVME. There
+ * was real world issue that the CCIE IRQ is asserted afer boot, but
+ * will not be handled well and cause IRQ storm. So disable it early.
+ */
+ if (!pci_msi_enabled())
+ pcie_disable_hp_interrupts_early(pdev);
}
static void set_pcie_thunderbolt(struct pci_dev *dev)
--
2.43.5
prev parent reply other threads:[~2025-02-24 3:50 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 3:44 [PATCH v3 0/4] PCIe hotplug interrupt related fixes Feng Tang
2025-02-24 3:44 ` [PATCH v3 1/4] PCI: portdrv: pciehp: Move PCIe hotplug command waiting logic to port driver Feng Tang
2025-02-24 15:06 ` Ilpo Järvinen
2025-02-25 8:18 ` Feng Tang
2025-02-24 3:44 ` [PATCH v3 2/4] PCI/portdrv: Add necessary wait for disabling hotplug events Feng Tang
2025-02-24 9:42 ` Markus Elfring
2025-02-24 15:00 ` Ilpo Järvinen
2025-02-25 5:51 ` Feng Tang
2025-02-24 18:12 ` Lukas Wunner
2025-02-25 3:06 ` Feng Tang
2025-02-25 4:01 ` Lukas Wunner
2025-02-25 4:42 ` Feng Tang
2025-02-28 6:29 ` Feng Tang
2025-02-28 7:14 ` Lukas Wunner
2025-02-28 9:33 ` Feng Tang
2025-02-28 10:01 ` Feng Tang
2025-02-24 3:44 ` [PATCH v3 3/4] PCI/portdrv: Loose the condition check for disabling hotplug interrupts Feng Tang
2025-02-24 9:47 ` Markus Elfring
2025-02-25 4:09 ` Lukas Wunner
2025-02-26 2:54 ` Feng Tang
2025-02-24 3:45 ` Feng Tang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250224034500.23024-5-feng.tang@linux.alibaba.com \
--to=feng.tang@linux.alibaba.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Markus.Elfring@web.de \
--cc=bhelgaas@google.com \
--cc=guanghuifeng@linux.alibaba.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lukas@wunner.de \
--cc=rafael@kernel.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=zhangliguang@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox