Public bug reported:
SRU Justification:
Impact:
Since upstream commit eed85ff4c0da7 (4.16), control of PCIe DPC
(Downstream Port Containment) is coupled with control of AER (Advanced
Error Reporting), eliminating the option for the kernel to separately
manage DPC (which was previously the default behavior).
Fix:
The upstream commit log explains the change:
commit 35a0b2378c199d4f26e458b2ca38ea56aaf2d9b8
Author: Olof Johansson <o...@lixom.net>
Date: Wed Oct 23 12:22:05 2019 -0700
PCI/DPC: Add "pcie_ports=dpc-native" to allow DPC without AER control
Prior to eed85ff4c0da7 ("PCI/DPC: Enable DPC only if AER is available"),
Linux handled DPC events regardless of whether firmware had granted it
ownership of AER or DPC, e.g., via _OSC.
PCIe r5.0, sec 6.2.10, recommends that the OS link control of DPC to
control of AER, so after eed85ff4c0da7, Linux handles DPC events only if it
has control of AER.
On platforms that do not grant OS control of AER via _OSC, Linux DPC
handling worked before eed85ff4c0da7 but not after.
To make Linux DPC handling work on those platforms the same way they did
before, add a "pcie_ports=dpc-native" kernel parameter that makes Linux
handle DPC events regardless of whether it has control of AER.
[bhelgaas: commit log, move pcie_ports_dpc_native to drivers/pci/]
Link: https://lore.kernel.org/r/20191023192205.97024-1-o...@lixom.net
Signed-off-by: Olof Johansson <o...@lixom.net>
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
Testcase:
Control of DPC can be determined from kernel boot messages when
pciehp probes a capable slot; when the kernel controls DPC, messages
of the format:
pcieport 0000:2d:00.0: pciehp: Slot #0
pcieport 0000:2d:00.0: DPC: error containment capabilities:
will appear; if the kernel does not control DPC, the DPC line will
not be present (only the "pciehp: Slot" message).
Additionally, devices bound to the kernel DPC PCIe port service
driver will be found in the /sys/bus/pci_express/drivers/dpc/ sysfs
directory; this will be empty of devices if the kernel does not control
DPC.
Regression Potential:
The risk of regression is low as (a) by default, the patch has no
effect (the default setting is to not enable the option), and (b) when
enabled, the patch restores functionality that previously worked, and was,
in fact, the default behavior.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1869423
Title:
Restore kernel control of PCIe DPC via option
Status in linux package in Ubuntu:
New
Bug description:
SRU Justification:
Impact:
Since upstream commit eed85ff4c0da7 (4.16), control of PCIe DPC
(Downstream Port Containment) is coupled with control of AER (Advanced
Error Reporting), eliminating the option for the kernel to separately
manage DPC (which was previously the default behavior).
Fix:
The upstream commit log explains the change:
commit 35a0b2378c199d4f26e458b2ca38ea56aaf2d9b8
Author: Olof Johansson <o...@lixom.net>
Date: Wed Oct 23 12:22:05 2019 -0700
PCI/DPC: Add "pcie_ports=dpc-native" to allow DPC without AER control
Prior to eed85ff4c0da7 ("PCI/DPC: Enable DPC only if AER is available"),
Linux handled DPC events regardless of whether firmware had granted it
ownership of AER or DPC, e.g., via _OSC.
PCIe r5.0, sec 6.2.10, recommends that the OS link control of DPC to
control of AER, so after eed85ff4c0da7, Linux handles DPC events only if
it
has control of AER.
On platforms that do not grant OS control of AER via _OSC, Linux DPC
handling worked before eed85ff4c0da7 but not after.
To make Linux DPC handling work on those platforms the same way they did
before, add a "pcie_ports=dpc-native" kernel parameter that makes Linux
handle DPC events regardless of whether it has control of AER.
[bhelgaas: commit log, move pcie_ports_dpc_native to drivers/pci/]
Link: https://lore.kernel.org/r/20191023192205.97024-1-o...@lixom.net
Signed-off-by: Olof Johansson <o...@lixom.net>
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
Testcase:
Control of DPC can be determined from kernel boot messages when
pciehp probes a capable slot; when the kernel controls DPC, messages
of the format:
pcieport 0000:2d:00.0: pciehp: Slot #0
pcieport 0000:2d:00.0: DPC: error containment capabilities:
will appear; if the kernel does not control DPC, the DPC line will
not be present (only the "pciehp: Slot" message).
Additionally, devices bound to the kernel DPC PCIe port service
driver will be found in the /sys/bus/pci_express/drivers/dpc/ sysfs
directory; this will be empty of devices if the kernel does not control
DPC.
Regression Potential:
The risk of regression is low as (a) by default, the patch has no
effect (the default setting is to not enable the option), and (b) when
enabled, the patch restores functionality that previously worked, and was,
in fact, the default behavior.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869423/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
