注意，内存故障也可导致假的死锁的，如物理内存故障可直接导致锁变量的值为-1，所以使用该锁的进程都会阻塞. 如果是代码的bug导致的内存corruption,可用valgrind工具检查程序来发现. 但如果是物理内存的故障导致的corruption, 则需要硬件的支持，对于高端的PC, 如MCE功能的机器，当物理内存故障时能直接产生异常或报告, 但对于低端PC服务器，除了运行memtest工具进行检测外，没有其他方法
D) 进程长期处于 'D' (UnInterruptible)状态没法退出
这种多是由内核中的故障引起的. 内核在很多执行路径中会将进程至于'D'的状态，以确保关键的执行路径不被外部的信号中断, 导致不必要的内核中数据结构状态的不一致性. 但一般而言，进程处于 'D' 状态的时间不会太久, 因为状态结束的条件(如timer触发，IO操作完成等)很快会将进程唤醒. 当进程长期处于 'D',关键是要找出其阻塞的代码位置，用 sysrq 的t键功能可直接打印出系统中全部睡眠进程的内核执行堆栈，如 echo 't' > /proc/sysrq-trigger, 其中包括出现 'D'状态的进程的内核态堆栈. 找出代码位置后，一般可直接分析出 'D' 状态不能退出的原因, 如IO read操作因硬件或nfs故障而不能完成.
有可能导致 'D' 状态的原因比较复杂，如‘D’的退出依赖于某变量的值，而该变量的值因某种原因被永久corrupted掉了.
3. 内核故障情形及处理
A) 内核panic
panic是内核最直接的故障报告，发生panic时，内核已经认为故障已经导致操作系统不再具备正常运行的条件了. 当发生panic时，Linux会将所有CPU的中断和进程调度功能都关掉，所以这时系统是没有任何反应的，如果用户启动的是图形界面，则在屏幕上也看不到任何关于panic的信息. 我们通常遇到的，机器没反应，ping不通的情况，绝大部分都是panic. Panic发生时，内核直接在console上打印导致panic的代码位置的调用堆栈, 传统的用户用串口连接到机器上来收集console上的打印信息, 但串口这种方式，显然用起来不方便, 现在的Linux, 如RHEL5,RHEL6， 都采用kdump的方法来收集panic时的信息. 在配置好kdump的情况下，panic时系统会用kexec加载并切换到一个新的内核上(放置在预先分配的内存位置)，并用磁盘或网络等将系统的全部或部分内存数据保存起来.
用kdump收集到panic的数据后，用户用crash工具就能直接查看导致panic的代码路径.
panic一般是很直观的，panic的堆栈信息能直接反映出导致bug的原因，如MCE故障，NMI故障, 数据结构分配失败等. 但有时panic是因为内核主动发现了关键的数据结构不一致性，这种不一致性是什么时候，什么代码导致的，并不清楚，可能还需要多次测试用SystemTap这样的工具进行捕捉
B) 多处理机环境内核执行路径产生的死锁
内核死锁和panic不一样，产生死锁时，内核并不主动的使自己处于挂起状态. 但内核死锁发生时，两个以上的CPU的执行路径在内核态不能推进了，处于互相阻塞状态, 而且是100%的占用CPU(用的spin-lock)，直接或间接的导致全部CPU上的进程无法调度. 内核死锁又分两种情况:
l 涉及到中断上下文的死锁. 这种情况的死锁，最少一个CPU上的中断被屏蔽了.系统可能没法响应ping请求. 由于有一个CPU已经没法响应中断，其上的local APIC定时中断没法工作，可以用NMI Watchdog的方法来检测出来(检查local APIC handler维护的计数器变量)，NMI Watchdog可以在其处理程序中调用panic(), 用户就可以用kdump收集内存信息，从而分析各死锁CPU上的调用堆栈，查处导致死锁的逻辑原因.
l 不涉及中断上下文的死锁. 这种情况的死锁，各CPU上的中断都是正常的，系统能对ping请求作出反应，这时NMI Watchdog无法被触发. 在 2.6.16之前的内核中,并没有一种很好的方法来处理这种情形. 在RHEL5, RHEL6 内核中， 每个CPU上提供了一个watchdog内核线程，在死锁出现的情况下，死锁CPU上的watchdog内核线程没法被调度(即使它是最高优先级的实时进程),它就没法update相应的counter变量，各CPU的NMI Watchdog中断会周期性的检查其CPU对应的counter, 发现没有updated, 会调用panic()，用户就可用kdump收集内存信息，分析各死锁CPU上的调用堆栈，查处导致死锁的逻辑原因.
C) 内核的oops或warning