我们正在开发定制嵌入式 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）有什么建议可以进一步完善这种方法吗？