** Description changed:
[Impact]
rasdaemon provides a ras-mc-ctl, a tool for querying the rasdaemon database.
When displaying PCIe AER events from the
database, it doesn't provide any information to identify the associated PCIe
device. This information is already stored in the database (has been since
0.6.5 in focal), so we just need to update ras-mc-ctl to display it as well.
[Test Case]
+ - Trigger an AER event (how to do so appears to be pretty platform-specific).
+ - Check for the Bus/device/function info in the output of ras-mc-ctl.
[Fix]
https://github.com/mchehab/rasdaemon/commit/059a901e97f4091e31c50ce55027daf707638f8d
[Regression Risk]
+ The change here adds additional content to the output of ras-mc-ctl. Instead
of something like this:
+
+ PCIe AER events:
+ 1 2020-04-16 22:09:48 +0000 Corrected error: Receiver Error
+ 2 2020-04-16 22:23:24 +0000 Corrected error: Receiver Error
+
+ You'll now see something like this:
+ PCIe AER events:
+ 1 2020-04-16 22:09:48 +0000 0000:0b:00.0 Corrected error: Receiver Error
+ 2 2020-04-16 22:23:24 +0000 0000:0b:00.0 Corrected error: Receiver Error
+
+ As with any such unstructured output, it's possible that a user has some
+ code to parse the output that would be confused by the additional
+ content.
** Changed in: rasdaemon (Ubuntu Focal)
Status: New => In Progress
** Changed in: rasdaemon (Ubuntu Focal)
Assignee: (unassigned) => dann frazier (dannf)
** Description changed:
[Impact]
- rasdaemon provides a ras-mc-ctl, a tool for querying the rasdaemon database.
When displaying PCIe AER events from the
- database, it doesn't provide any information to identify the associated PCIe
device. This information is already stored in the database (has been since
0.6.5 in focal), so we just need to update ras-mc-ctl to display it as well.
+ rasdaemon provides ras-mc-ctl, a script for querying the rasdaemon database.
When displaying PCIe AER events from the
+ database, it doesn't provide any information to identify the associated PCIe
device. Knowing that some hardware is reporting errors, but not knowing what
hardware that is, isn't terribly helpful.
+
+ This information is already stored in the database (has been since 0.6.5
+ in focal), so we just need to update ras-mc-ctl to display it as well.
[Test Case]
- - Trigger an AER event (how to do so appears to be pretty platform-specific).
- - Check for the Bus/device/function info in the output of ras-mc-ctl.
+ - Trigger an AER event (how to do so appears to be pretty platform-specific).
+ - Check for the Bus/device/function info in the output of ras-mc-ctl.
[Fix]
https://github.com/mchehab/rasdaemon/commit/059a901e97f4091e31c50ce55027daf707638f8d
[Regression Risk]
The change here adds additional content to the output of ras-mc-ctl. Instead
of something like this:
PCIe AER events:
1 2020-04-16 22:09:48 +0000 Corrected error: Receiver Error
2 2020-04-16 22:23:24 +0000 Corrected error: Receiver Error
You'll now see something like this:
PCIe AER events:
1 2020-04-16 22:09:48 +0000 0000:0b:00.0 Corrected error: Receiver Error
2 2020-04-16 22:23:24 +0000 0000:0b:00.0 Corrected error: Receiver Error
As with any such unstructured output, it's possible that a user has some
code to parse the output that would be confused by the additional
content.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1888423
Title:
ras-mc-ctl doesn't provide BDF for PCIe errors
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rasdaemon/+bug/1888423/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
