Proactive and crash-time data collection on Steam Deck
summary
Steam Deck uses a pstore default path for fast persistent crash logs (a few megabytes) and falls back to full-memory kdumpst VMcore captures (historically ~200 MB, mitigated by a CMA patch to shrink reserved memory). Kernel events like OOM and split-locks stream via ftrace, GPU resets and minidumps are collected, and all formats are normalized and sent by SLS steam log submitter to Valve Sentry as an opt-in pipeline. Panic notifiers remain fragile and kdumpst currently automates only GRUB setups, so firmware control is required for the pstore+kdump mix to work reliably.
AI-written summary · about
chapters (11)
- 0:00Introduction and background
- 1:06Steam Deck overview and data goals
- 3:13Data collection infrastructure
- 4:39Kernel crash handling with Kdump
- 8:54Pstore for persistent crash logs
- 11:00Steam OS approach combining tools
- 12:29Improving panic notifiers and Kdump
- 14:59GPU reset and metric collection
- 15:42Out of memory and split locks tracking
- 16:47Peripheral data and aggregation
- 17:52Q&A on tool dependencies
related talks
27mWhen kdump is way too much
37mPracticing Linux Crash/Panic Issue on Production and Cloud Server: Using K...
26mStateless Linux Kernel Crashdumps
32mLove Your Crash Dumps
27mShipping Software with an SRE Mindset
01h 19mHow Code Fails in the Real World
37m(Finally) Sufficient Monitoring and Logging
50mPractical aspects of crash reporting, analytics and connectivity