Files
fresnel-fourier/phase0_findings_iter10.md
marfrit 917e9b2691 iter10 Phase 0: Bommarito patch unreachable on RK3399 — close Phase 0 negative
Empirical reachability check on linux-fresnel-fourier 7.0-1 source tree
at boltzmann:~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/.../linux-7.0/.

rkvdec_hevc_assemble_hw_rps() is defined in rkvdec-hevc-common.c:411 and
called ONLY from rkvdec-vdpu381-hevc.c:609 (RK3576) and
rkvdec-vdpu383-hevc.c:620 (RK3588). RK3399's variant_ops bind to
rockchip,rk3399-vdec and route HEVC through the older standalone
rkvdec-hevc.c, which does NOT call rkvdec_hevc_assemble_hw_rps.

Bommarito's May 13 patch is real and load-bearing on RK3588/3576,
but inert on RK3399 / fresnel. Not iter10 vehicle for Bug 5.

Saved a kernel build/reboot cycle by Phase-0 reachability check.

Memory rule candidate: before applying any upstream patch to fresnel's
kernel, verify the patched path is reachable from rockchip,rk3399-vdec.
mainline rkvdec has diverging per-variant code (VDPU381/383 vs RK3399
legacy).

iter10 candidate pivots:
- α-10: audit rkvdec-hevc.c (RK3399 legacy) for analogous OOB gaps;
  same KUnit/KASAN methodology Bommarito used. Route via kernel-agent
  per user directive.
- α-12: stay on Bug 4 H.264 (PPS deep diff / OUTPUT bitstream).

User directive registered: "consult kernel-agent for kernel work."

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-14 01:34:20 +00:00

75 lines
5.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Iteration 10 — Phase 0 (substrate / motivation / inventory) → Phase 1 lock
Opens 2026-05-14 after iter9 PARTIAL close ([`phase8_iteration9_close.md`](phase8_iteration9_close.md), commit `5e2a228`). User pointed me at Michael Bommarito's May 13, 2026 patch on linux-rockchip:
> `[PATCH] media: rkvdec: hevc: cap EXT SPS RPS control counts before descriptor assembly`
> Message-ID: `<20260513181922.2075438-1-michael.bommarito@gmail.com>`
> Assisted-by: Claude:claude-opus-4-7
iter10 Phase 0 task: evaluate whether this kernel-side bounds-check patch fixes Bug 5 (HEVC libva all-zero) on fresnel.
## Empirical reachability check
The patch adds `rkvdec_hevc_validate_rps_ctrls()` and calls it at the entry of `rkvdec_hevc_assemble_hw_rps()` in `drivers/media/platform/rockchip/rkvdec/rkvdec-hevc-common.c:411`.
Reachability on fresnel (RK3399, `rockchip,rk3399-vdec`):
```
$ grep -rn rkvdec_hevc_assemble_hw_rps drivers/media/platform/rockchip/rkvdec/
rkvdec-hevc-common.c:411 void rkvdec_hevc_assemble_hw_rps(...) { ... } # definition
rkvdec-hevc-common.h:96 void rkvdec_hevc_assemble_hw_rps(...); # header
rkvdec-vdpu381-hevc.c:609 rkvdec_hevc_assemble_hw_rps(...) # RK3576 caller
rkvdec-vdpu383-hevc.c:620 rkvdec_hevc_assemble_hw_rps(...) # RK3588 caller
```
The function is referenced **only** from the VDPU381 (RK3576) and VDPU383 (RK3588) variant glue. The RK3399 variant operations (`rk3399_variant_ops` in `rkvdec.c:1657`) bind to `rockchip,rk3399-vdec` (DT compatible at line 1752) and the RK3399 HEVC path lives in the older `rkvdec-hevc.c`, which does **not** call `rkvdec_hevc_assemble_hw_rps`.
**Conclusion**: Bommarito's patch is reachable on RK3588 / RK3576, not on RK3399. **It does not fix Bug 5 on fresnel.**
This matches Bommarito's own commit log:
> "I don't have a RK3588 / RK3576 board to confirm this through a real /dev/videoN request path yet, but was convinced enough by [KUnit harness]."
The patch is real and load-bearing on the RK3588/3576 path — but irrelevant to our hardware.
## Implications for the campaign
1. The May 13 patch is **not an iter10 candidate** for fresnel.
2. Bug 5 (HEVC libva all-zero) on fresnel is in a different code path: `rkvdec-hevc.c` (the RK3399 standalone HEVC handler). That's what would need to be investigated for a kernel-side Bug 5 fix.
3. The Bommarito patch is still useful as **methodology reference**: KUnit harness around the existing helper, KASAN-detect OOB writes, then add bounds check. Same shape could be applied to the RK3399 HEVC path in `rkvdec-hevc.c` if we suspect a similar OOB write is happening there.
## iter10 candidate pivots
Three candidates after Bommarito unreachability is confirmed:
- **α-10**: Audit the RK3399 HEVC kernel path (`rkvdec-hevc.c`) for analogous bounds-check gaps. If libva's HEVC controls submit out-of-range count fields, we may be triggering a silent OOB write that explains Bug 5's all-zero output. Same KUnit/KASAN methodology as Bommarito.
- **α-11**: Apply Bommarito's patch anyway (no-op on RK3399 since unreachable, but ships hygiene). Skip — pure busywork.
- **α-12**: Stay on Bug 4 H.264 (iter9 close ranked: PPS deep diff, OUTPUT bitstream byte inspection, DPB ordering, slice-data encoding).
User directive carries: "consult kernel-agent for kernel work" → α-10 (if pursued) routes through kernel-agent for source / build / promote.
## Substrate state at iter10 open
- Fork tip `e0be4e6` (iter9 close) on noether + fresnel + gitea.
- Backend SHA `a17e3c39…` on fresnel (iter8+iter9 hygiene cleanups: γ + IMP-1 + α-2 + α-7).
- Kernel `linux-fresnel-fourier 7.0-1` unchanged (mmind v7.0 + 3 PBP DTS).
- Kernel source on boltzmann: `~/src/kernel-agent-bootstrap/build/marfrit-packages/arch/linux-fresnel-fourier/src/linux-7.0/`.
- All diagnostic instrumentation (γ + memset gate) preserved.
## Locked research question (iter10, 2026-05-14)
Phase 0 conclusion: Bommarito patch is **not the iter10 vehicle**. iter10 PASS condition for this Phase 0 alone is simply **"establish whether the Bommarito patch is reachable on fresnel: no."** That's done.
iter10 continues by picking a fresh research question — defer to user direction or proceed with α-10 / α-12.
## Phase 8 wrap (early)
This Phase 0 closes with a definitive negative finding. iter10 doesn't need a Phase 1-7 loop because the candidate was eliminated at Phase 0 by reachability analysis.
Net: **eliminated one kernel-side hypothesis for Bug 5 cleanly without burning a kernel build cycle.** Source-read on boltzmann's kernel-agent tree was sufficient.
Memory rule worth recording: **before applying any upstream patch to fresnel's kernel, verify the patched code path is reachable from `rockchip,rk3399-vdec`**. The mainline rkvdec tree has diverging per-variant code (VDPU381/383 vs RK3399 legacy) and patches targeting one variant don't apply to the other.
## Next moves
Pending user direction. Default: continue with α-12 (Bug 4 H.264, the iter9 ranked candidates) until kernel work for Bug 5 is explicitly invoked.