Chinaunix首页 | 论坛 | 博客
  • 博客访问: 183749
  • 博文数量: 64
  • 博客积分: 1451
  • 博客等级: 上尉
  • 技术积分: 665
  • 用 户 组: 普通用户
  • 注册时间: 2009-08-24 10:07
文章分类

全部博文(64)

文章存档

2010年(7)

2009年(57)

我的朋友

分类: LINUX

2009-09-08 15:19:43

追风 2009.03.05

概述
当系统出现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/

以上文档主要是翻译自内核自带文档linux/Documentation/kdump/kdump.txt,部分使用自己的语言表达。如有错误,请指正。
阅读(1756) | 评论(0) | 转发(0) |
0

上一篇:Linux 快速启动机制

下一篇:IPsec HOWTO(1)

给主人留下些什么吧!~~