请教如何调试内核线程卡死？

fire_vr

Hi，

测试的同事在使用LTP进行压力测试Kernel时，Kernel发生了复位。
LTP全称是Linux Test Project，是一系列应用层的程序。
我看Log，是Kernel下面的watchdog触发的复位。
我们板子的Kernel watchdog是厂家弄的（高通平台），大致的原理是通过schedule_delayed_work_on来周期性喂狗，一旦没来得急喂狗，watchdog模块便调用panic()发生复位了。
因此我判断是Kernel进程调度来不及起schedule_delayed_work_on，导致了复位。

请问如何debug这个问题呢？我想在watchdog使用panic()重启之前，加些打印看当前Kernel下面是哪个线程的占用率高。请问能做得到吗?

谢谢！

镇水铁牛

schedule_delayed_work_on使用的是内核默认的，还是你自己新定义的worker？建议使用自己新定义的。
watchdog重启，要么cpu死锁了，要么是你的喂狗程序异常了。

Tinnal

回复 1# fire_vr


狗多久咬狗？

worker就一普通优先级的内核线程在执行。系统繁忙或有FIFO，它就得让路。

你要关注是正真出问题，还是你的喂狗模型不合理。

fire_vr

如果把watchdog注掉的话，测试是能通过的。
应该是worker优先级不够，但schedule_delayed_work_on的优先级好像不能调呀。请问能有其他更实时的任务来跑我的喂狗程序吗？
回复 3# Tinnal


   

fire_vr

回复 2# 镇水铁牛

Hi，我用schedule_delayed_work_on来运行我们自己定义的喂狗程序。一旦喂狗不及时，就会触发fiq中断系统复位。一直以来运行都正常的，就是在做LTP压力测试时，有时候喂狗任务抢不到控制权。请问有其他的更好方法吗？


   

arm-linux-gcc

回复 5# fire_vr


    要不使用实时线程来做？

linuxfellow

回复 1# fire_vr

出现这样问题一般是系统内进程优先级设置不合理，已经对某些进程实际执行时间估计不足。如果没有办法加ftrace，就可以试试下面的实用办法：kill对cpu资源消耗大的进程，直到看门狗不复位。再把进程按同样顺序加回来，直到复位再发生。这样就可以定位到哪一个，或几个进程有问题。如果单进程有问题，就是该进程strobe看门狗频率不够。要在函数之间，或函数里增加看门狗刷新。如果是多个进程，还要考虑死锁。

fire_vr

回复 7# linuxfellow

Hi， 我想问下如何设置内核的进程优先级呢？
事实上我们有两个版本的内核，一个是3.0.21，一个是3.4.16，3.0.21版本没问题，3.4.16的内核才出问题。当然，两个版本的BSP有些不一样。做测试的LTP执行文件都是一个。
   

镇水铁牛

回复 5# fire_vr
简单易行的办法：用timer去喂狗。

Tinnal

回复 4# fire_vr


无论高有限级线程喂狗也好，Timer喂狗也好，最重要的是你要回答：你要看的门看好没有？

看门够要是一条好狗，主人没事不能乱吠，同时，主人有事不能不吠。看门狗应该选择合理的实现方法，而不是一直去报证能喂狗成功。