Linux内核崩溃转储机制。

 

　概述

　　当 系统出现panic的时候，kdump（内核崩溃转储机制）会通过调用kexec来快速的启动预先准备好的dump-capture kernel.该启动方式与快速启动机制类似，不会经过BIOS，属于热启动。dump-capture kernel 启动后，前一个内核运行时的内存镜像会被保存到/proc/vmcore，可以通过cp 或者scp将其vmcore文件拷贝到磁盘上。重启系统后，即可通过分析工具对刚才保存的vmcore文件进行分析，查找导致panic的原因。

　　dump-capture kernel 启动只是使用少量的内存，并且这些内存由第一个内核提供。这样设计保证了第一个内核启动且正在运行中的DMA不会破坏第二个内核的运行。在内核崩溃之前所 有有关于核心映像的必要信息都用ELF格式编码并储存在预先保留的内存区域中。

　　目前kdump和kexec只支持 x86,x86_64,ppc64,ia64这四种架构。

　　设置

　　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."中出现，如果是 这种情况，可以直接检查.config文件，确认CONFIG_SYSFS是不是已经开启。

　　grep 'CONFIG_SYSFS' .config

　　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 \

　　--initrd= --args-linux \

　　--append="root= "

　　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

　　也可以通过/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/