Patchset sent to KTML:
https://lists.ubuntu.com/archives/kernel-team/2025-August/162609.html
** Description changed:
- Description:
+ [ Impact ]
+
s390/pci: Handle PCI error codes other than 0x3a
- Symptom:
+ The Linux implementation of PCI error recovery for s390 was based on the
+ understanding that firmware error recovery is a two step process with an
+ optional initial error event to indicate the cause of the error if known
+ followed by either error event 0x3A (Success) or 0x3B (Failure) to
+ indicate whether firmware was able to recover. While this has been the
+ case in testing and the error cases seen in the wild it turns out this
+ is not correct. Instead firmware only generates 0x3A for some error and
+ service scenarios and expects the OS to perform recovery for all PCI
+ events codes except for those indicating permanent error (0x3B, 0x40)
+ and those indicating errors on the function measurement block (0x2A,
+ 0x2B, 0x2C). Align Linux behavior with these expectations.
+
+ [ Fix ]
+
+ Backport the following commit from upstream:
+ - 3cd03ea57e8e s390/pci: Handle PCI error codes other than 0x3a
+
+ [ Test Plan ]
+
+ Boot the kernel on an IBM Z system with PCI devices bound to drivers
+ that support error recovery and inject different PCI error codes. For
+ recoverable errors, check that the device auto-recovers and remains
+ usable. For 0x2A–0x2C errors, verify they are ignored with no impact.
+ For permanent failure codes (0x3B, 0x40), confirm the device is
+ correctly marked as failed. Use dmesg to validate that recovery paths
+ are triggered as expected and that unaffected devices continue normal
+ operation.
+
+ [ Regression Potential ]
+
+ The fix affects how the s390 PCI error handler interprets and reacts to PCI
event codes. A bug here could cause error codes to be misclassified, leading to
incorrect recovery actions.
+ Users may see devices being driven into recovery even for irrelevant events,
devices left permanently failed when they should have recovered, or recovery
attempts being triggered repeatedly in a loop.
+
+ ---
+
+ Description:
+ s390/pci: Handle PCI error codes other than 0x3a
+
+ Symptom:
When hardware reports some error other than the generic 0x3a for a PCI device
it is left in a "frozen" state to be recovered manually.
- Problem:
+ Problem:
This requires manual intervention in some error scenarios.
- Reproduction:
+ Reproduction:
Inject errors - either through instrumented kernel code, or through HW inject
methods.
- Solution:
+ Solution:
Attempt the same PCI auto-recovery for these errors, if the respective device
driver supports that.
Upstream-ID: 3cd03ea57e8e16cc78cc357d5e9f26078426f236
Upstream-Description:
s390/pci: Handle PCI error codes other than 0x3a
The Linux implementation of PCI error recovery for s390 was based on the
understanding that firmware error recovery is a two step process with an
optional initial error event to indicate the cause of the error if known
followed by either error event 0x3A (Success) or 0x3B (Failure) to
indicate whether firmware was able to recover. While this has been the
case in testing and the error cases seen in the wild it turns out this
is not correct. Instead firmware only generates 0x3A for some error and
service scenarios and expects the OS to perform recovery for all PCI
events codes except for those indicating permanent error (0x3B, 0x40)
and those indicating errors on the function measurement block (0x2A,
0x2B, 0x2C). Align Linux behavior with these expectations.
Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery")
Reviewed-by: Gerd Bayer <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
** Description changed:
[ Impact ]
s390/pci: Handle PCI error codes other than 0x3a
The Linux implementation of PCI error recovery for s390 was based on the
understanding that firmware error recovery is a two step process with an
optional initial error event to indicate the cause of the error if known
followed by either error event 0x3A (Success) or 0x3B (Failure) to
indicate whether firmware was able to recover. While this has been the
case in testing and the error cases seen in the wild it turns out this
is not correct. Instead firmware only generates 0x3A for some error and
service scenarios and expects the OS to perform recovery for all PCI
events codes except for those indicating permanent error (0x3B, 0x40)
and those indicating errors on the function measurement block (0x2A,
0x2B, 0x2C). Align Linux behavior with these expectations.
[ Fix ]
Backport the following commit from upstream:
- 3cd03ea57e8e s390/pci: Handle PCI error codes other than 0x3a
[ Test Plan ]
- Boot the kernel on an IBM Z system with PCI devices bound to drivers
- that support error recovery and inject different PCI error codes. For
- recoverable errors, check that the device auto-recovers and remains
- usable. For 0x2A–0x2C errors, verify they are ignored with no impact.
- For permanent failure codes (0x3B, 0x40), confirm the device is
- correctly marked as failed. Use dmesg to validate that recovery paths
- are triggered as expected and that unaffected devices continue normal
- operation.
+ Boot the kernel on an IBM Z system with PCI devices bound to drivers that
support error recovery and inject different PCI error codes.
+ For recoverable errors, check that the device auto-recovers and remains
usable.
+ For 0x2A–0x2C errors, verify they are ignored with no impact.
+ For permanent failure codes (0x3B, 0x40), confirm the device is correctly
marked as failed.
+ Use dmesg to validate that recovery paths are triggered as expected and that
unaffected devices continue normal operation.
[ Regression Potential ]
The fix affects how the s390 PCI error handler interprets and reacts to PCI
event codes. A bug here could cause error codes to be misclassified, leading to
incorrect recovery actions.
Users may see devices being driven into recovery even for irrelevant events,
devices left permanently failed when they should have recovered, or recovery
attempts being triggered repeatedly in a loop.
---
Description:
s390/pci: Handle PCI error codes other than 0x3a
Symptom:
When hardware reports some error other than the generic 0x3a for a PCI device
it is left in a "frozen" state to be recovered manually.
Problem:
This requires manual intervention in some error scenarios.
Reproduction:
Inject errors - either through instrumented kernel code, or through HW inject
methods.
Solution:
Attempt the same PCI auto-recovery for these errors, if the respective device
driver supports that.
Upstream-ID: 3cd03ea57e8e16cc78cc357d5e9f26078426f236
Upstream-Description:
s390/pci: Handle PCI error codes other than 0x3a
The Linux implementation of PCI error recovery for s390 was based on the
understanding that firmware error recovery is a two step process with an
optional initial error event to indicate the cause of the error if known
followed by either error event 0x3A (Success) or 0x3B (Failure) to
indicate whether firmware was able to recover. While this has been the
case in testing and the error cases seen in the wild it turns out this
is not correct. Instead firmware only generates 0x3A for some error and
service scenarios and expects the OS to perform recovery for all PCI
events codes except for those indicating permanent error (0x3B, 0x40)
and those indicating errors on the function measurement block (0x2A,
0x2B, 0x2C). Align Linux behavior with these expectations.
Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery")
Reviewed-by: Gerd Bayer <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
** Changed in: ubuntu-z-systems
Status: Triaged => In Progress
** Changed in: linux (Ubuntu Jammy)
Status: Triaged => In Progress
--
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/2120344
Title:
[UBUNTU 22.04] s390/pci: Handle PCI error codes other than 0x3a
Status in Ubuntu on IBM z Systems:
In Progress
Status in linux package in Ubuntu:
Invalid
Status in linux source package in Jammy:
In Progress
Status in linux source package in Noble:
Invalid
Status in linux source package in Plucky:
Invalid
Status in linux source package in Questing:
Invalid
Bug description:
[ Impact ]
s390/pci: Handle PCI error codes other than 0x3a
The Linux implementation of PCI error recovery for s390 was based on the
understanding that firmware error recovery is a two step process with an
optional initial error event to indicate the cause of the error if known
followed by either error event 0x3A (Success) or 0x3B (Failure) to
indicate whether firmware was able to recover. While this has been the
case in testing and the error cases seen in the wild it turns out this
is not correct. Instead firmware only generates 0x3A for some error and
service scenarios and expects the OS to perform recovery for all PCI
events codes except for those indicating permanent error (0x3B, 0x40)
and those indicating errors on the function measurement block (0x2A,
0x2B, 0x2C). Align Linux behavior with these expectations.
[ Fix ]
Backport the following commit from upstream:
- 3cd03ea57e8e s390/pci: Handle PCI error codes other than 0x3a
[ Test Plan ]
Boot the kernel on an IBM Z system with PCI devices bound to drivers that
support error recovery and inject different PCI error codes.
For recoverable errors, check that the device auto-recovers and remains
usable.
For 0x2A–0x2C errors, verify they are ignored with no impact.
For permanent failure codes (0x3B, 0x40), confirm the device is correctly
marked as failed.
Use dmesg to validate that recovery paths are triggered as expected and that
unaffected devices continue normal operation.
[ Regression Potential ]
The fix affects how the s390 PCI error handler interprets and reacts to PCI
event codes. A bug here could cause error codes to be misclassified, leading to
incorrect recovery actions.
Users may see devices being driven into recovery even for irrelevant events,
devices left permanently failed when they should have recovered, or recovery
attempts being triggered repeatedly in a loop.
---
Description:
s390/pci: Handle PCI error codes other than 0x3a
Symptom:
When hardware reports some error other than the generic 0x3a for a PCI device
it is left in a "frozen" state to be recovered manually.
Problem:
This requires manual intervention in some error scenarios.
Reproduction:
Inject errors - either through instrumented kernel code, or through HW inject
methods.
Solution:
Attempt the same PCI auto-recovery for these errors, if the respective device
driver supports that.
Upstream-ID: 3cd03ea57e8e16cc78cc357d5e9f26078426f236
Upstream-Description:
s390/pci: Handle PCI error codes other than 0x3a
The Linux implementation of PCI error recovery for s390 was based on the
understanding that firmware error recovery is a two step process with an
optional initial error event to indicate the cause of the error if known
followed by either error event 0x3A (Success) or 0x3B (Failure) to
indicate whether firmware was able to recover. While this has been the
case in testing and the error cases seen in the wild it turns out this
is not correct. Instead firmware only generates 0x3A for some error and
service scenarios and expects the OS to perform recovery for all PCI
events codes except for those indicating permanent error (0x3B, 0x40)
and those indicating errors on the function measurement block (0x2A,
0x2B, 0x2C). Align Linux behavior with these expectations.
Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery")
Reviewed-by: Gerd Bayer <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Signed-off-by: Heiko Carstens <[email protected]>
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2120344/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
