How to Investigate Issues on Linux Embedded System?
summary
Shows concrete debugging steps for R-Car Linux boards: uses ftrace and memtest to capture traces and rare memory corruption, enables early-console and KDB for early boot and live kernel inspection, and adds targeted printk/circular-buffer hooks when tracing affects timing. Presents three root causes: a register-overlap bug in USB endpoint setup, DMA-corruptions in a high physical-memory region fixed by controller settings, and a race in UDC storage fixed with a spinlock.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:18Overview of this session
- 1:31When do we observe issues?
- 2:31What kind of issues do we observe?
- 4:23How to find the root cause?
- 11:14Investigation ways - #define DEBUG
- 12:40Investigation ways - memtest
- 13:25Investigation ways - ftrace
- 16:03Investigation ways - perf
- 17:45Investigation ways - memory logging example
- 20:07Case studies - The USB HID driver cannot work correctly
- 25:26Case studies - NFS rootfs cannot work on a new SoC
- 30:16Case studies - Kernel panic while data transferring
- 32:21Case studies - Probing a device driver fails
- 33:32Case studies - Performance issue
- 36:15Summary
related talks
43mTools and Techniques to Debug an Embedded Linux System
46mTools and Techniques to Debug an Embedded Linux System
38mDebugging Embedded Linux
37mDebugging & Tracing and More Between Linux and RTOS on Heterogeneous ARM SoC
02h 00mAdvanced Debug and Trace Tools for RISC-V Architectures
11mBoost SoC Debug with Smart Monitors and Embedded Software
40mTips, Tricks, and Gotchas for Linux Real-Time Tuning
26mTuning Real-Time Linux for ARM SoCs