# DF-4694 — sili_pm: sili_pm_softreset polls with sili_quick_timeout, whose sole-active KKASSERT is violated when other PM-target commands are still on-chip

## Build & run

```
sh build.sh          # cc -O2 -Wall -o trigger_sili_pm trigger_sili_pm.c
sh run.sh            # ./trigger_sili_pm 15  (camcontrol reset = XPT_RESET_DEV storm)
```

## Expected output

* **On hardware (SiI HBA + PM, several targets active):** `camcontrol reset`
  on a PM target issues XPT_RESET_DEV → sili_cam.c:904-915 →
  `sili_port_reset(ap, atx, 0)` → `sili_pm_softreset()` under the port lock
  **without draining other targets' on-chip commands**. If the softreset FIS
  times out while any other command is still active, `sili_quick_timeout()`
  hits `KKASSERT((ap->ap_active & ~ap->ap_expired) == (1 << ccb->ccb_slot))`
  (sili.c:2537-2538) → **kernel panic** (INVARIANTS is enabled in
  X86_64_GENERIC:56). On non-INVARIANTS builds the assert is compiled out and
  the code clears only its own `ap_active` bit then calls
  `sili_port_reinit()`, force-completing the *other* in-flight commands as
  ATA_S_TIMEOUT — spurious aborts of unrelated I/O.
* **On the audit QEMU guest:** trigger runs, `camcontrol reset 0/1` succeeds
  benignly against the PIIX3 nata buses (run.log) — no sili HBA exists
  (env.txt); hardware gate, not a false positive.

Contrast: `sili_pm_hardreset()` drains with `sili_exclusive_access()` first
(sili_pm.c:272); the softreset path has no equivalent.