marfrit/fresnel-fourier
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

iter19 Phase 8 close: mechanism 2 (REINIT) disproved; ctrl_hdl mismatch is sole remaining hypothesis

Browse Source 
α-23 test (skip media_request_reinit): no change. HEVC still 06b2c5a0...
all-zero. Kernel printk still shows w=0 h=0 for libva.

Cumulative disproved mechanisms (iter17-iter19):
  2. REINIT clears between S_EXT_CTRLS and QUEUE: DISPROVED (α-23)
  3. Stale stack-local pointer: DISPROVED (α-21)
  5. Silent partial failure via error_idx: DISPROVED (α-22)
  1. request_fd mismatch: unlikely per strace evidence

Remaining:
  4. ctrl_hdl mismatch — libva submits to one v4l2_ctrl_handler,
     rkvdec reads from another.

iter20 candidate: kernel printk dumping &ctx->ctrl_hdl, per-ID
ctrl pointer, and *p_cur.p first bytes during rkvdec_hevc_run_preamble.
Comparing libva vs kdirect will pinpoint where the mismatch sits.

State at close: backend c1d4bb53... (iter15 stable). Fork tip 415688d.
5-codec anchors held. Diagnostic kernel 7.0-3 still running on fresnel.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Markus Fritsche
2026-05-14 09:04:11 +00:00
parent a449cec92e
commit a443ad73d3
1 changed files with 42 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
phase8_iteration19_close.md
+42
View File
@@ -0,0 +1,42 @@
# Iteration 19 — Phase 8 (close)
Closes 2026-05-14. iter19 = test mechanism 2 (REINIT clears controls). DISPROVED. PARTIAL close.
## α-23 test result
Disabled `media_request_reinit()` in `RequestSyncSurface`. HEVC hash unchanged (`06b2c5a0…`); kernel printk still shows `w=0 h=0`. Reverted.
Mechanism 2 (REINIT-clearing) **DISPROVED**.
## Remaining mechanism after iter19
Only mechanism 4 (ctrl_hdl mismatch — libva submits to one v4l2_ctrl_handler, rkvdec reads from another) remains untested. This requires deeper kernel printk: dump `&ctx->ctrl_hdl` pointer + the per-request handler pointer.
Mechanism 1 (request_fd mismatch) is empirically unlikely — strace confirmed libva uses consistent request_fd across S_EXT_CTRLS, QBUF, and IOC_QUEUE for the same frame.
## State at iter19 close
Backend SHA on fresnel: `c1d4bb53…` (iter15 stable). Fork tip `415688d` (revert of α-23). Diagnostic kernel printk in rkvdec_hevc_run remains (linux-fresnel-fourier 7.0-3); useful for iter20+.
5-codec anchors: unchanged. Zero regression from iter15.
## Iter17 finding still load-bearing
Three iterations (17, 18, 19) of investigation have eliminated 4 of 5 hypothesis mechanisms. The smoking-gun finding from iter17 remains:
**rkvdec sees zero V4L2 controls for libva HEVC despite identical wire-byte payloads to kdirect.**
The remaining mechanism (ctrl_hdl handler routing) requires kernel-side printk to confirm. iter20 candidate work.
## iter20 next
Add kernel printk in `rkvdec_hevc_run_preamble` that dumps:
- `&ctx->ctrl_hdl` pointer address.
- For each `v4l2_ctrl_find()`: `ctrl` pointer + `ctrl->p_cur.p` pointer + first 8 bytes of `*ctrl->p_cur.p`.
Compare libva-trigger vs kdirect-trigger:
- If both have same `&ctx->ctrl_hdl` and same `ctrl` per ID, but libva's `p_cur.p` has zeros while kdirect's has correct values — the `v4l2_ctrl_request_setup` (or analog) call during IOC_QUEUE isn't applying request-staged controls to ctx for libva.
- If `&ctx->ctrl_hdl` differs — libva and kdirect are working on different control handlers entirely.
- If `ctrl` differs by ID — control registration changed between contexts.
Each outcome localizes the bug to a specific kernel layer.