# DF-3952 — Verification Verdict

**Status:** inconclusive (hardware-gated; source-certain)
**Impact demonstrated:** none (expected: kernel panic "MLX: too many s/g segments")
**Confidence:** likely (needs a DAC960 reporting me_max_sg < ~33; code path certain)

## Source proof

- Buffer DMA tag hard-codes nsegments=MLX_NSEG=64 at attach:
  `sys/dev/raid/mlx/mlx.c:363-370` (`bus_dma_tag_create(..., MAXBSIZE,
  MLX_NSEG, ...)`), created *before* ENQUIRY2 runs (mlx.c:395).
- `me_max_sg` is firmware-controlled (`sys/dev/raid/mlx/mlxreg.h:291`,
  u_int16_t inside the DMA'd ENQUIRY2 response).
- The only reconciliation is the panic at `mlx.c:2009-2010` inside the
  `bus_dmamap_load` callback `mlx_setup_dmamap()` — a callback that cannot
  propagate an error, so the driver chose `panic()`.
- Reachable segment counts: MLX_COMMAND allows `mu_datasize` up to MAXPHYS
  (mlx.c:1872-1874); a 128 KB kmalloc buffer maps to up to ~32 segments on
  4 KB pages; disk bios are capped at `(me_max_sg-1)*PAGE_SIZE`
  (mlx_disk.c:262-269) which bounds the ordinary-I/O case — the passthrough
  case is uncapped relative to me_max_sg.
- Historical DAC960 firmware reports me_max_sg of 17/33/65 (Mylex DAC960 PG/
  PJ/PD families) — 17 < 32 ⇒ panic reachable from a stock management ioctl.

Impact: kernel panic = availability only; operator/root gated (0600
root:operator device). Low.

## Guest result

Trigger compile-tested (BUILD_RC=0, DragonFly 6.5-DEVELOPMENT); runtime
ENOENT — no Mylex hardware. Honest: inconclusive.

## Fix validation

fix.diff bounds `mu_datasize` by the firmware budget. Not runtime-testable
here → fix_status: not_testable.

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