Fix/sel event data selector bits#56
Merged
datdenkikniet merged 1 commit intoJul 10, 2026
Merged
Conversation
IPMI encodes the format and availability selectors for Event Data 2 and Event Data 3 in Event Data 1. The decoder assigned those selector fields in reverse: it read bits [5:4] for Event Data 2 and bits [7:6] for Event Data 3. This issue was noticed while decoding Lenovo SEL entries. Those records exposed standard System Firmware Progress extension values that disappeared during EventData parsing, leading to the selector-bit mismatch. IPMI v2.0 revision 1.1, section 29.7, Table 29-6 defines the opposite layout for both threshold and discrete events: bits [7:6] describe Event Data 2, while bits [5:4] describe Event Data 3. Swap the shifts used by EventData::parse and update the API documentation to match the normative table. The reversal loses valid sensor-specific extension data whenever the two selectors differ. A standard System Firmware Progress record with event bytes C2 13 FF demonstrates the problem. Per Table 29-6, C2 means that Event Data 2 carries a sensor-specific extension and Event Data 3 is unspecified. Per Table 42-3, sensor type 0Fh, offset 02h, extension 13h means Starting operating system boot process. The old decoder instead treated Event Data 2 as unspecified, interpreted FF as Event Data 3, and consequently discarded 13h. The existing 59 42 50 test did not expose the reversal because both selector fields in 59h are 01b. Add asymmetric regression tests for C2 13 FF and for the inverse Data-3-only selector layout 32 FF 23. These independently pin each selector to its correct bit field and prevent a future swap from passing accidentally. Normative reference: Intelligent Platform Management Interface Specification, Second Generation, v2.0 revision 1.1, section 29.7 Table 29-6 and section 42 Table 42-3: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf Concrete firmware-progress encoding examples: Oracle documents Event Data 2 value 13h for Starting operating system boot process: https://docs.oracle.com/cd/E19121-01/sf.v20z/817-5249-17/chapter2.html NVIDIA shows an ipmitool SEL record with Event Data c213ff decoded as System boot initiated: https://docs.nvidia.com/networking/display/bluefieldbsp453/logging fix(doc): remove misleading power supply test heading Remove a stale Rustdoc comment that describes the generic EventData test module as a Power Supply sensor-specific decoder. The comment was introduced with the original event-data implementation in 8439308, directly above #[cfg(test)] mod tests. Git history shows that no Power Supply decoder was removed from or moved away from this location; the documented item has always been the test module. Keeping the heading causes generated documentation and source readers to infer that a Sensor Type 08h decoder exists here when the module only contains generic EventData parsing tests. Remove the inaccurate heading separately from the selector-bit behavior fix. Reference: IPMI 2.0 revision 1.1, Table 42-3 defines Sensor Type 08h as Power Supply, but this module does not implement a dedicated decoder for it: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
datdenkikniet
force-pushed
the
fix/sel-event-data-selector-bits
branch
from
July 10, 2026 19:17
06526d7 to
9c6782d
Compare
datdenkikniet
approved these changes
Jul 10, 2026
datdenkikniet
left a comment
datdenkikniet
left a comment
Owner
There was a problem hiding this comment.
Good catch!
Yeah, stuff like this is hard to get right. Thank you for being willing to submit fixes :)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
My mistake, IPMI docs quite hard to read and easy to misinterpret, and seems best way to detect such mistakes to test it on various hardware and improve in process.
IPMI encodes the format and availability selectors for Event Data 2 and Event Data 3 in Event Data 1. The decoder assigned those selector fields in reverse: it read bits [5:4] for Event Data 2 and bits [7:6] for Event Data 3.