linux程序崩溃
⑴ 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_schele(&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_schele(&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);
/*初始化工作队列并将其与处理函数绑定*/
schele_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)
{
...
schele_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);
...
}
⑵ Linux下多线程程序崩溃时怎么提取出所有线程的函数调用栈
gcc编译时加-g参数，然后用gdb去跑，挂掉的时候使用bt命令就可以看到某一线程的调用栈了，你可以使用thread命令去切换线程，就可以看到不同线程的调用栈了，具体去网络一下gdb的用法就行了。
另：
还可以把堆栈错误给mp core，如果你觉得有必要的话。
⑶ 如果在linux中遇到down机你怎么处理(比如数据库崩溃,后台程序崩溃)
这样看怎么个崩溃了，如只是应用崩溃，那需要尽快查清楚原因，恢复数据和应用程序这些东西。
如果是系统崩溃估计只有先重启，然后在启动数据库和应用啥的，看看是否受损，如有受损尽快查找原因，进行恢复操作。
如果是硬件级别的崩溃就比较惨了，只要存储还健全，那还能通过手段恢复数据啥的，如果是存储异常，就杯具了，基本上所有的东西都差不多该重装了。
⑷ Linux 操作系统在什么情况下崩溃
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 = 0; ks_obtained < 1024; ks_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.其它。（不知道了）
⑸ 分析linux内核崩溃信息
分析kernel比较关键的就是看三点：1） 内核会给出一个崩溃原因的猜测，这里是，CPU 0 Unable to handle kernel paging request at virtual address 000000002） 看pc指针的值，这里是epc == 000000003） 看调用栈Call Trace:[ //可惜后面没给出来通常是根据指针加上偏移值跟反汇编代码对照，找到出问题的指令。这个panic的原因比较明显，应该是引用了空指针，试图执行0x00000000出的代码。