SouveraineOS/docs/tasks/34-slpi-bringup-sequencing.md

TASK 34 — SLPI bring-up sequencing regression

Status: NEEDS RE-DIAGNOSIS — the test below is invalid (2026-07-27). The real symptom is the one reproduced deliberately: a DSP-side FastRPC session survives its host daemon's death and only a cold boot clears it. A recovery path that does not cost a cold boot is what this task is for; the sequencing question is downstream of it. No longer blocks grip — TASK-13 shipped 2026-07-28 with the doorbell up. Size: one session, mostly bisection.

2026-07-27: measured on the device, blueline-hexagonrpcd-sdsp is active, and the sensors work: monitor-sensor --light returns live, changing lux (0.665771, unit: lux) and iio-sensor-proxy answers HasProximity/HasAmbientLight/HasAccelerometer = true.

The symptom below — "no ssc-accel, ssc-proximity, ssc-light in /sys/bus/iio/devices" — is not a valid test and was never going to be. The SSC sensors are not IIO devices. 90-iio-sensor-proxy-ssc.rules tags them onto the FastRPC misc nodes:

SUBSYSTEM=="misc", KERNEL=="fastrpc-sdsp*", ENV{IIO_SENSOR_PROXY_TYPE}+="ssc-accel ssc-proximity ssc-light"

so iio-sensor-proxy reaches them over libssc/FastRPC and they never appear under /sys/bus/iio/devices — healthy or not. That directory holds exactly two entries on a working device, both PMIC ADCs, which is what it holds today.

Whatever happened on 07-26 was real (the service did hit its start limit), but "no SSC sensor reached userspace" was inferred from a test that cannot show that. Re-diagnose from the service journal and a live monitor-sensor, not from the IIO device list. TASK-13 is not blocked on this.

2026-07-27 later — the real symptom, reproduced deliberately. Installing a mis-built package crash-looped the doorbell, and tearing it down while CHRE held the DSP session left the attach wedged: Could not attach to FastRPC node: Connection timed out, then on the next try Could not fetch next FastRPC message: Broken pipe, failed after 5 restarts. An SLPI SSR did not recover it — systemctl restart blueline-slpi (remoteproc2 stop → start) brought remoteproc back to running while the doorbell kept broken-piping. Only a cold boot cleared it.

That is this task's thesis, demonstrated: the DSP-side session survives the host daemon's death and nothing on the host can reclaim it. A recovery path that does not need a cold boot is what this task is actually for — the sequencing question is downstream of it. Repo: ~/Projects/Pixel3Arch (rootfs-overlay/etc/systemd/system).

Symptom

blueline-hexagonrpcd-sdsp.service — the FastRPC/HexagonFS doorbell for the SLPI sensor island — dies seconds after start, restarts, and hits its start limit. Observed live 2026-07-26: dead since 14:44, ~2.5 h before anyone noticed, and no SSC sensor reached userspace the whole time (/sys/bus/iio/devices held only the PMIC ADC and rradc — no ssc-accel, ssc-proximity, ssc-light).

This is a sequencing regression, not a new fault. The same path ran consistently in the past.

What the evidence actually says

hexagonrpcd: open $ADSP_LIBRARY_PATH /mnt/vendor/persist/sensors/registry/sns_reg_config (r) -> fd=5
Could not open testsig-0x1c7accff.so: No such file or directory
hexagonrpcd: open $ADSP_LIBRARY_PATH /mnt/vendor/persist/sensors/registry/sns_reg_version (r) -> fd=5
Could not open testsig.so: No such file or directory
Could not fetch next FastRPC message: Broken pipe

Two things in that log are not the bug, and cost time on 07-26:

• The testsig*.so lines are noise. Those are Qualcomm test-signing stubs; they are absent on a healthy boot too. Ignore them.
• The registry is complete. All the files are there and the opens above succeed (-> fd=5). The nested registry/registry layout was flattened deliberately at one point; do not go hunting a missing path. /persist/sensors/registry/registry currently holds 177 groups — matching the Android capture exactly, including the Elmyra ADC groups.

The bug is the line after: the remote PD closes the session. dmesg:

remoteproc remoteproc2: crash detected in slpi: type fatal error
remoteproc remoteproc2: handling crash #6 in slpi
remoteproc remoteproc2: recovering slpi
remoteproc remoteproc2: remote processor slpi is now up

Six firmware crashes during boot. remoteproc recovered each time, but the userspace daemon burned its restart budget against a target that kept vanishing and gave up permanently. SLPI has been stable since — a reset-failed + start at 17:08 still failed identically, so simply restarting does not recover it. Something in the boot ordering puts the daemon against a PD that is not ready.

Two failures worth fixing separately

1. The sequencing itself. blueline-slpi.service carries a long comment about the boot window it must land in (after rmtfs/local-fs, before ath10k's MSA/QMI window). The doorbell's ordering relative to that window is the suspect. Bisect against whatever moved: it worked before.
2. The restart budget is wrong for a target that self-recovers. Six firmware crashes is a survivable event; a start limit that turns it into a permanent outage is not. Either raise StartLimitBurst/interval to cover SSR, or make the unit wait for the island rather than race it.

The third failure is that nobody was told

The daemon exits status 0 on this path (Deactivated successfully), so the crash reporter — which keys on failure — saw nothing, and no surface said the sensors were gone. This is exactly TASK-08 (f), sensors_degraded reaches no surface, with a concrete instance attached: 2.5 hours of no sensors, silently. Fix that there, not here.

Blocks

Nothing, as of 2026-07-28. It used to block TASK-13 step 2 (is sns_touch_gesture served); grip shipped with the doorbell up, so what remains here is the recovery path itself, not a dependency anyone is waiting on.

Connects to

TASK-08 (f) surfacing, TASK-13 (grip, blocked on this), TASK-09 and the sensor bring-up neighbours, blueline-slpi.service's boot-window comment.