Improve PCI device post-reset readiness polling
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v4 Latest3 patches 15 repliesIn review
- v317 patches 6 repliesSuperseded
- v217 patches 0 repliesSuperseded
Earlier versions · 1
| Version | Posted | Patches | Replies | Status |
|---|---|---|---|---|
| v1 | 3 patches | 11 replies | Superseded |
Changes in v4 from the cover letter
- In pci_dev_wait(), added "timeout -= waited" to account the time spent polling PCI_VENDOR_ID before falling back to polling PCI_COMMAND if device readiness could not be positively established via CRS (i.e., if we stopped receiving CRS completions but did not receive a valid vendor ID due to dealing with an SR-IOV VF, or due to a different error)
- Simplified the commit message of "PCI: Add CRS handling to pci_dev_wait()" to avoid confusion as to when Root Ports will autonomously retry requests that resulted in CRS completions.
Patches in v4 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | PCI: Refactor polling loop out of pci_dev_waitdrivers/ | +49 | 0 replies | |
| 2/3 | PCI: Cache CRS Software Visibiliy in struct pci_devdrivers/ include/ | +10 | 2 replies | |
| 3/3 | PCI: Add CRS handling to pci_dev_wait()drivers/ | +47 | 11 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v4 yet.
Cover letter [PATCH v4 0/3] Improve PCI device post-reset readiness polling
From: Stanislav Spassov <[email protected]>
The first version of this patch series can be found here:
https://lore.kernel.org/linux-pci/[email protected]
The goal of this patch series is to solve an issue where pci_dev_wait can cause system crashes. After a reset, a hung device may keep responding with CRS completions indefinitely. If CRS Software Visibility is enabled on the Root Port, attempting to read any register other than PCI_VENDOR_ID will cause the Root Port to autonomously retry the request without reporting back to the CPU core. Unless the number of retries or the amount of time spent retrying is limited by platform-specific means, this scenario leads to low-level platform timeouts (such as a TOR Timeout), which can easily escalate to a crash.
Feedback on the v1 inspired a lot of additional improvements all around the device reset codepaths and reducing post-reset delays. These improvements were published as part of v2 (v3 is just small build fixes).
It looks like there is immediate demand specifically for the CRS work, so I am once again reducing the series to just that. The reset will be posted as a separate patch series that will likely require more time and iterations to stabilize.
Changes since v3:
- In pci_dev_wait(), added "timeout -= waited" to account the time spent polling PCI_VENDOR_ID before falling back to polling PCI_COMMAND if device readiness could not be positively established via CRS (i.e., if we stopped receiving CRS completions but did not receive a valid vendor ID due to dealing with an SR-IOV VF, or due to a different error)
- Simplified the commit message of "PCI: Add CRS handling to pci_dev_wait()" to avoid confusion as to when Root Ports will autonomously retry requests that resulted in CRS completions.
Stanislav Spassov (3):
PCI: Refactor polling loop out of pci_dev_wait
PCI: Cache CRS Software Visibiliy in struct pci_dev
PCI: Add CRS handling to pci_dev_wait()
drivers/pci/pci.c | 109 +++++++++++++++++++++++++++++++++++--------- drivers/pci/probe.c | 8 +++- include/linux/pci.h | 3 ++ 3 files changed, 98 insertions(+), 22 deletions(-)
base-commit: bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9
Signature · 12 lines
2.25.1 Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879