借助OOPS信息调试
配置串口：
1.
vi /boot/grub.conf
说明：
Console=ttyS0 对应串口设备
9600 代表波特率
2. 虚拟机上添加串口设备
3. 物理机上配置串口
首先应安装minicom软件
配置minicom
# minicom –s
依次选择 Serial port setup -> Serial Device
修改为： /dev/ttyS0
Save setup as dfl
Exit from Minicom
启动minicom
# Minicom –C 接收文件名
NULL Pointer – 问题分析
当使用了空指针后，内核会产生如上的OOPS信息
使用GDB确定问题代码位置：
1. Gdb ***.ko
2. L*
注：当代码中有释放内存的情况，应该先对该内存置特殊位，以方便代码调试。
实现：
调用：
Soft lockup –问题分析
1. Spinlock 应该成对出现
2. 避免spinlock被中断，导致长时间无法放锁，使用spin_lock_saveirq和spin_unlock_restore
3. 自旋锁内不可以有耗时操作，不可以有睡眠。
Stack Overflow –问题分析
死锁问题
callstack显示大量进程尝试获取同一个lock，那么说明有一个进程持有了该lock未释放。
用”echo t > /proc/sysrq-trigger”命令来获取所有线程的call stack。
# 立即重新启动计算机
echo "b" > /proc/sysrq-trigger
# 立即关闭计算机
echo "o" > /proc/sysrq-trigger
# 导出内存分配的信息 （可以用/var/log/message 查看）
echo "m" > /proc/sysrq-trigger
# 导出当前CPU寄存器信息和标志位的信息
echo "p" > /proc/sysrq-trigger
# 导出线程状态信息
echo "t" > /proc/sysrq-trigger
# 故意让系统崩溃
echo "c" > /proc/sysrq-trigger
# 立即重新挂载所有的文件系统
echo "s" > /proc/sysrq-trigger
# 立即重新挂载所有的文件系统为只读
echo "u" > /proc/sysrq-trigger
Core dump
http://blog.csdn.net/tenfyguo/article/details/8159176
配置
http://blog.chinaunix.net/uid-26557245-id-3199660.html
- 1. 确认需要的软件包已经安装：
a) Kexec-tools
b) Kernel-debuginfo
c) kernel-debuginfo-common
- 2. 配置kdump
打开/etc/kdump.conf，添加
path /var/crash （也可使用scp）
- 3. 配置内核
1. 配置启用NMI Watchdog Timer
vi /boot/grub/grub.cfg
追加nmi_watchdoc=1 (重启后grep NMI /proc/interrupts)
cat /proc/sys/kernel/hung_task_panic 软中断 ， 内核中有进程进入了死循环，结束不了，或执行时间过长。
cat /proc/sys/kernel/nmi_watchdog 硬中断
2. 打开/etc/sysctl.conf，添加
vm.panic_on_oom = 1
kernel.panic_on_unrecovered_nmi = 0
kernel.unknown_nmi_panic = 0
kernel.panic_on_oops = 1
- 4. 配置启动项
打开/etc/grub.conf，添加
crashkernel=256M
- 5. 启动kdump服务
# chkconfig kdump on
# service kdump start
- 6. 测试
# echo "c" > /proc/sysrq-trigger
GDB查看结构体内的偏移
(gdb) p &((struct task_struct *)0)->prio
$1 = (int *) 0x30
来源：https://www.cnblogs.com/jawfeng/p/5317070.html