# DF-4097 — XPT_RESET_DEV clobbered into a malformed opcode-0 CCB

## Verdict: REPRODUCED (clobber observed live + terminal kernel panic)

Same rig class as DF-2429 (see DF-2429/README.md): the REAL production
`btaction`/`btdone`, dispatched through the real CAM XPT layer
(`xpt_action`) over a fabricated post-attach softc.

## Build

    ./push_rig.sh

## Run

    sh run_clean.sh    # non-panicking half: the clobber observation
    sh run_panic.sh    # panicking half: firmware rejection -> btdone panic

## Expected output

1. `queue io` (control): post-dispatch hccb snapshot `op=0x00 cmd_len=6`
   — a normal no-data TUR.
2. `queue rst` (XPT_RESET_DEV through the same production path):
   post-dispatch hccb snapshot `op=0x00 cmd_len=0 sense_len=0` — the
   INITIATOR_BUS_DEV_RESET (0x81) that btaction stored at bt.c:1062 was
   overwritten with INITIATOR_CCB (0x00) by btexecuteccb's unconditional
   nseg==0 path (bt.c:1285).  The adapter is handed a reset request
   encoded as an ordinary CCB with a zero-length CDB.
3. Panic run: the virtual firmware rejects that malformed CCB the way
   conforming MultiMaster firmware does — completion BMBI_ERROR with
   btstat=BTSTAT_INVALID_OPCODE (0x16) written into the CCB — and
   production btdone panics: `panic: bt9: Invalid CCB Opcode code`
   (bt.c:1520), full backtrace in panic.txt.