randomparity / randomparity/kdive

Verify the IPMI diagnostic interrupt and watchdog pre-timeout NMI on crashable x86 hardware

Open
#1,843 0 comments 0 reactions 0 assignees View on GitHub
area:control-retrieve effort:S priority:P1 provider:baremetal-bmc risk:daytime-only status:needs-human type:test
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.