DF-4100 — Recovery BCCB never BCCB_ACTIVE: BDR recovery branch is dead code

Verdict: REPRODUCED (dead branch + guaranteed hard-reset escalation)

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

Build

./push_rig.sh

Run

sh run1.sh       # DF-4100 is the second section

Expected output (run.log)

1. Production bttimeout() fired on a queued I/O CCB takes the BDR branch: flags=0x7 (ACTIVE|DEVICE_RESET|RELEASE_SIMQ), 2s re-arm (timer=1), recovery BCCB programmed — and rec_flags=0 (BCCB_FREE, never ACTIVE; the only writer of BCCB_ACTIVE is bt.c:1302 in btexecuteccb, which the recovery BCCB never transits).
2. The firmware completes the BDR mailbox (BMBI_OK) → production btdone hits the guard first — console: unknown: btdone - Attempt to free non-active BCCB 0xfffff801167df690 (f690 == the recovery BCCB) — and returns. async_bdr=0: the AC_SENT_BDR notification the recovery branch would send never fires; the pending CCB's timer stays stopped (timeouts are never reinstated); the SIM queue stays frozen.
3. 2s later the re-armed timer fires bttimeout again → BCCB_DEVICE_RESET set → hard-reset branch: the virtual HBA observes the driver write HARD_RESET (0x80) to CONTROL_REG (vhba_hard_resets=1, last_ctl=128), btreset runs to completion, and the timed-out CCB completes CAM_CMD_TIMEOUT (ccb_status=0xb).

Conclusion: targeted device recovery can never work; a single hung command guarantees a full hard bus reset 2 seconds later, disrupting I/O to every target on the bus.

DF-4100 VERDICT — recovery BCCB never marked ACTIVE; BDR branch dead

Bottom line

REPRODUCED end-to-end on the production handlers.

1. Dead branch: bttimeout's BDR branch (bt.c:2214-2230) arms bt->recovery_bccb without ever setting BCCB_ACTIVE on it. Live snapshot at arm time: rec_flags=0 (BCCB_FREE). When the adapter completes the BDR mailbox, production btdone evaluates the guard at bt.c:1388 first and bails: unknown: btdone - Attempt to free non-active BCCB 0xfffff801167df690 (f690 is the recovery BCCB). The recovery branch at bt.c:1406-1447 is unreachable — proven by three independent observables: the guard message printed, async_bdr == 0 (AC_SENT_BDR, which only that branch sends, never fired), and the pending CCB's timeouts were never reinstated (bt.c:1439-1441).
2. Guaranteed escalation: with the recovery branch dead, the 2s re-armed timer from bt.c:2215 fires bttimeout again; BCCB_DEVICE_ RESET is now set, so bt.c:2183-2200 takes the full hard-reset branch. The virtual HBA observed the production driver write HARD_RESET (0x80) to CONTROL_REG (vhba_hard_resets=1, vhba_last_ctl=128), btreset(hard) completed, and the timed-out CCB finished with ccb_status=0xb (CAM_CMD_TIMEOUT). Console: two CCB ... - timed out lines and No longer in timeout (the hard-branch message).

So every command timeout on real bt(4) hardware escalates to a bus-wide hard reset 2 seconds later (freezing the SIM queue for that period), disrupting I/O to every target — targeted BDR recovery is impossible.

Root cause (path:line)

• bt.c:2214-2230 — BDR arm; no recovery_bccb->flags = BCCB_ACTIVE.
• bt.c:1302 — the only site that sets BCCB_ACTIVE (btexecuteccb), which the recovery BCCB never transits.
• bt.c:1388-1393 — the guard that therefore always rejects the BDR completion.
• bt.c:2215 — the 2s re-arm that guarantees the hard-reset escalation.

Impact

Reliability/DoS: one hung command → 2s frozen SIM queue → full hard bus reset → all targets' I/O disrupted. On real hardware this also converts every recoverable single-device hang into a bus-wide event.

Fix validation

fix.diff sets recovery_bccb->flags = BCCB_ACTIVE when the BDR is armed (bttimeout) and clears it to BCCB_FREE when the recovery branch finishes. Patched bt.c+btreg.h compile clean with the kernel's own flags under -Werror (FIXED-COMPILES-CLEAN). No runtime A/B kernel build (DoS class, not memory corruption; not mandated).

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.