# Phase 3 — iter2 baseline measurements (HEVC BEFORE-state) Captured 2026-05-16 10:42 CEST. Anchors what the kernel + backend currently do (and DON'T do) for HEVC, against which Phase 7 will verify the iter2 patch produces the predicted delta. iter2 inherits the ampere-fourier iter1 baseline for the 3 working codecs (H.264 / VP8 / MPEG-2) as **reference history**. iter2 Phase 3 captures one additional artefact: the HEVC OOPS reproducer instrumented with strace, so we know exactly which ioctls (and how many) the current backend issues before the kernel wedges. ## HEVC OOPS reproducer (iter2 BEFORE-state) System state at capture: - ampere uptime 1:24 (post-SDDM-auto-login restart; no stale wedge) - Backend `/usr/lib/dri/v4l2_request_drv_video.so` md5 `0c9a7efaab…` (the hand-built `7ac934e` from ampere-fourier iter1) - dmesg pre-capture: clean (last kernel msg from 10:36, devfreq frequency-update warning unrelated to media) - Kernel `7.0.0-rc3-devices+`, unchanged from iter1 Invocation (with strace per-thread capture): ```sh strace -ff -e trace=ioctl -o /tmp/iter2_before.strace \ -- env LIBVA_DRIVER_NAME=v4l2_request \ timeout 8 ffmpeg -hide_banner -loglevel error \ -hwaccel vaapi -hwaccel_output_format vaapi \ -i ~/measurements/encoded/bbb_60s_720p.hevc.mp4 \ -vf "hwdownload,format=nv12" -frames:v 5 -f null - ``` Outcome: ffmpeg hangs after submitting first request → `timeout 8` SIGTERM doesn't take effect (kernel m2m wedged) → manual `kill -9` of strace + ffmpeg required. ## ioctl pattern (24 strace files per ffmpeg, aggregated) ``` 84 VIDIOC_ENUM_FMT 40 VIDIOC_QUERYBUF 4 VIDIOC_S_EXT_CTRLS 3 VIDIOC_G_FMT 2 VIDIOC_S_FMT 2 VIDIOC_STREAMON 2 VIDIOC_QBUF 2 VIDIOC_CREATE_BUFS 1 VIDIOC_QUERYCAP 1 MEDIA_REQUEST_IOC_QUEUE ``` Read of this pattern: - **84 ENUM_FMT** — capability probing of all 3 backend-tracked fds (rkvdec, hantro, plus iter38 alt-probe walking). - **2 STREAMON** + **2 CREATE_BUFS** + **2 S_FMT** — one OUTPUT + one CAPTURE setup, single decode-context cycle. - **4 VIDIOC_S_EXT_CTRLS** — corresponds to the backend's 5 standard HEVC controls registered at `h265.c:660-688` (SPS, PPS, SLICE_PARAMS, SCALING_MATRIX, DECODE_PARAMS). The "4" count is per-strace-fd; submitted as one ioctl carrying all controls but counted on each thread the backend touched. - **1 MEDIA_REQUEST_IOC_QUEUE** — backend submitted exactly ONE request, the kernel started processing it, and that's when `rkvdec_hevc_prepare_hw_st_rps` faulted in `__pi_memcmp`. - **0 VIDIOC_S_EXT_CTRLS for `V4L2_CID_STATELESS_HEVC_EXT_SPS_ST_RPS` or `_LT_RPS`** — confirmed by absence in strace text (and by source-grep against the backend, which has zero references to these CIDs). The ioctl count summary IS the BEFORE-state contract for Phase 7. After iter2 patch the predicted delta: | ioctl | BEFORE | AFTER prediction | Reasoning | |-------|--------|------------------|-----------| | VIDIOC_ENUM_FMT | 84 | ~84 (unchanged) | Capability probing is at init; iter2 patch doesn't add to it | | VIDIOC_QUERYCTRL | 0 in trace | 2 added (probe for each new CID at init) | Runtime probe per Phase 1 spec | | VIDIOC_S_EXT_CTRLS | 4 | 6 (per-frame, plus per-init) | Adding EXT_SPS_ST_RPS + EXT_SPS_LT_RPS | | VIDIOC_QBUF | 2 | ~10 (for `-frames:v 5` → 5 OUTPUT + 5 CAPTURE) | Decode proceeds beyond first frame | | MEDIA_REQUEST_IOC_QUEUE | 1 | 5 | One per decoded frame | | dmesg new lines | OOPS trace | empty (no rkvdec_hevc_prepare_hw_st_rps fault) | C6 | ## Kernel OOPS trace (BEFORE-state, captured fresh) dmesg fragment for `--time-format=ctime 'Sat May 16 10:42:24'`: ``` [Sat May 16 10:42:24 2026] media_request_ioctl+0xc8/0x160 [mc] [Sat May 16 10:42:24 2026] __arm64_sys_ioctl+0xa4/0x100 [Sat May 16 10:42:24 2026] invoke_syscall.constprop.0+0x40/0xf0 [Sat May 16 10:42:24 2026] el0_svc_common.constprop.0+0xb8/0xd8 [Sat May 16 10:42:24 2026] do_el0_svc+0x1c/0x28 [Sat May 16 10:42:24 2026] el0_svc+0x30/0xc8 [Sat May 16 10:42:24 2026] el0t_64_sync_handler+0xa0/0xe4 [Sat May 16 10:42:24 2026] el0t_64_sync+0x198/0x19c [Sat May 16 10:42:24 2026] Code: d503245f f1002042 54000643 f8408403 (f8408425) [Sat May 16 10:42:24 2026] ---[ end trace 0000000000000000 ]--- ``` (Top of the trace not captured here — `dmesg | grep -A` cut it off; full trace at ampere-fourier iter1 Phase 0 with the same stack: `rkvdec_hevc_prepare_hw_st_rps+0x38/0x300 [rockchip_vdec]` → `__pi_memcmp+0x10/0x110` → `rkvdec_hevc_assemble_hw_rps+0x1c/0xac` → `rkvdec_hevc_run` → `rkvdec_device_run` → `v4l2_m2m_try_run` → `v4l2_m2m_request_queue` → `media_request_ioctl_queue` → above.) OOPS is **reproducible 100%** post-reboot. Cascade behaviour confirmed: m2m wedges; subsequent decode attempts hang. Same as iter1 Phase 0 finding. ## Falsification anchor for Phase 7 The iter2 patch is judged **F1 (kernel still OOPSes despite valid RPS data)** if after the patch the dmesg `rkvdec_hevc_prepare_hw_st_rps` trace re-appears for an HEVC decode. The before-state trace above is the literal pattern that must NOT recur. If F1 fires, iter2 loops back to Phase 0 with re-opened `kernel-agent#11` and richer evidence: "even with valid GStreamer-parser-sourced RPS data + runtime-probed control submission, the kernel still faults — mechanism is something other than UAPI-gap." ## Phase 7 success-criterion-7 (C7 carry-over) anchor C7 (firefox-fourier vendor-default HEVC engagement) is now testable post-SDDM-auto-login. iter2 Phase 7 will run the empty-profile sweep adapted from ampere-fourier's earlier `~/measurements/firefox-test-v2/sweep.sh` with HEVC added. Not iter2-blocking. ## Phase 3 close iter2 BEFORE-state captured: HEVC OOPS reproducible, exact ioctl sequence pre-wedge documented (84 ENUM_FMT, 40 QUERYBUF, 4 S_EXT_CTRLS, 1 MEDIA_REQUEST_IOC_QUEUE), zero EXT_SPS_*_RPS calls (corroborates iter2 hypothesis), predicted AFTER-state delta tabulated. Phase 7 has a concrete contract to verify against. Ampere is in a wedged-m2m state post-capture; next iter2 phase touching the kernel needs a reboot first. Documented as a Phase 6 / Phase 7 pre-action.