# DF-4867 VERDICT — not_reproduced (latent; path traced dead on this tree)

## Bottom line

The fragile error-contract at `ata-intel.c:177-180` is real and certain in shape, but
it is **not reachable as a bug on this tree today**: `ata_ahci_chipinit()` can only
return `0` or `ENXIO`, so the `!= ENXIO` test never mistakes a failure for success.
No runtime manifestation is possible, hence `not_reproduced` / impact `none`. The
finding is filed as hardening: the guard is one refactor away from a boot-time NULL
function-pointer call, because `ata_ahci_chipinit()` propagates
`ata_ahci_ctlr_reset()`'s error **verbatim** (`return (error);` at ata-ahci.c:97)
and that callee's return set is not enforced by any contract.

## Line-level trace

1. `sys/dev/disk/nata/chipsets/ata-intel.c:177-180`
   ```c
   if ((ctlr->chip->cfg1 == INTEL_AHCI) &&
       (pci_read_config(dev, 0x90, 1) & 0xc0) &&
       (ata_ahci_chipinit(dev) != ENXIO))
       return 0;
   ```
   Entering the SATA branch requires `chip->max_dma >= ATA_SA150` (ata-intel.c:159/166),
   i.e. cfg1==INTEL_AHCI entries only (ICH6+ AHCI/RAID SKUs, ata-intel.c:71-112).
   Requires config 0x90 bits 0xc0 set (BIOS AHCI/RAID mode).

2. `ata_ahci_chipinit()` return paths (sys/dev/disk/nata/chipsets/ata-ahci.c):
   - :80-82 BAR(5) MEMORY alloc fails → `ENXIO`
   - :85-89 `ata_setup_interrupt` fails → `ENXIO`
   - :95-98 `ata_ahci_ctlr_reset()` != 0 → `return (error)` — **any error code propagates**
   - :121 success → `0` (only here are `ctlr->channels/:105-108 setmode` etc. assigned)
   `ata_ahci_ctlr_reset()` (:124-159) currently returns only `ENXIO` (:141) or `0` (:159).

3. If a non-ENXIO error ever propagated: `ata_intel_chipinit` returns 0 at :180 with
   `ctlr->setmode == NULL` — the compat block at :182-189 (`ctlr->setmode = ata_intel_sata_setmode`
   or `ata_sata_setmode`) is skipped, and the AHCI block never assigned it.

4. Sink: `ata_pcichannel_setmode()` ata-pci.c:857-866 calls
   `ctlr->setmode(dev, ATA_PIO_MAX)` (:863) unconditionally via the `ata_setmode`
   bus method, invoked from ata-all.c:525 and ata-disk.c:436 during channel/device
   attach → NULL function pointer call → panic while attaching the disk subsystem.

## Why not reproducible on this guest / tree

- Hardware path: requires an ICH6+ Intel SATA controller with cfg1==INTEL_AHCI,
  BIOS mode bits 0x90&0xc0, and an AHCI controller-reset failure returning non-ENXIO.
- Source path: with the current tree, `ata_ahci_chipinit` ∈ {0, ENXIO} at every exit
  (verified by exhaustively reading all four return sites), so the `!= ENXIO` guard
  never misfires. There is no way to make `ata_ahci_ctlr_reset` return a third value
  without editing sys/ (read-only for this audit).
- Guest (QEMU PIIX3, see env.txt) has no AHCI-capable Intel SATA part at all: the
  boot path is the *non-SATA* branch (ata-intel.c:159-163), which always assigns
  `ctlr->setmode = ata_intel_new_setmode`.

## What WAS live-verified (negative evidence for this file's boot path)

The guest boots on `atapci0: <Intel PIIX3 WDMA2 controller>` (chip 0x70108086 =
`ATA_I82371SB`, ata-intel.c:51 → `ata_intel_chipinit` → non-SATA branch, channels=2,
`ata_intel_allocate`, `ata_intel_new_setmode`):

- dmesg.txt: `atapci0`, `ata0`, `ata1`, `acd0 ... WDMA2` — the setmode callback ran
  at attach and indexed `timings[ata_mode2idx(WDMA2)]` = `timings[7]` (in-bounds,
  table has 15 entries) with no anomaly.
- env.txt: PCI config dword at 0x54 = 0x00000400 — exactly the vendor-specific bit
  `reg54 |= 0x0400` written by `ata_intel_new_setmode` (ata-intel.c:310). Direct
  register-level proof the audited function executed on this boot.
- Guest healthy throughout; no panic; guest not dirtied.

## Fix validation

Not applicable (nothing to make fail on the baseline). The one-line `fix.diff`
(`!= ENXIO` → `== 0`) is trivially semantics-preserving for every return value the
callee can produce today and closes the contract hole for any future error code.

## 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.