# DF-4099 — Unknown mailbox comp_code leaks the BCCB and CAM command forever

## Verdict: REPRODUCED (permanent leak + bus-wide wedge)

Rig class as DF-2429 (production handlers, real XPT dispatch, virtual
firmware writing completion mailboxes — see DF-2429/README.md).

## Build

    ./push_rig.sh

## Run

    sh run1.sh       # DF-4099 is the final section

## Expected output (run.log)

After `queuein` (CAM_DIR_IN, 512 bytes, real dmamap) and a completion
with the unknown comp_code 0x42 delivered to production `btdone`:

```
[snap] id=5 bccb=... flags=0x1 (BCCB_ACTIVE) ccb_status=0x200
       (CAM_SIM_QUEUED) on_pending=1 timer=0 comp=0 map=1
```

three seconds later — and forever after:

- `flags=0x1`: the BCCB is still marked ACTIVE,
- `on_pending=1`: still on `bt->pending_ccbs`,
- `timer=0`: its callout was stopped at bt.c:1449 and is never re-armed,
- `comp=0`: no CAM completion callback ever fires,
- `ccb_status=0x200` (CAM_SIM_QUEUED): the client command hangs forever.

Repeating for every BCCB on the adapter leaks all of them
(`active=11 pending=11` captured; exhaustion of the remaining slots)
and the next `queue io` is CAM_REQUEUE_REQ'd (`bccb=0x0`, btgetccb
NULL → resource_shortage + simq frozen): all I/O on the bus wedges.

## Honest correction

The finding's "dmamap stays loaded" detail is wrong in one respect:
`bus_dmamap_sync`/`bus_dmamap_unload` (bt.c:1395-1404) execute BEFORE
the comp_code switch, so a DIR_IN CCB's map is unloaded even on the
fall-through path.  The leak that matters — BCCB never freed, CAM
command never completed, timeout already stopped — is fully reproduced.