Minidump to debug end user device crashes
summary
Qualcomm ships a firmware-backed minidump that records a table of physical regions the kernel or subsystems register and, on a crash, firmware copies only those snippets to a reserved partition instead of a full RAM image, cutting transfer size and user-data exposure. Remote-processor minidump support (ADSP/CDSP/modem) is already upstream; patches add a kernel driver to register kernel regions and surface existing pstore records, initial boot logs, IRQ/runqueue summaries for postmortem.
AI-written summary · about
chapters (17)
- 0:00Introduction to Minidump
- 1:08What is Minidump
- 2:32Limitations of full RAM dumps
- 3:57Comparison with Kdump and ramoops
- 5:02Minidump implementation details
- 6:50Upstreaming Minidump efforts
- 8:18Additional data collection goals
- 12:14Community feedback and future plans
- 13:19User space vs kernel registration
- 15:48Overhead of pstore vs Minidump
- 17:58Non-kernel crash sources
- 20:06Firmware storage requirements
- 22:17ELF format and tooling
- 23:22Firmware and kernel version compatibility
- 24:51Primary motives for Minidump
- 25:55Capturing hung task stacks
- 27:27Closing and Q&A
related talks
46mMeminspect - Kernel memory selection and inspection mechanism
13mRamdump for Trusted VMs: Efficient Crash Debugging Without Reboot Device
43mEfficient and Practical Capturing of Crash Data on Embedded Systems
42mUsing Yocto to Debug Embedded Device Crashes
20mDebugging RISC-V Kernel Crashes: KDUMP, vmcore, and Crash Utility Enhancements- 42mUsing Yocto to Debug Embedded Device Crashes
52mLinux Kernel Debugging: Going Beyond Printk Messages
19mKdump memory usage