# DF-4101 — Stale bttimeout fires BDR/hard-reset on a recycled CCB

## Verdict: REPRODUCED (deterministic choreography of the exact race)

Rig class as DF-2429 (see DF-2429/README.md).

## Build

    ./push_rig.sh

## Run

    sh run1.sh       # DF-4101 is the third section

## Choreography (mirrors the production race window)

1. `queue io` ccb-A (healthy, 60 s timeout) → ACTIVE (`flags=0x1`).
2. `hold` — the ioctl thread takes `bt->lock` (the lock bttimeout
   acquires at bt.c:2143).
3. `racefire 3` — a kthread calls the **production** `bttimeout(bccb)`
   and blocks acquiring the lock: this is the in-progress callout
   invocation that `callout_stop` at bt.c:1449 cannot cancel.
4. Under the lock: `comp 3` completes ccb-A (BMBI_OK; the callout_stop
   inside btdone is a no-op against the blocked handler) and `queue io`
   ccb-B — production `btgetccb` hands out the **same BCCB**
   (`bccb_kva` identical), which `btaction` marks ACTIVE again with a
   fresh 60 s timer.
5. `rel` — the stale `bttimeout` acquires the lock and proceeds against
   ccb-B.

## Expected output (run.log)

- After `rel`: ccb-B `flags=0x7` (DEVICE_RESET set **by the stale
  handler**), `timer=1` (stale handler's 2s re-arm), console
  `CCB 0xfffff801167df620 - timed out` — printed for a command whose
  own 60 s timer never expired.  ccb-A meanwhile completed
  CAM_REQ_CMP (`comp=1`, `last_status=0x1`).
- 2 s later: the stale handler's re-arm fires the hard-reset branch —
  `vhba_hard_resets` increments (1→2; the extra hard reset on a
  healthy bus), and ccb-B completes `ccb_status=0xb`
  (CAM_CMD_TIMEOUT) — a healthy command misreported as timed out.

The lock choreography makes the production race window deterministic;
every step except the timing is genuine production code.