![请求有关调试 Linux 内核冻结的建议](https://linux22.com/image/204159/%E8%AF%B7%E6%B1%82%E6%9C%89%E5%85%B3%E8%B0%83%E8%AF%95%20Linux%20%E5%86%85%E6%A0%B8%E5%86%BB%E7%BB%93%E7%9A%84%E5%BB%BA%E8%AE%AE.png)
我们正在开发定制嵌入式 Linux 板基于电源 PC 的 SOC和显示面板。
我们正在调试一个问题,在视频播放期间,Linux 内核冻结,甚至不响应 sysrq-trigger,
如果我们启用ftrace
问题就会消失。
我们还尝试了不同的内核黑客选项,例如debug soft irq
,detect hung task
等等。尚未尝试kdb
或kgdb
尚未尝试,但不确定这在这种情况下是否有帮助。
劳特巴赫设置未处于工作状态,因此无法使用它:(
芯片供应商提供了内核和平台代码,但是他们已经停业,因此没有来自他们的支持:(
方法一
- 当它没有响应时,
sysrq-trigger
我怀疑它被困在中断处理程序中, - 因此,在工作中(冻结之前),我监视
/proc/interrupts
并找出了用例中涉及的中断。然后我在部分中添加了标志noinit
,并在每个 irq 处理程序的进入和退出时更新了它。我之前打印过它们request_irq
- 重现问题后,在硬件看门狗重新启动系统后,当我查看这些
dmesg
标志时,其值表明irq_handlers
已退出。 - 我没有看过的一个 irq 是
timer
.我对此毫不怀疑。但是如果我没有找到任何东西,我也会在那里添加标志切换。(但是那里并不抱希望)
问题集1
A)除了内核卡住之外,还有什么可能导致冻结irq handler
?
B)有什么建议可以改进这种方法吗?
C) 还有其他调试技术吗?
方法2
- 我们测试了过去的不同固件版本,发现内核中两个不相关的(与视频播放无关的内核模块,另一个是内核代码的小变化)更改导致了此问题,如果我们删除这些更改,内核冻结就会消失离开。
- 然而,如果保留两个内核更改中的任何一个,崩溃再次出现,就会有更多的故事发生。
- 我们将批判性地研究这些变化,以确定这些不相关的变化如何影响它。
问题集2
A)从上述方法2中的观点来看,有什么特别的地方有人怀疑吗?(我觉得我不知道要问什么问题,所以问这个)。
B)有什么建议可以进一步完善这种方法吗?