randomparity / randomparity/kdive
Verify the IPMI diagnostic interrupt and watchdog pre-timeout NMI on crashable x86 hardware
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 1h 26m
- Merged PRs (30d)
- 311
Description
Follow-on from the x86 half of #1816. Directly gates the decision in #1842 and the scope of #1821.
## Question
Redfish on a real AMI MegaRAC / AST2600 BMC advertises no `Nmi` reset type (#1842). Does **IPMI**
provide the OOB crash trigger that Redfish does not?
Two candidate mechanisms, both present in the protocol and both unverified:
1. **`ipmitool chassis power diag`** — Chassis Control (NetFn Chassis, cmd `0x02`) option `0x04`,
"pulse diagnostic interrupt". Optional in IPMI 2.0; an unsupported BMC returns a completion code
rather than acting.
2. **Watchdog pre-timeout interrupt** — `ipmitool mc watchdog get` on the surveyed BMC returns a
populated `Pre-timeout interrupt` field (currently `None`). IPMI defines NMI/diagnostic interrupt
as one of its settable values.
## Why it could not be answered by the survey
The surveyed host is a **production Proxmox hypervisor**. Both mechanisms are fire-only: there is no
capability query that reports support without performing the action, and arming a watchdog risks an
unattended reset. Neither was issued.
Supporting evidence that the platform path exists, short of proof:
- `ipmitool chassis status` reports `Diag Button Disabled: false` — the platform's diagnostic/NMI
button path is enabled.
- The SDR exposes a `WATCHDOG2` sensor.
- `mc info` confirms IPMI 2.0 with Chassis Device support.
## What to do
On an x86 host with a BMC that we are permitted to crash:
1. Boot a kernel configured to panic on NMI (`kernel.panic_on_unrecovered_nmi`/`unknown_nmi_panic`)
with kdump armed.
2. Issue `chassis power diag` over IPMI LAN. Record the completion code and whether the guest
panics.
3. Independently, set a short watchdog with `Pre-timeout interrupt: NMI` and confirm whether the
pre-timeout fires an NMI rather than a reset.
4. Record whether a **vmcore survives** in each case — an NMI that panics but leaves no readable
vmcore does not answer the need.
## Why this is P1
It decides whether #1821 (the IPMI driver, currently scoped as "a second driver for BMCs predating
Redfish") is optional or is the **only** OOB force-crash path on x86. That is a materially different
position in epic #1814's dependency graph.
## Non-goals
Not to be attempted on `gamera` or any other production host.
Contributor guide
Research direction
No repository files or tests are named. Start by preparing an explicitly permitted, crashable x86 host with kdump and the specified panic settings, then run the two documented ipmitool procedures independently. Record completion codes, panic behavior, and whether a readable vmcore survives; do not use gamera or production hosts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- infrastructure, operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100