出现原因

1. Linux在中断处理程序中，它不处于任何一个进程上下文，如果使用了可能睡眠的函数，则系统调度会被破坏，导致kernel panic。因此，在中断处理程序中，是不能使用有可能导致睡眠的函数(例如信号量等)。

在中断发起的软中断中，其上下文环境有可能是中断上下文,同理，也不能调用可能导致睡眠的函数。软中断执行时，全局中断是打开的，而中断程序执行时，全局中断是禁止的。

软中断除了系统调度进入点，当软中断数量频繁时，内核中有一个专门的软中断的后台程序daemon来处理其事务。

2. 内核堆栈溢出，或者指针异常访问时，会出现kernel panic。

    堆栈溢出：程序循环或者多层嵌套的深度过多时，可能会导致栈溢出。参考Linux的内存模型

3. 除0异常、内存访问越界、缓冲区溢出等错误时，当这些事件发生在应用程序时，Linux内核的异常处理机制可以对这些由应用程序引起的情况予以处理。当应用程序出现不可恢复性错误时，Linux内核可以仅仅终止产生错误的应用程序，而不影响其他程序。

  如果上述操作发生在内核空间，就会引起kernel panic。

4. 内核陷入死锁状态，自旋锁有嵌套使用的情况。

解决方法

1. 全部排查内核中可能造成睡眠的函数调用地方。如果是自己写的模块，则在调用睡眠函数之前打印出特征日志，以备查验。

2. 在可疑的地方，调用dump_stack()函数或者__backtrace()，打印当前CPU的堆栈调用函数。

3. 打开Linux内核的崩溃转储机制(kdump机制，生产vmcore文件)，当系统crash时，将内存内容保存到磁盘，或者通过网络发送到故障服务器，或者直接使用内核调试器。crash工具用于调试内核崩溃转储文件。

4. 尝试使用kgdb来单步调试内核，分析内核错误日志，并且构造条件重现。

5. 使用内核自带的 notify_chain机制。Linux内核提供“通知链”功能，并预定义了一个内核崩溃通知链。当kernel panic时，异常处理程序会沿着预定义的通知链顺序调用注册到通知链中的通知函数。

6. 在RedHat、StackOverflow、查找出现bug的历史解决方案，

7. 调试方法，采用kprobe来调试内核。Kprobe在Linux kernel debug中的应用