# DF-4098 — btdone/btreset panic() on host-adapter-fed bytes

## Verdict: REPRODUCED (two independent panic sites, both captured)

Same rig class as DF-2429 (see DF-2429/README.md): production handlers
resolved from the running kernel image and dispatched over a fabricated
post-attach softc; the virtual firmware writes status bytes into the
CCB DMA memory and the register file exactly as a MultiMaster HBA would.

## Build

    ./push_rig.sh

## Run (each on a fresh boot)

    sh run_panic_btdone.sh    # site 1: btdone btstat panic
    sh run_panic_btreset.sh   # site 2: btreset DIAG_ACTIVE panic

## Expected output

1. `run_panic_btdone.sh`: a perfectly valid I/O CCB (normal TUR,
   cmd_len=6, queued ACTIVE through the real XPT path) is completed by
   the HBA with BMBI_ERROR + btstat=BTSTAT_INVALID_ACTION_CODE (0x15) —
   a single device-fed byte — and production btdone executes
   `panic("bt9: Invalid Action code")` at bt.c:1517 while holding
   bt->lock.  panic_btdone.txt has the backtrace (btdone+0x4d3).
2. `run_panic_btreset.sh`: with the virtual STATUS_REG holding
   DIAG_ACTIVE (0x80) stuck, production btreset(hard) waits 5s for
   diagnostics to start (passes), then 10s for DIAG_ACTIVE to drop,
   and panics at bt.c:1650-1651:
   `panic: bt9: btreset - Diagnostic Active failed to drop. status = 0x80`
   (panic_btreset.txt, btreset+0x266).  ~15s of DELAY polling then panic.