Repository navigation
Read FRU data 255 bytes at a time, halving the count when the controller refuses it - #199
Merged
bertysentry merged 2 commits intoOct 19, 2026
Conversation
…ler refuses it Read FRU Data asked for 16 bytes per round trip, so a 2 KB FRU cost 128 round trips. The first read of a controller now asks for 255 bytes and a refusal (C7h to CAh) halves the count down to 16, the way ipmitool backs off; the count a controller accepts serves its other FRUs. The offset advances by the bytes each reply returns, so the truncation offset in problems() is exact and a controller that returns no data within the size it declared is reported instead of being asked again. ReadFruData accepts a reply with a count of 0 and refuses one shorter than its count instead of failing on the array copy. Live (frus() with the SDR already walked): Lenovo IMM 15.0 s to 1.4 s, Lenovo XCC 8.3 s to 1.6 s, iLO 5 49.8 s to 26.8 s, Supermicro 0.27 s to 0.08 s, same FRUs and records. Supermicro, IMM, GIGABYTE, Fujitsu iRMC and iDRAC 6 answer 255; iLO 5 refuses it with C8h and answers 240; XCC and Dell F200 refuse it with C9h; iDRAC 8, Cisco IMC and F200 answer CAh to anything above 16 and read as before. Closes #102 Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 058a32b75c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…from the count sent A word-addressed FRU device takes its offset in words, so a 255-byte read left the next offset odd and the next read started one byte early. The count is kept even for such a device, but for the last read. The back-off starts from the count actually sent rather than from the chunk size, so a short FRU that is refused is asked again with a smaller count, and a refused tail of 16 bytes or less is a failure rather than a reason to shrink the reads of the next FRUs. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
bertysentry
deleted the
102-fru-reads-are-slow-read-fru-data-is-issued-in-16-byte-chunks
branch
October 19, 2026 17:54
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
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.
Closes #102.
FruReaderasked Read FRU Data for 16 bytes per round trip. The first read of a controller now asks for 255 bytes, and a refusal (C7htoCAh) halves the count down to 16, as ipmitool backs off; the count a controller accepts serves its other FRUs. The offset advances by the bytes each reply returns: the truncation offset inproblems()is exact, and a controller that returns no data within the size it declared is reported (No data returned).ReadFruDataaccepts a reply with a count of 0 and refuses one shorter than its count instead of failing on the array copy.Live probe of Read FRU Data counts (FRU 0, offset 0, one card per vendor): Supermicro, Lenovo IMM, GIGABYTE, Fujitsu iRMC, Dell iDRAC 6 and NetApp HCI answer 255; iLO 5 refuses 255 with
C8hand answers 240; Lenovo XCC and Dell F200 refuse 255 withC9h; iDRAC 8, both Cisco IMCs and the F200 answerCAhto anything above 16.Live
frus(), main vs this branch, SDR already walked, same FRUs and records on both:Unit tests on the fake BMC: a BMC refusing above 32 bytes is read in 32-byte chunks after three refusals, once for both of its FRUs; a refusal at 16 is reported as the FRU's problem; a reply shorter than asked advances by its bytes and an empty one ends the read. Docs:
fru-inventory.mddescribes the read,troubleshooting.mddrops the issue mention,upgrading.mdlists the change.🤖 Generated with Claude Code