marfrit/fresnel-fourier
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
fresnel-fourier/phase0_recovery_2026-05-07.md
T
claude-noether e83298f0da phase 0 deliverables 1-3: SDDM watchpoint, V4L2 inventory, iter8 fork smoke 
Three Phase 0 deliverables, three findings worth flagging.

Deliverable #1 — SDDM recovery (phase0_recovery_2026-05-07.md):

Closed as watchpoint, not as root-caused fix. Greeter is green on
this boot — mfritsche has been in Plasma Wayland on tty1 since 20:32.
The "Process crashed (exit code 1)" in journalctl -u sddm is the
post-login greeter teardown, not the pre-login crash described in
~/.claude/plans/dynamic-forging-piglet.md. No coredumps, no qFatal
strings. No package changed since the 2026-04-28 Syyuu; the only
difference between the failing boot and this one is a reboot —
likely a flaky panfrost/GBM cold-init that happened to succeed.
Plan procedures + /var/cache/pacman/pkg rollback candidates remain
ready if regression fires.

Deliverable #2 — V4L2 inventory (phase0_evidence/2026-05-07/
v4l2_inventory_findings.md, raw capture in v4l2_inventory.txt
which is gitignored as raw data):

Full v4l2-ctl --all + --list-ctrls-menus + --list-formats-out per
node, plus media-ctl topology, plus DT compatibles. Authoritative
codec map on running kernel 6.19.9-99-eos-arm:

  /dev/video3 (rkvdec, rockchip,rk3399-vdec):
    OUTPUT_MPLANE: S265 (HEVC), S264 (H.264), VP9F (VP9)
    CAPTURE_MPLANE: NV12

  /dev/video5 (hantro-vpu-dec, rockchip,rk3399-vpu):
    OUTPUT_MPLANE: MG2S (MPEG-2), VP8F (VP8)
    CAPTURE_MPLANE: NV12

This contradicts phase0_findings.md (and README.md), which both
claim hantro-vpu-dec on RK3399 also does H.264. It does not on
this kernel. Open Question #2 from phase0_findings.md ("two-block
H.264 routing") is null on RK3399. Correction commit follows.

Deliverable #3 — iter8 fork build + vainfo (phase0_evidence/
2026-05-07/iter8_build_smoke.md):

Built libva-v4l2-request-fourier master tip 65969da on fresnel
directly (no distcc per locked precedent), gcc 15.2.1, meson 1.11.1,
ninja 1.13.2, libva 1.23.0, libdrm 2.4.131. Clean build, 302 KB
.so, two harmless v4l2.h forward-decl warnings. Installed to
/usr/lib/dri/v4l2_request_drv_video.so. vainfo enumerates:

  rkvdec bind: H.264 {Main, High, ConstrainedBaseline, MultiviewHigh,
                      StereoHigh}, HEVCMain
  hantro-vpu-dec bind: MPEG-2 {Simple, Main}

Substrate is iter8 master, not iter5 as the campaign docs frame —
libva-multiplanar continued past iter5 into iter6-iter8 between the
2026-05-05 iter5 close and the 2026-05-07 fresnel-fourier scaffold.
Building from master inherits per-OUTPUT-slot REINIT, slot-leak
fix, cap_pool harness, msync verify harness, OUTPUT-pool teardown.
Correction commit follows.

HEVC anomaly worth flagging: src/config.c:146-151 probes
V4L2_PIX_FMT_HEVC_SLICE before adding VAProfileHEVCMain. rkvdec
advertises S265 so the probe succeeds; HEVCMain gets enumerated.
But src/meson.build excludes h265.c from the build. A consumer
that calls vaCreateConfig(VAProfileHEVCMain) will succeed (config.c
validation list includes HEVCMain) but actual decode will fault
at dispatch since no h265 symbols are linked. Phase 4 decision:
re-enable h265.c, gate enumeration on a compile-time #ifdef, or
strip enumeration honestly.

Per-codec routing confirmed one-env-var-per-process: request.c:149
reads LIBVA_V4L2_REQUEST_VIDEO_PATH once at init. A single backend
instance binds to either rkvdec or hantro-vpu-dec, not both. Phase 4
will need either a wrapper-script-per-consumer hack or a backend
probe-loop change to route by VAProfile across both decode nodes.

Build infrastructure (gitignore):

Switched from blanket phase*_evidence/ exclude to extension-based
allow-list — track narrative .md, ignore raw .txt/.log/.trace/.pcap/
.bin/.gz/.zst/.json/.dat/.ftrace/.strace. Keeps the V4L2 inventory
text untracked (reproducible from the v4l2-ctl invocation) while
preserving the findings narrative in-repo.

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

5.2 KiB
Raw Permalink Blame History

Phase 0 task 1 close — SDDM recovery watchpoint (2026-05-07)

Verdict

Closed as watchpoint, not as root-caused fix. SDDM is currently green on fresnel; no recovery action was needed for this boot. Plan procedures in ~/.claude/plans/dynamic-forging-piglet.md stayed unused. Re-open the task on the first organic regression.

Evidence (captured 2026-05-07 ~22:25 CEST over SSH from this session)

System state:

  • uname -r = 6.19.9-99-eos-arm (custom OC kernel, matches phase0_findings.md).
  • uptime = 1:54 → boot at ~20:31 CEST.
  • loginctl list-sessions shows session 2 (uid 1000 mfritsche) on tty1 active since 20:32, plus a manager session and a remote pts session.
  • pgrep -af "plasma|kwin" confirms running Plasma Wayland: /usr/bin/startplasma-wayland (pid 2256), /usr/bin/kwin_wayland_wrapper --xwayland (2361), /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayland-xauthority /run/user/1000/xauth_IhSEKJ --xwayland (2367), /usr/bin/plasmashell --no-respawn (2511).
  • /sys/class/tty/tty0/active = tty1 — graphical foreground.

SDDM journal trace this boot (journalctl -u sddm -b):

  • 20:31:49 Display server started; greeter starting; greeter session opened for user sddm (uid 961) via PAM.
  • 20:31:50 Starting X11 session: /usr/bin/sddm-greeter-qt6 --socket /tmp/sddm-:0-ZWEnZk --theme /usr/share/sddm/themes/eos-breeze.
  • 20:31:51 Greeter loaded /usr/share/sddm/themes/eos-breeze/Main.qml, connected to daemon.
  • 20:31:56 Adding view for "eDP-1" QRect(0,0 1920x1080) — the greeter rendered onto the panel.
  • 20:32:04 mfritsche logged in (Authentication for user "mfritsche" successful), Plasma Wayland session launched.
  • 20:32:11 Greeter stopping...
  • 20:32:16 Error from greeter session: "Process crashed" + sddm-helper exit 9.

The 20:32:16 "Process crashed" is the post-login greeter teardown, not the pre-login crash described in the plan. SDDM kills the greeter on session start; the greeter doesn't exit cleanly; sddm logs that as "crashed". This sequence happens on every successful boot+login on this version of sddm and is not the failure mode dynamic-forging-piglet.md addresses.

Coredumps: coredumpctl list returns "No coredumps found" (since-2h and since-boot both empty). No SIGABRT this boot.

qFatal-style strings in journal since boot: none.

Why this isn't a declared fix

  1. No qFatal capture exists. The plan's Step 1 was never executed because the failure mode didn't reproduce. The plan's Step 2/3 (package-rollback testing) was therefore unreached.
  2. No package changed since pacman -Syyuu on 2026-04-28 22:53–23:00 (mesa 26.0.3→26.0.5, qt6-base/declarative/imageformats 6.10.2→6.11.0, xorg-server 21.1.21→21.1.22). The only difference between the crashing boot and this working boot is a reboot.
  3. RK3399 panfrost / Mali-T860 GBM init is timing-sensitive on cold start. A flaky pre-login GLX context-create that happened to succeed on this boot could fail on the next.
  4. The pacman.log shows two consecutive qt6-base reinstalls on 2026-04-28 23:08 and 23:29 (6.11.0-2 -> 1:6.11.0-2, no version change), then a triple at 23:37 (qt6-base, qt6-declarative, qt6-imageformats reset to 6.11.0). This is consistent with the plan's documented "downgrade test then re-install fourier" sequence; the plan reports the greeter still crashed afterwards. The recovery between then and this boot is unaccounted-for.

Watchpoint conditions (re-open task 1 if any of these fire)

  • journalctl -u sddm -b on a future boot contains qFatal from libqxcb-glx-integration.so (the original signature).
  • coredumpctl list shows a fresh sddm-greeter-qt6 SIGABRT post-reboot.
  • mfritsche reports a black-screen or crash-loop greeter again.

What stays ready in case of regression

  • ~/.claude/plans/dynamic-forging-piglet.md Step 1 invocation is unchanged and runnable as soon as a fresh failure occurs.
  • /var/cache/pacman/pkg/ on fresnel still holds the 2026-04-28 rollback candidates: mesa-1:26.0.3-1, qt6-base-6.10.2-1, qt6-declarative-6.10.2-1, qt6-imageformats-6.10.2-1, xorg-server-21.1.21-1. Plus older mesa 25.2.7 and 25.3.1 (deeper rollbacks if needed).
  • No libdrm-pinebookpro cached version was found in /var/cache/pacman/pkg/; only stock libdrm-2.4.131-1. If a libdrm-pinebookpro rollback turns out to be needed, will need a different source (build host or marfrit-packages snapshot).
  • Workaround Option A (Wayland greeter via Compositor=) and Option B (TTY autologin) remain documented in the plan; not pre-installed.

Implication for Phase 0

Task 1 is closed for this iteration. Phase 0 deliverables 2–6 (V4L2 inventory, iter5 fork build + vainfo, H.264 baseline trace, per-codec fixture inventory, chromium cross-validator trace) proceed against the live Plasma session — no headless-rig substitution needed.

What this isn't

This is not a Mesa, Qt6, or panfrost bug report. We have no evidence of the failure mode on this boot and no diagnostic to attach to a tracker issue. If/when the regression fires and Step 1 captures qFatal output, an upstream report may be appropriate; until then, nothing to file.

Reference in New Issue View Git Blame Copy Permalink