fix(bios): wire numa_nps into the guided walk and verify pass - #285
Merged
Conversation
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
VijitSingh97
enabled auto-merge (squash)
July 17, 2026 03:17
This was referenced Jul 17, 2026
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.
Summary
_bios_detecthas detected and persisted anuma_npsitem since #201, but_bios_guideand_bios_verifynever wired it up:_bios_guide's pending-items loop only iteratedmemory_profile smt power_boost, so a pending NPS item never rendered in the guided walk, and could make the "Everything's already set" early-out fire while an EPYC rig was still sitting at NPS1._bios_verify's per-itemcasehad nonuma_npsarm, so it hit*) continue— a savednuma_nps: pendingitem was silently dropped from both the applied and still-pending columns, and the state file was deleted (or a false "All BIOS items applied" printed) even though nothing was verified.This fixes both spots:
numa_npsto_bios_guide's walk list, with a status line (ok/pending) mirroring the wording of doctor's NPS advisory (doctor/bios: detect NPS1 on EPYC — flag a NUMA-per-socket regression (detectable, currently silent) #201) — same target mode (NPS4) and "quadrant-local memory" phrasing.numa_npsarm to_bios_verifythat re-runs the same_nps_suspect-backed detection_bios_detectuses, and classifies the item as applied (NPS4 seen) or still pending, consistent with how the other three items verify — including the kept/rewrite bookkeeping so a NPS item that did take doesn't get carried forward into the resaved state.The "Everything's already set" early-out was already correct once NPS participates in the same pending-list loop as the other three items — it fires only when the loop builds an empty pending list across all four.
Tests
Added the three tests called out in the issue, next to the existing
_biostests intests/run.sh(reusing the$NPS/one/$NPS/fournode-count fixtures from the existing #201 detection tests):numa_npspending → the NPS step renders, "Everything's already set" does not fire.numa_nps: pendingin state and detection still reporting NPS1 → stays pending, no "All BIOS items applied", state file survives.make test(shellcheck + shfmt + the full suite): 1348 passed, 0 failed. Confirmed all 3 new test blocks (7 of 9 assertions) go red against the unfixed code before re-applying the fix.Closes #268
🤖 Generated with Claude Code