开发者

Debugging kernel hang

开发者 https://www.devze.com 2022-12-29 07:37 出处:网络
I am trying to run an app which is using a kernel mode driver. System locks up every hour and the only way to recover it is a hard reset. Sysrq stops responding, telnet sessions 开发者_Python百科hang

I am trying to run an app which is using a kernel mode driver. System locks up every hour and the only way to recover it is a hard reset. Sysrq stops responding, telnet sessions 开发者_Python百科hang and there are no error messages of any kind. Unfortunately the board does not have ejtag support. I have been trying to isolate it functionally, but this is like looking for a needle in a hay stack. Any suggestions?

PS: This is a mips linux system (2.6.31).


Here are some options, depending on the specifics on your situation. If you can provide more detail about the platform and nature of the kernel mode driver it would be helpful.

Assuming you have reason to be confident in the hardware, your likely sources of lockups are locking problems in the kernel, uninitialized variables, and infinite loops with preemption disabled.

Can you configure a timer interrupt to run periodically and blink a LED? You might find it useful to see if interrupts continue to be handled while in a lockup.

Enable soft lockup detection in the Linux kernel hacking menu, and any other relevant kernel hacking features. It may take Linux a minute or two detect and report a soft lockup. Have you waited long enough to check for this?

Enable lock dependency checking in kernel hacking, and fix any reported locking errors in your driver.

Try changing the kernel preemption mode. This changes the behaviour of some system locks, in some cases turning deadlocks into less harmful locks. If it's relevant/possible, disable SMP.


Unfortunately without sysreq operating, or some way of poking the underlying system, you are out of luck.

If you can get some behavior out of the system (perhaps a hardware watchdog?), I would recommend kdump.

Furthermore, if this is a more recent problem, start by bisecting the code of the driver to determine where the crash is occurring.


If the kernel isn't totally hung and you are still getting interrupts, you might be able to use KGDB.

If you can't do that, you could add more logging code to your driver to track down the source of the problem. I'd put a printk() on every function's entry at a minimum and probably on every exit of each function as well. That should at least help you find out where the problem is happening.

0

精彩评论

暂无评论...
验证码 换一张
取 消