oxidecomputer / oxidecomputer/omicron
Feature Request: Identify "missing/moving DIMMs" in FM
Open
@mergeconflict is already working on this.
Since Jul 9, 2026.
fault-management
- Dominant language
- Rust
- Stars
- 572
- Forks
- 97
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 96
Description
See also: #10669
This issue tracks the FM system identifying the following condition: "You have a DIMM, which you expected to be present in a control plane sled, but it is not alive anymore".
We're going to need to complete a couple sub-objectives to finish this work:
- We must be able to identify an "intended configuration" for system hardware. For DIMMs, this can be resolved with a "watermark" system on control plane sleds. In other words: create a system to record when a DIMM has been seen within the system at least once, flag it as problematic if that DIMM no longer appears within the topology of a sled.
- We'll need to rule out false-positive signals - e.g. , "Sled not present", which could happen during reboot
- We'll need to access additional libtopo information to infer: "is a DIMM present in a slot". Additionally, we'll need to add information about DIMMs to inventory, regarding "what is their identity" and "where are the DIMMs currently attached".
- We may want a layer of post-processing via CRDB tables on the Nexus inventory system, identifying edge-triggered changed between inventory collections for a particular disk. This CRDB table could identify: "for a given DIMM (vendor, serial, model), where has it been physically attached to the system (by sled + slot)"? This history information could help us identify when a DIMM has moved.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.