linux驱动调试修改系统时钟终端来定位僵死问题【转】

曾经遇到过一个bug是这样的&＃xff0c;通过串口终端和开发板交互时&＃xff0c;执行一个程序后&＃xff0c;整个系统就挂了&＃xff0c;也不接受输入了&＃xff0c;只能重启&＃xff0c;
后来发现是死在某段代码里了&＃xff0c;当时可是费了一番功夫&＃xff0c;今天来说一下怎么调试这种系统僵死的程序.

首先说一下linux的时钟中断。
linux的时钟中断也是一种硬件中断&＃xff0c;通过计数器产生输出脉冲&＃xff0c;送到CPU&＃xff0c;触发中断。这个中断比较特殊&＃xff0c;它是来记录系统时间的&＃xff0c;
每隔固定的一段时间就会触发一次。类似于现实中的钟表&＃xff0c;每隔1秒就滴答一次&＃xff0c;记录时间&＃xff0c;我们的时间概念都是以这个为基准的。
同样&＃xff0c;内核当中的时间都是以时钟中断为基准的&＃xff0c;一次中断就可以认为是一个时间单位。它是内核的心脏&＃xff0c;它不跳了&＃xff0c;内核肯定就挂了。
系统利用时钟中断来维持系统时间、促使环境切换和进程调度。

linux用HZ来表示1s产生的时钟中断次数&＃xff0c;用jiffies来表示自从系统启动后产生了多少次时钟中断

下面进入正题

首先写一个能够引起系统僵死的测试程序。


system_dead.c


test.c

# insmod system_dead.ko
sysdead_drv_init success!
# ./test

程序会卡死&＃xff0c;输入会没有任何反应&＃xff0c;因为我们在 sysdead_test_open 函数里引入了一个死循环&＃xff0c;当应用程序调用open的
时候&＃xff0c;程序就陷入死循环出不来了。

这种调试方法的思想是&＃xff0c;如果内核僵死了&＃xff0c;我们认为可能是卡在某个程序里出不来了&＃xff0c;这个时候内核只有这一个程序在运行。
我们调试方法就是&＃xff0c;如果我们判断一个进程连续执行超过10s&＃xff0c;我们就认为这个进程陷入了死循环&＃xff0c;把进程号&＃xff08;可能是没用的&＃xff0c;因为
卡死了要重新启动&＃xff0c;在运行时进程号就变了&＃xff09;和PC值打印出来&＃xff0c;根据PC值来定位当前执行的代码。

那么怎么去修改内核来实现我们的这种思想呢&＃xff1f;

由之前的说明我们知道&＃xff0c;无论什么时候内核的脉搏总是有的&＃xff0c;就是系统时钟中断。就算卡死的时候也还是有的&＃xff0c;因为它是一个
硬件中断&＃xff0c;卡死的时候也会响应中断。所以我们在系统中断响应函数里添加一段代码实现我们上面的调试思想。

在linux-2.6.30.4\arch\arm\kernel\irq.c 文件中&＃xff0c;找到asm_do_IRQ函数&＃xff0c;修改如下&＃xff1a;


添加的部分为红色的字体&＃xff0c;注意第6、7行的pre_pid和cnt变量定义要用static修饰&＃xff0c;这样初值只会赋一次&＃xff0c;不然会判断错误。
具体原因请百度static的作用。30号中断是代表时钟中断&＃xff0c;见linux-2.6.30.4\arch\arm\mach-s3c2410\include\mach\irqs.h。
current是结构体struct task_struct&＃xff0c;表示当前进程。还有struct pt_regs&＃xff0c;请百度。
通过current->pid, current->comm&＃xff0c;regs->ARM_pc分别打印当前进程号、进程名、PC值。

接下来编译内核&＃xff1a;make uImage
然后启动开发板&＃xff0c;进入uboot模式&＃xff0c;通过tftp下载uImage镜像&＃xff0c;并启动&＃xff1a;
> tftp 0x30007fc0 uImage
> bootm 0x30007fc0

&＃xff08;这个内核是用来调试的&＃xff0c;每一次编译烧到nand flash太麻烦。关于tftp下载内核启动请参见另一篇博文&＃xff1a;
http://blog.chinaunix.net/uid-29401328-id-4930747.html&＃xff09;

下面再来测试一次&＃xff1a;
# insmod system_dead.ko
sysdead_drv_init success!
# ./test             // 卡死了&＃xff0c;等10s会打印如下信息
asm_do_IRQ -> s3c2410_timer_irq : pid &＃61; 635 , task_name &＃61; test , pc &＃61; bf0d700c
asm_do_IRQ -> s3c2410_timer_irq : pid &＃61; 635 , task_name &＃61; test , pc &＃61; bf0d700c

我们一眼就看出来了&＃xff0c;问题出现在test这个程序上&＃xff0c;但具体出在哪不清楚&＃xff0c;就要根据PC值去分析了&＃xff0c;分析方法和之前博文讲的一样。
下面再唠叨一遍&＃xff1a;

1. 找到bf0d700c所在的函数。
现在的系统僵死了&＃xff0c;我们没办法继续下去&＃xff0c;只有重启系统。这里注意一个问题&＃xff0c;重启系统使用的内核要和僵死时使用的内核是同一个。
因为如果内核变了&＃xff0c;我们就很难还原僵死前的状态了&＃xff0c;新内核pc &＃61; bf0d700c可能代表不同的代码。

用tftp启动刚才的内核&＃xff0c;插入模块system_dead.ko。
先去查看内核源码下的 System.map 文件&＃xff0c;看PC地址是否属于其中&＃xff0c;这里不属于&＃xff08;那里面是内核函数&＃xff0c;地址都是以C开头&＃xff09;。
然后查看开发板的模块地址&＃xff1a;cat cat /proc/kallsyms > kall.txt
打开kall.txt&＃xff0c;在里面查找PC值相近的地址&＃xff08;有可能直接查到&＃xff0c;也有可能PC位于某段地址之间&＃xff09;&＃xff0c;这里查到&＃xff1a;

00000000 a system_dead.c        [system_dead]
bf0d7000 t $a   [system_dead]
bf0d7000 t sysdead_test_open    [system_dead]
bf0d7010 t sysdead_drv_exit     [system_dead]

可知pc &＃61; bf0d700c位于sysdead_test_open函数中。接下来去分析这个函数

2. 分析发生错误的函数
因为我们这里的代码很短&＃xff0c;所以可以很快的定位出问题&＃xff0c;但当代码很长时&＃xff0c;可能就需要看汇编了。这里给出方法

反汇编sysdead_test_open函数位于的模块system_dead.ko&＃xff1a;
arm-none-linux-gnueabi-objdump system_dead.ko -D > system_dead.dis

打开system_dead.dis&＃xff1a;&＃xff08;贴出对我们有用的那段&＃xff09;
00000000 :
   0:   e1a0c00d        mov     ip, sp
   4:   e92dd800        push    {fp, ip, lr, pc}
   8:   e24cb004        sub     fp, ip, #4      ; 0x4
   c:   eafffffe        b       c 

到这里就需要用汇编去分析了&＃xff0c;我们这里的错误比较明显&＃xff0c;就是一直跳转到自己这个函数里&＃xff0c;调不出去了。

注&＃xff1a;有可能两次发生僵死时PC值不一样&＃xff0c;就算僵死在同一段代码&＃xff0c;PC值也可能不一样。因为如果死循环是一段代码&＃xff0c;
那么僵死时&＃xff0c;程序可能正在执行这段代码当中的任意一句。