# DF-4737 — amdpm_wait() off-by-one (silent SMBus timeout / spurious last-poll failure)

File: `sys/dev/powermng/amdpm/amdpm.c` (pass-2 GLM 5.3 re-audit)
Sibling of DF-4549 (viapm.c, same `while(count--)` / `if (!count)` defect family).

## Build

On the audit QEMU guest (DragonFly 6.5-DEVELOPMENT, cc 8.3):

    cc -Wall -Wextra -o /tmp/df4737 /tmp/df4737.c

(`amdpm_wait_offbyone_demo.c` transferred to the guest first — see build.sh)

## Run

    /tmp/df4737

## Expected output (decisive lines)

    A  clear_on_read=0     polls=10000  error=0x0    NO-TIMEOUT
       -> genuine timeout (controller never clears HST_STS) reported as
          SMB_ENOERR; amdpm_recvb/readb/readw/bread then return stale
          HSTDATA/FIFO bytes as a SUCCESSFUL transfer
    B  clear_on_read=10000 polls=10000  error=0x20   TIMEOUT-REPORTED
       -> transfer that completes on the final (10000th) poll is spuriously
          reported SMB_ETIMEOUT
    bugs demonstrated in buggy loop: 2   (exit 0)

The demo's "fixed loop" section re-runs A and B against the one-line fix
(`if (count < 0)`) and shows both cases behave correctly.

## Why a userspace replica

The in-kernel path is hardware-gated: `amdpm(4)` attaches only to AMD
756/766/768/8111 PMU (1022:740b/7413/7443/746b) or nForce SMBus
(10de:01b4) PCI devices; the QEMU audit guest has none (guest_hw_evidence.txt:
`kldload amdpm` succeeds, attaches nothing, no /dev/smb*). The loop is
pure C semantics, so a verbatim replica of `amdpm_wait()`'s control flow
with a fixture register read proves the defect deterministically. Same
method as the accepted DF-4549 evidence pack.