[abradburne]

The main thread goes real-time right after the settings are read and then runs to the first frame without a sleep. Under the 200 ms RLIMIT_RTTIME that PipeWire's client module sets, and that any process started from a PipeWire client inherits (a launcher's shelf, for instance), the kernel's RT watchdog kills it with a bare SIGKILL between the settings and SDL_Init whenever that stretch takes more than 200 ms of CPU. Nothing is logged unless kernel.print-fatal-signals is on, so from outside it looks like an instant signal 9 with no crash line.

Reproduced on an RK3566 (Cortex-A55) with the clock capped at 408 MHz: LimitRTTIME=200000 kills DSperate 0.22 s after start, and dmesg shows RT Watchdog Timeout (hard): dsperate. At full clock the same stretch takes 120 ms, so a device half as fast at that moment is enough. A field report on exactly this came in from a handheld running the fork.

The fix moves the OffRealtime guard that already covers the ROM load (rt_budget.h) up to right after latch_worker_sched(), so start-up runs as an ordinary task. The workers take the latched policy themselves in place_current_thread, and the guard still lifts, with a nap, where emulation begins. With it, the same 408 MHz run reaches SDL_Init, and a launch capped at 1.1 GHz reaches its first frame under the 200 ms budget. One visible change: threads started during start-up by SDL and PipeWire no longer inherit the real-time policy; PipeWire's module-rt sets its own.

🤖 Generated with Claude Code