lockdep报告只在检测到死锁或循环依赖时输出且必须已启用配置，若dmesg无结果，先验证config_prove_locking=y和/proc/sys/kernel/lockdep=1是否生效，报告必出现在dmesg中，典型开头为“warning: possible circular locking dependency detected”，含锁名、调用点、栈回溯及依赖图。
内核死锁触发后，dmesg 里看不到报告怎么办
Lockdep 报告默认只在真正检测到死锁或循环依赖时才输出，且必须已启用相关配置。如果 dmesg | grep -i "deadlock\|lockdep\|WARNING" 没结果，大概率是 Lockdep 根本没开，或者死锁还没触发（只是卡住但未满足 Lockdep 的检测条件）。
先确认是否启用：
-
cat /proc/sys/kernel/lockdep返回1表示运行时已启用（需 CONFIG_LOCKDEP=y 编译） -
grep CONFIG_PROVE_LOCKING /boot/config-$(uname -r)必须输出CONFIG_PROVE_LOCKING=y -
grep CONFIG_LOCKDEP /boot/config-$(uname -r)必须为y，否则整个机制不可用
注意：仅设置 /proc/sys/kernel/lockdep=1 不够——它只是打开运行时开关，底层编译选项缺一不可。很多发行版内核（如 Ubuntu standard kernel）默认关闭 CONFIG_LOCKDEP，此时写入 /proc/sys/kernel/lockdep 会失败或静默忽略。
死锁发生后，关键日志在哪看
一旦 Lockdep 捕获到问题，报告一定出现在 dmesg 输出中，不会写入文件或 syslog。典型开头是：
WARNING: possible circular locking dependency detected
------------------------------------------------------
kworker/0:2/42 is trying to acquire lock:
(&sb->s_type->i_mutex){+.+.}, at: [] ext4_file_write_iter+0x12a/0x3c0
but task is already holding lock:
(&sb->s_type->i_mutex){+.+.}, at: [] ext4_file_write_iter+0x12a/0x3c0
这类报告包含三部分：
- 锁的符号名（如
&sb->s_type->i_mutex）和调用点地址（ext4_file_write_iter+0x12a/0x3c0） - 当前线程栈回溯（
Call Trace:后面一长串函数） - 锁依赖图（
-> #1 (&sb->s_type->i_mutex){+.+.}等层级缩进）
不要跳过最后的依赖图——它明确指出哪两个锁路径交叉形成了环，这才是定位 AB-BA 死锁的核心依据。
为什么 /proc/lockdep 和 /proc/lockdep_chains 是空的
这两个文件只在 Lockdep 已启用且**至少触发过一次警告**后才生成有效内容。/proc/lockdep 显示当前已注册的锁类数量；/proc/lockdep_chains 则列出所有已记录的锁依赖链。它们不是实时监控接口，而是事后快照。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
常见误操作：
- 以为 cat 这两个文件就能“主动扫描”死锁——实际它们不触发检测，只反映历史积累
- 在没复现 bug 的情况下反复查看，结果自然是空
- 混淆
/proc/lock_stat（需CONFIG_LOCK_STAT=y）——它统计锁争用耗时，和死锁检测无关
真正要查锁竞争热点，用 echo 1 > /proc/sys/kernel/lock_stat 再跑负载，然后看 /proc/lock_stat；但别指望它告诉你哪里死锁了。
用户态进程卡死，但 dmesg 没 Lockdep 日志，该看什么
这是最常被混淆的场景：你看到某个进程 ps 显示状态为 D 或长时间停在 futex_wait_queue_me，但内核没报 Lockdep 警告——说明问题不在内核锁逻辑，而在用户态同步原语或 I/O 阻塞。
此时应转向：
-
cat /proc/<pid>/stack</pid>看内核态调用栈，确认是否真卡在锁上（如futex_wait、mutex_lock） -
pstack <pid></pid>或gdb -p <pid> -ex "thread apply all bt" -ex quit</pid>查用户态线程阻塞点 -
strace -p <pid></pid>观察系统调用是否卡在pthread_mutex_lock、sem_wait等 -
lsof -p <pid></pid>检查是否因文件锁（flock）、socket 或设备节点阻塞
内核 Lockdep 只管内核锁（spinlock/mutex/rwsem），对用户态 pthread_mutex_t 完全无感知——那是 glibc 和 futex 的事。
真正难啃的是那种既没 Lockdep 日志、又没明显用户态阻塞点的情况：比如软锁死（soft lockup）导致 CPU 卡死，但锁本身没循环依赖。这时候得盯紧 dmesg 里 BUG: soft lockup 和 NMI watchdog 的堆栈，而不是徒劳刷新 /proc/lockdep。
