linux驱动中断，程序运行几个小时后系统崩溃

中断与定时器:

中断的概念:指CPU在执行过程中，出现某些突发事件急待处理，CPU暂停执行当前程序，转去处理突发事件

，处理完后CPU又返回原程序被中断的位置继续执行

中断的分类:内部中断和外部中断

内部中断:中断源来自CPU内部(软件中断指令、溢出、触发错误等)

外部中断:中断源来自CPU外部，由外设提出请求

屏蔽中断和不可屏蔽中断:

可屏蔽中断:可以通过屏蔽字被屏蔽，屏蔽后，该中断不再得到响应

不可平布中断:不能被屏蔽

向量中断和非向量中断:

向量中断:CPU通常为不同的中断分配不同的中断号，当检测到某中断号的中断到来后，就自动跳转到与该中断号对应的地址执行

非向量中断:多个中断共享一个入口地址。进入该入口地址后再通过软件判断中断标志来识别具体哪个是中断

也就是说向量中断由软件提供中断服务程序入口地址，非向量中断由软件提供中断入口地址

/*典型的非向量中断首先会判断中断源，然后调用不同中断源的中断处理程序*/

irq_handler()

{

...

int int_src = read_int_status()/*读硬件的中断相关寄存器*/

switch(int_src){//判断中断标志

case DEV_A:

dev_a_handler()

break

case DEV_B:

dev_b_handler()

break

...

default:

break

}

...

}

定时器中断原理:

定时器在硬件上也以来中断，PIT(可编程间隔定时器)接收一个时钟输入，

当时钟脉冲到来时，将目前计数值增1并与已经设置的计数值比较，若相等，证明计数周期满，产生定时器中断，并

复位计数值。

如下图所示:

Linux中断处理程序架构:

Linux将中断分为:顶半部(top half)和底半部(bottom half)

顶板部:完成尽可能少的比较紧急的功能，它往往只是简单的读取寄存器中的中断状态并清除中断标志后就进行

“登记中断”(也就是将底半部处理程序挂在到设备的底半部执行队列中)的工作

特点：响应速度快

底半部:中断处理的大部分工作都在底半部，它几乎做了中断处理程序的所有事情。

特点：处理相对来说不是非常紧急的事件

小知识:Linux中查看/proc/interrupts文件可以获得系统中断的统计信息。

如下图所示:

第一列是中断号 第二列是向CPU产生该中断的次数

介绍完相关基础概念后，让我们一起来探讨一下Linux中断编程

Linux中断编程:

1.申请和释放中断

申请中断:

int request_irq(unsigned int irq,irq_handler_t handler,

unsigned long irqflags,const char *devname,void *dev_id)

参数介绍:irq是要申请的硬件中断号

handler是向系统登记的中断处理程序(顶半部)，是一个回调函数，中断发生时，系统调用它，将

dev_id参数传递给它

irqflags:是中断处理的属性,可以指定中断的触发方式和处理方式:

触发方式:IRQF_TRIGGER_RISING、IRQF_TRIGGER_FALLING、IRQF_TRIGGER_HIGH、IRQF_TRIGGER_LOW

处理方式:IRQF_DISABLE表明中断处理程序是快速处理程序，快速处理程序被调用时屏蔽所有中断

IRQF_SHARED表示多个设备共享中断,dev_id在中断共享时会用到，一般设置为NULL

返回值:为0表示成功，返回-EINVAL表示中断号无效，返回-EBUSY表示中断已经被占用，且不能共享

顶半部的handler的类型irq_handler_t定义为

typedef irqreturn_t (*irq_handler_t)(int,void*)

typedef int irqreturn_t

2.释放IRQ

有请求当然就有释放了

void free_irq(unsigned int irq,void *dev_id)

参数定义与request_irq类似

3.使能和屏蔽中断

void disable_irq(int irq)//等待目前中断处理完成(最好别在顶板部使用，你懂得)

void disable_irq_nosync(int irq)//立即返回

void enable_irq(int irq)//

4.屏蔽本CPU内所有中断:

#define local_irq_save(flags)...//禁止中断并保存状态

void local_irq_disable(void)//禁止中断，不保存状态

下面来分别介绍一下顶半部和底半部的实现机制

底半部机制:

简介:底半部机制主要有tasklet、工作队列和软中断

1.底半部是想方法之一tasklet

(1)我们需要定义tasklet机器处理器并将两者关联

例如:

void my_tasklet_func(unsigned long)/*定义一个处理函数*/

DECLARE_TASKLET(my_tasklet,my_tasklet_func,data)

/*上述代码定义了名为my_tasklet的tasklet并将其余

my_tasklet_func()函数绑定，传入的参数为data*/

(2)调度

tasklet_schedule(&my_tasklet)

//使用此函数就能在是当的时候进行调度运行

tasklet使用模板:

/*定义tasklet和底半部函数并关联*/

void xxx_do_tasklet(unsigned long)

DECLARE_TASKLET(xxx_tasklet,xxx_do_tasklet,0)

/*中断处理底半部*/

void xxx_do_tasklet(unsigned long)

{

...

}

/*中断处理顶半部*/

irqreturn_t xxx_interrupt(int irq,void *dev_id)

{

...

tasklet_schedule(&xxx_tasklet)//调度地板部

...

}

/*设备驱动模块加载函数*/

int __init xxx_init(void)

{

...

/*申请中断*/

result = request_irq(xxx_irq,xxx_interrupt,

IRQF_DISABLED,"xxx",NULL)

...

return IRQ_HANDLED

}

/*设备驱动模块卸载函数*/

void __exit xxx_exit(void)

{

...

/*释放中断*/

free_irq(xxx_irq,xxx_interrupt)

...

}

2.底半部实现方法之二---工作队列

使用方法和tasklet类似

相关 *** 作:

struct work_struct my_wq/*定义一个工作队列*/

void my_wq_func(unsigned long)/*定义一个处理函数*/

通过INIT_WORK()可以初始化这个工作队列并将工作队列与处理函数绑定

INIT_WORK(&my_wq,(void (*)(void *))my_wq_func,NULL)

/*初始化工作队列并将其与处理函数绑定*/

schedule_work(&my_wq)/*调度工作队列执行*/

/*工作队列使用模板*/

/*定义工作队列和关联函数*/

struct work_struct(unsigned long)

void xxx_do_work(unsigned long)

/*中断处理底半部*/

void xxx_do_work(unsigned long)

{

...

}

/*中断处理顶半部*/

/*中断处理顶半部*/

irqreturn_t xxx_interrupt(int irq,void *dev_id)

{

...

schedule_work(&my_wq)//调度底半部

...

return IRQ_HANDLED

}

/*设备驱动模块加载函数*/

int xxx_init(void)

{

...

/*申请中断*/

result = request_irq(xxx_irq,xxx_interrupt,

IRQF_DISABLED,"xxx",NULL)

...

/*初始化工作队列*/

INIT_WORK(&my_wq,(void (*)(void *))xxx_do_work,NULL)

}

/*设备驱动模块卸载函数*/

void xxx_exit(void)

{

...

/*释放中断*/

free_irq(xxx_irq,xxx_interrupt)

...

}

1.一个死循环不大可能把linux搞崩溃，尤其是到2.4以后，内核都有相应的保护机制，多半情况下这种进程会被杀死的。当然，你可以试试提高进程的优先级（这种我没做过，不知道结果，请事先保存好数据，以免不必要的损失）

2.还有，大量地消耗系统内存。这方法也不能成功。

比如：

======================================

#BOF

#include <unistd.h>

#include <stdlib.h>

#include <stdio.h>

#define ONE_K （1024）

int main ()

{

char*some_memory

int size_to_allocate = ONE_K

int megs_obtained = 0

int ks_obtained = 0

while (1) {

for (ks_obtained = 0ks_obtained <1024ks_obtained++) {

some_memory = (char*)malloc(size_to_allocate)

if (some_memory == NULL) exit (EXIT_FAILURE)

sprintf(some_memory, "Hello,World")

}

megs_obtained++

printf("Now allocated %d Megabytes\n", megs_obtained)

}

exit(EXIT_SUCCESS)

}

#EOF

====================

运行之后，

.....

.....

Out of Memory:Killed process 2365

Killed

======================================

系统为了保护自己的安全运行，终止了这个危险的进程。

3.驱动程序出现问题，比如驱动有bug崩溃了，这时间系统就危险了，但现在的社区里面写的开源驱动大都能和内核很好地结合，bug也没抓得差不多了。（关于驱动程序，可以参看Minix作者写的 *** 作系统原理那本书，作者分析，70％的系统崩溃是由于驱动程序引起的，所以minix采用了微内核设计，只把必要的几千行代码放在内核而剩下的都放到了用户层，他认为这样做能极大地提高系统的稳定性。关于微内核的优劣，不好评论，反正我了解一点，GNU中的一个项目是做一个叫做Hurd的微内枋系统，这个项目已经有好几年了，可以去www.gnu.org找相应的文档。

4.其它。（不知道了）

　设置

1.安装kexec-tools工具，至于如何安装，在此不再多 说。

2.编译支持kdump的系统内核，我们叫他primary kernel。

确认以下内核选项已经被打开并重编内核。

1) 使能"kexec system call =>Processor type and features." ,使内核支持kexec系统调用

CONFIG_KEXEC=y

2) 使能"Filesystem" =>"Pseudo

filesystems."=>"sysfs file system support"

CONFIG_SYSFS=y

注意：如果"General Setup."=>"Configure standard kernel features (for small system)" 没有打开的话，"sysfs file system support"可能并不会在"Pseudo

filesystems."中出现，如果是 这种情况，可以直接检nfig文件，确认CONFIG_SYSFS是不是已经开启。

grep 'CONFIG_SYSFS'nfig

3）使能"Kernel hacking."=>"Compile the kernel with debug info" ，保证编译出的内核带有调试符号。因为dump分析工具在读取和分析dump文件时需要这些调试符号。

CONFIG_DEBUG_INFO=Y

3. 编译dump-capture kernel

针对不同的架构，内核选项也有不同，但是不论哪种架构，以下两个选项是必选的

"Processor type and features"=>"kernel crash dumps"

CONFIG_CRASH_DUMP=y

"Filesystems" =>"Pseudo filesystems"=>"/proc/vmcore support"

CONFIG_PROC_VMCORE=y

（当 CONFIG_CRASH_DUMP 被选中时，CONFIG_PROC_VMCORE会被自动选中）

下面我们看一下针对不同的架构，编 译内核还有哪些特殊的选项

1）i386 和x86_64

＊在i386上，使能高内存支持"Processor type and features"=>"high memory support"

CONFIG_HIGHMEM64G=y

or

CONFIG_HIGHMEM4G

＊ 在i386 和x86_64上，关闭"Processor type and features"=>"symmetric multi-processing support"

CONFIG_SMP=n

如果没有将该选项设为n，则需要在加载dump- capture kernel时指定参数maxcpus=1。

＊如果想编译一个加载地址可浮动的内核，则选中"Processor type and features"=>"Build a relocatable kernel"

CONFIG_RELOCATABLE=y

＊ 设置合适的值给"Processor type and features"=>"Physical address where the kernel is loaded"

该值的设置与内核加载地址是否是可浮动的（即是否选中CONFIG_RELOCATABLE）有关。

如 果内核加载地址不可浮动， 则该值必须与crashkernel=Y@X中的X相同（至于crashkernel=Y@X的含义即如何使用将在后面讲到），例 如：crashkernel=64M@16M，则CONFIG_PHYSICAL_START=0x100000

0。

如果内核加载地址可 浮动，则CONFIG_PHYSICAL_START的值便可不必在意，使用默认的即可。不过为了保险起见，为了能使kdump正确执 行，CONFIG_PHYSICAL_START的值不论在何时，都要于X的值相同。

2）ppc64

除了前面两个必须的选项，其 余选项默认即可。

3）ia64

除了前面两个必须的选项，其余选项默认即可。

4.准备好两个内核后，即可按如下步 骤使用kdump

1）使用primary kernel启动系统，但是要在启动参数中加入“crashkernel=Y@X”，Y表示为dump-capture kernel 预留了多少内存空间，X该段空间的起始地址，即内核选项中CONFIG_PHYSICAL_START的值。

对于x86和x86_64架构，一般 使用crashkernel=64M@16M，CONFIG_PHYSICAL_START＝0x1000000

对于ppc64架构，一般使用 crashkernel=128M@32M，CONFIG_PHYSICAL_START＝0x2000000

对于ia64架构，通常使用 crashkernel=256M@256M。

2）加载dump-capture kernel

系统启动后，即可加载dump- capture kernle。

不同的架构，可以选择使用为压缩的dump-capture kernle （vmlinux） 或者压缩过的dump-capture kernle（bzImage/vmlinuz）。

i386 和x86_64：

如果dump-capture kernel编译时未选中CONFIG_RELOCATABLE，则只能使用vmlinux

如果dump-capture kernel编译时打开了CONFIG_RELOCATABLE，则可以使用bzImage/vmlinuz

ppc64 :

只能使用vmlinux

ia64：

可以使用vmlinux或者vmlinuz.gz

加载方法：

kexec -p <dump-capture-kernel-vmlinux-image>\

--initrd=<initrd-for-dump-capture-kernel>--args-linux \

--append="root=<root-dev><arch-specific-options>"

dump- capture-kernel-vmlinux-image：表示存放dump-capture kernel 的路径

initrd-for- dump-capture-kernel：表示initrd的路径，如果没有，可以省略该参数

--args-linux：表示Pass linux kernel style options，没看明白什么意思，但是ia64架构不需要加这个参数，其他架构都要有。

--append： 该参数后跟内核启动参数。

arch-specific-options：内核启动参数的一部分，该处根据不同架构，填写不同参数。 i386, x86_64 和 ia64 填"1 irqpoll maxcpus=1 reset_devices"，ppc64填"1 maxcpus=1 noirqdistrib reset_devices"。

注：

默认情况下，ELF文件头采用ELF64格式存储以支持那些拥有超过 4GB内存的系统。但是可以指定“--elf32-core-headers”标志以 强制使用ELF32格式的ELF文件头。这个标志是有必要注意的，一个重要的原因就是：当前版本的GDB不能在一个32位系统上打开一个使用ELF64格 式的vmcore文件。ELF32格式的文件头不能使用在一个“没有物理地址扩展”（non-PAE）的系统上。（即是说，少于4GB内存的系统）

1 这个参数，将启动“转储捕捉内核”到一个没有网络支持的单用户模式。如果你希望有网络支持，那么使用“init 3”

maxcpus=1，这个前 面说过，如果CONFIG_SMP=n，则需要在启动参数中加入maxcpus=1。

irqpoll 的启动参数可以减低由于在“转储捕获内核”中使用了“共享中断”技术而导致出现驱动初始化失败这种情况发生的概率。

举例：

kexec -p /boot/vmlinux_capture --args-linux --append="root=/dev/nfs rw nfsroot=128.224.149.6:/tftpboot/cxu/15554/rootfs ip=dhcp console=ttyS0,115200 1 maxcpus=1 noirqdistrib reset_devices"

3）测试 kdump是否成功

手动产生一个crash：echo c >/proc/sysrq-trigger。

或者可以些一个强制产生 crash的模块。

如果成功，系统将会进入热启动过程，系统启动完成后，可以执行一下uname -a ,看看内核的名字是不是有-kdump的标签呢？

然后就可以把生成的转储文件vmcore拷贝出来了，直接cp即可：

cp /proc/vmcore <anywhere>

也可以通过/dev/oldmem这个设备将其考出：

cd ~

mknod /dev/oldmem c 1 12

dd if=/dev/oldmem of=oldmem.001

成功将vmcore 拷贝出来后即可重启系统了。

4）分析vmcore文件

在开始分析“转储文件”之前，应该确定重启到一个稳定的内核。

可以 使用GDB在‘转储文件’上做有限的分析。分析的时候需要“带有调试信息的vmlinux文件”（编译的时候带有-g选项），运行如下命令：

gdb vmlinux vmcore

注意：GDB不能分析x86平台上以ELF64格式产生的“内核转储文件”。在一个最大内存为4GB的系统上，可 以通过在“转储捕捉内核”上指定“--elf32-core-headers”标志来使用ELF32格式的文件头。

也可以使用Crash工具集来 分析Kdump产生的“内核转储文件”,crash 工具可以到网上下载：

~anderson/

以上文档主要是翻译自内核自带文档linux/Documentation/kdump/kdump.txt，部分使用自己的语言表达。如有错误，请指正。

标签： 内核崩溃转储机制 Linux

---