ILD

Ftrace是一个内部追踪，用来帮助开发者和设计者来发现内核正在干啥，可以用来调试和分析发生在用户态之外的延迟以及性能问题，虽然ftrace被认为是function tracer，但是它是多种tracing工具的框架。有一个latency tracing来检查中断开关的延迟，有一个preemptio

以前我们发现一处panic是非法内存访问。但是发生panic的栈是内核的核心栈。这种地方一般不会出现问题。所以通常我们会怀疑是其它模块的非法内存写入导致破坏了其它数据结构，而引起的panic。对于这种问题，我通常无从下手，主要用排除法，下载一些模块，看看是否ok。但是这种方法效率低下。今天看到一篇文

page owner是内核的内存调试的一个功能，可以打印出每一个page的分配栈。因此当使用直接分配页（__alloc_pages)的方式分配内存发生泄露时，使用page owner特别合适。开启选项：Kernel hacking ---> Memory Debugging ---> [*] T

最近再移植ath11k qsdk 12.2版本，移植后，启动出现打印：NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!!打开内核调试选项：Kernel hacking ->

kasan （Kernel Address Sanitizer）是内核的内存检查工具，用来定位内核memory corruption等问题。后面还有一个kfence工具，算是一个后起之秀。kasan的原理是，每8个字节，使用一个字节，来表示这个8字节内存的状态。然后通过gcc编译选项，生成指令，在每

本文，根据异常日志中的code信息，定位到异常模块，及其对应的代码。异常日志mt7621出现升级后连续异常重启5次。每次都是kernel panic[0918_16:27:20][ 52.383539] CPU 2 Unable to handle kernel paging reque

卸载模块后，继续访问模块的数据（全局变量、函数等）导致非法内存访问，触发panic，是一种常见的panic场景。本文分析了一种此类panic的解决思路。pannic日志如下：Unable to handle kernel paging request at virtual address 7fdbc