oxidecomputer / oxidecomputer/hubris

Ereports for hotswap fan presence changes

Open
#2,606 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

⚠️ ereport fault-management
Dominant language
Rust
Stars
3.6k
Forks
239
Avg merge
1d 12h
Merged PRs (30d)
23

Description

We should be producing an ereport when a hot-swappable fan module is inserted or removed. This is definitely something we should be doing on Sidecar, where the fans are actually hot-swappable...and, if it's easy to also do on Gimlet/Cosmo, we may want to do something there too; fans are not hot swappable on compute sleds, but if we see something that looks like a fan tray going away while the system is up, that is probably also worth saying something about...

I would expect these ereports to be in the hw.insert.fan and hw.remove.fan ereport classes, similar to the existing ones for PSU insert/remove events. Unlike the PSU ones, these, of course, won't have a power rail, but we may want to include the refdes of the fan connector (?) as long as a fan slot, and we will definitely want to also include the fan's part number/revision/serial from its VPD EEPROM.

I'm not totally sure off the top of my head where the easiest place in Hubris to actually detect fan presence changes.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with drv/psc-seq-server/src/main.rs around the existing PSU insert/remove ereports linked in the issue, then trace where Hubris detects fan presence changes on Sidecar. Determine how fan-slot and VPD EEPROM data are represented before defining the hw.insert.fan and hw.remove.fan payloads. Done means the relevant fan events emit those ereports with the required part number, revision, and serial data; Gimlet/Cosmo support is optional if straightforward.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
embedded-iot
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.