RUNTIME OBSERVATIONS (audit guest, kernel #2 with ncr claiming QEMU lsi53c895a)

1. ncr0 attaches to the emulated 53C895A (ncr.c:3355 ncr_attach runs to
   completion; ncr_snooptest passes).

2. CAM bus scan drives XPT_SCSI_IO through ncr_action (ncr.c:3852):
   12 selection attempts complete via the HS_RESET path
   ("(probeNN:ncr0:0:N:0): COMMAND FAILED (6 ff)"), the LUN probe CCBs
   for existing targets stall in the start queue.

3. THE DAEMON PATH IS LIVE: ncr_timeout (ncr.c:5101) fires every ~1s
   and completes the stalled CCBs — 90+ "ncr0: timeout nccb=... (skip)"
   lines during the session, re-armable from userland via
   `camcontrol rescan 2` (which then blocks forever on the retry cycle).
   These completions are the launch==select (never-selected) variant;
   the fix.diff's protected variant (chip still connected, DSA armed)
   cannot be produced because the QEMU lsi target never stalls mid-phase
   on demand — the emulated device answers instantly or not at all.

4. Trigger binary builds clean on the guest:
     $ cc -O2 -o ncr_timeout_race ncr_timeout_race.c -lcam
   but cannot be aimed at a pass(4) device: no INQUIRY completes through
   the chip on the emulator, so no pass/da node ever appears on scbus2.
   On real hardware (or a programmable target), ./ncr_timeout_race passN
   with 1 ms timeouts against a stalling target drives the exact window:
   timeout daemon completes the connected nccb (ncr.c:5148-5182), then
   the target's phase change hits ncr_int_ma (ncr.c:5640) with a dead
   nccb found by DSA match (ncr.c:5692-5707, mismatch-return commented
   out) -> chip wedged (ncr.c:5775-5782) or stale-scatter patch +
   restart (ncr.c:5798-5828).

CONCLUSION: every host-side element of the race verified live except the
hardware-side choreography (stall past tlimit, then resume), which the
emulator cannot perform. Honest status: inconclusive (source-certain,
runtime window not enterable with stock QEMU devices).