linux kdump crash

Kdump & Crash

标签：  杂谈

分类： Linux系统

Kdump & Crash 学习笔记 连接：

http://blog.chinaunix.net/space.php?uid=24563208&do=blog&frmd=2274&view=me

Kdump & Crash 学习笔记（五）  (2010-09-18 10:44)

分类：   Kdump

五：System-config-kdump

       其实Kdump也有图形化的配置的，之所以放到后面说是因为我认为学习Linux还是不要通过GUI的前端来作各种设置，因为过分依赖这些东西对学习没有什么好处。

       System-config-kdump是个用Python写的前端，安装方法如下：

[root@Derek-Laptop derek]# yum install -y system-config-kdump

      对于其他发行版，应该也有相应的GUI前端，这里就不再多说了。安装好后，可以在 系统->管理->Kdump 找到：

     对比我的/boot/grub/grub.conf可以看到，我保留了 256M 的内错给Crash Kernel。你可以通过System-config-kdump来调整Kdump Memory，也可以通过修改 /boot/grub/grub.conf，个人推荐后者。这里有一个 Total System emory ，大家可以通过看看源代码来找出System-config-kdump是怎么获得这个数字的，因为本人遇到过一个Bug，是 System-config-kdump因为检测不出内存，而直接退出的情况。给大家一点提示， System-config-kdump如果需要获得当前内存信息，那么，有二个文件可能被使用： /proc/iomem  和 /proc/meminfo   。

    除了可以调整 Kdump Memory之外， System-config-kdump还能够配置Dump Target：

    这里所显示的和以前说的没有区别，非常容易看懂这个。另外 System-config-kdump还能修改FIlter：

    左边的Filtering Level就不再多说了，重点说说右边的Output file format。可能大家不知道为什么这里的选项不可选，是因为这是由/sbin/makedumpfile决定的，当输出为ELF格式的时候，也就是添加 -E参数，是不能与-c联合使用的，ELF不支持任何压缩。具体的请/sbin/makedumpfile --help。

    剩下的Expert setting没什么好说的，有时间在这里做Expert倒不如直接修改文件来的更快：

    这些就是System-config-kdump的配置了，非常简单。但是如果不理解他读取了哪些文件，是没有办法理解Kdump的。所以还是推荐大家使用配置文件，而不是GUI前端。

Kdump & Crash 学习笔记（六）  (2010-09-18 18:56)

分类：   Kdump

六：Kdump一些琐碎的东西

       Kdump讲的差不多了，还有一些琐碎的东西要说。首先就是blacklist这个Feature：

       查看/sbin/mkdumprd这个文件，可以看到很多函数。先说明一下，/sbin/mkdumprd是个shell的脚本，如果对脚本不熟悉的话，可能难以理解。Shell在Linux下是非常非常强大的，这是后话了，先看看这个函数：

do_blacklist()

{

    local modName=$1

    if echo "$modName" | grep -q "\/" ; then

        local dirName="/lib/modules/$kernel/$modName"

        find $dirName -xtype f -exec basename {} \; | sed "s/^\(.*\).ko/blacklist \1/g" >> $MNTIMAGE/etc/blacklist-kdump.conf

    else

        echo "blacklist $modName" >> $MNTIMAGE/etc/blacklist-kdump.conf

    fi

}

     这个函数就是实现blacklist这个Feature的。这个Feature的大致目的就是，如果你不希望一些内核模块在Crash Kernel中被加载的话，可以在/etc/kdump.conf添加这样一行：

blacklist iwl3945

     这里用的是iwl3945，我的是Intel Corporation PRO/Wireless 3945ABG的无线网卡，我不想在Crash Kernel中加载iwl3945的内核模块，就可以像上面那样写在 /etc/kdump.conf中，blacklist这个配置的例子在Yum安装的时候，是没有写在默认的配置文件之中的，而且在System-config-kdump之中更别提这些Feature了。所以建议大家使用配置文件来进行Linux的配置。

     举iwl3945这个例子是源于一个Bug，遇到过一个Bug，是因为iwl3945这个模块导致Crash Kernel无法启动，禁用这个模块就可以正常启动了。当然了，这个Bug已经被Upstream修复了！

     另外的一个琐碎的东西是 default 选项。这个选项其实并不只有shell reboot halt选项的，通过这段代码就能看出来：

           default)

                 DEFAULT_ACTION=$config_val

                 case $DEFAULT_ACTION in

                       reboot|shell)

                                   FINAL_ACTION="reboot -f"

                                   ;;

                       halt)

                                   FINAL_ACTION="halt -f"

                                   ;;

                       poweroff)

                                   FINAL_ACTION="poweroff -f"

                                   ;;

                 esac

                 ;;

     其实还有 poweroff 这个选项的。当然了，你还能做的更多，比如说手动添加一个启动到Single的模式！看吧，这就是看源码的好处，总能有很多新的发现^_^

     Kdump的学习差不多就这些了，当然还有更多更多的深层次的东西，比如说kexec的机制、mkdumprd脚本等等。还有很长的路要走......

Kdump & Crash 学习笔记（七）  (2010-09-19 21:20)

分类：   Kdump

七：Crash的准备工作

       Crash这个工具真是非常的强大，具体就不说了，详细的介绍、安装请看 Kdump & Crash 学习笔记（一）。

       如果大家仔细的看了前面的几篇文章，那现在就是介绍如何实验的时候了！首先需要触发一个Crash，有以下几种方法可以选择：

       1)  AltSysRq C

             Kdump能够通过键盘的组合键来触发：Alt+SysRq+C。如果使用的是HMC，那还可以通过Ctrl+O+C来触发

       2)  NMI_WATCHDOG

              如果是硬件导致的Hang，很可能造成AltSysRq C这种方法失效，因为你的键盘可能都没有反应了。这个时候，NMI  Watchdog的特性就能够派上用场了。注意的是，这个特性必须在内核之中启用

       3)  Kernel OOPs

             这也可以产生一个Dump，如果你希望每次Kernel OOPs的时候，都产生一个Dump的话，那么可以：

echo 1 > /proc/sys/kernel/panic_on_oops

       4)  NMI button

        如果系统已经是处在Hang的状态的话，那么可以使用NMI按钮来触发Kdump。开启这个选项可以：

echo 1 > /proc/sys/kernel/unknown_nmi_panic

        需要注意的是，启用这个特性的话，是不能够同时启用NMI_WATCHDOG的！否则系统会Panic！！！

       5) Force-crash

             最后，也是实验需要用的方法。强制触发一个Crash：

[root@Derek-Laptop derek]# echo c > /proc/sysrq-trigger 

            需要注意的是，一旦你这么做了， 你的系统就死了 ！所以，如果你已经保存好你的数据了，并且不担心原地复活过程中SELinux可能的Relabel的话，同时非常冒险、学习的精神！那你可以敲下回车了！

    6) PPC还有一些别的方法，就不细说了，还是以ix86和x86_64为主，如果有需要，请Mail、留言、谷老师！

     先贴一下我的配置文件，首先是/boot/grub/grub.conf：

[root@Derek-Laptop derek]# cat /boot/grub/grub.conf 

default=0

timeout=3

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title Fedora (2.6.34.6-54.fc13.i686.PAE)

root (hd0,0)

kernel /vmlinuz-2.6.34.6-54.fc13.i686.PAE ro root=/dev/mapper/vg_dereklaptop-lv_root rd_LVM_LV=vg_dereklaptop/lv_root rd_LVM_LV=vg_dereklaptop/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet rdblacklist=nouveau  crashkernel=256M

initrd /initramfs-2.6.34.6-54.fc13.i686.PAE.img

      然后是/etc/kdump.conf：

[root@Derek-Laptop derek]# tail /etc/kdump.conf 

#kdump_post /var/crash/scripts/kdump-post.sh

#extra_bins /usr/bin/lftp

#disk_timeout 30

#extra_modules gfs2

#default shell

ext4 UUID=2c560b75-fc2b-4346-a669-6403e954498a

path /var/kdump

core_collector makedumpfile -c --message-level 1 -d 31

default shell

     手动强制触发Kdump之前， 确认一下Kdump服务 ：

[root@Derek-Laptop derek]# service kdump status

Kdump is   operational

     如果你的不是operational，建议你别回车，否则，你的Fedora就真的死了！
     现在，可以敲下回车了！短暂的花屏、神秘字符之后，会出现很多信息了！具体的我就不贴出来了，也没办法贴，因为那个时候已经没有办法复制了！

     在这个过程之中，眼睛好使的话，能够看到trigger a crash这样的信息的，还能看到Crash Kernel启动的很多信息，比如说加载模块、等待磁盘准备、等待网络设备、挂载分区等等很多信息，跟Primary Kernel启动的时候是一样的！如果顺利的话，很快就能保存好vmcore，重启电脑了！这个时候需要插一句，如果你没有使用-d选项，那么你是多大的 内存就会完整的保存多大的vmcore。根据需要选择自己的filter Level吧！

     重启完成之后，就能回到死而复生的Fedora了！如果你跟我一样，2GB的内存，使用-d 31的级别，不是那么老古董的机子，并且没有遇到SELinux的Relabel的话，估计5分钟就能完成了。

     现在来看看我的成果吧：

[root@Derek-Laptop derek]# ll /var/kdump/127.0.0.1-2010-09-18-00\:07\:09/vmcore 

-rw------- 1 root root 21494214  9月 18 08:07 /var/kdump/127.0.0.1-2010-09-18-00:07:09/vmcore

     成功保存了vmcore，好好保留这个文件，以后还指望他分析出当初Crash的原因呢！

Tips:

本来是有一些文档的，但是涉及一些版权的诸多问题，以后有机会拿出来分享！

Kdump & Crash 学习笔记（八）  (2010-10-04 15:46)

分类：   Kdump

八：Crash初步

       最近有点忙，很久都没有写东西了！翻了一下专辑，上次写到了Crash，这篇是讲Crash初步的东西。

       首先得有一个vmcore，可以直接Dump，也可以Mail我o(∩∩)o...

[root@Derek-Laptop derek]# du -sh /var/kdump/127.0.0.1-2010-10-04-16\:14\:09/vmcore 

45M   /var/kdump/127.0.0.1-2010-10-04-16:14:09/vmcore

     这就是我的vmcore了，总共才45M，Level为31。我的内存为2GB，压缩之后的大小非常客观吧！不过还是根据自己的需要来调整Level吧！

     使用Crash来分析vmcore有好几种方法，可以help一下：

     第一种就是 ，跑在Live的系统上，例如：

       $ crash

        $ crash /usr/tmp/vmlinux

        $ crash /boot/System.map vmlinux.dbg

        $ crash -S vmlinux.dbg

        $ crash vmlinux vmlinux.dbg

     另外一种就是跑在dumpfile之上，例如：

        $ crash vmlinux vmcore

        $ crash /boot/System.map vmlinux.dbg vmcore

        $ crash -S vmlinux.dbg vmcore

        $ crash vmlinux vmlinux.dbg vmcore

      这里的-S表示 使用 /boot/System.map 作为mapfile。所有的Usage为：

Usage:

  crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist] [dumpfile]

     我们这里采用的是跑在dumpfile之上的，所以需要安装一个包：

[root@Derek-Laptop derek]# yum install kernel-debuginfo

      需要注意的是，Kdump产生的vmcore需要对应的kernel-debuginfo才能使用Crash分析，所以需要安装对应的debuginfo！！！

      罗嗦了这么多，也该进入正题了！

[root@Derek-Laptop derek]# crash /var/kdump/127.0.0.1-2010-10-04-16\:14\:09/vmcore /usr/lib/debug/lib/modules/2.6.34.7-56.fc13.i686.PAE/vmlinux 

crash 5.0.7

Copyright (C) 2002-2010  Red Hat, Inc.

Copyright (C) 2004, 2005, 2006  IBM Corporation

Copyright (C) 1999-2006  Hewlett-Packard Co

Copyright (C) 2005, 2006  Fujitsu Limited

Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.

Copyright (C) 2005  NEC Corporation

Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.

Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.

This program is free software, covered by the GNU General Public License,

and you are welcome to change it and/or distribute copies of it under

certain conditions.  Enter "help copying" to see the conditions.

This program has absolutely no warranty.  Enter "help warranty" for details.

 

GNU gdb (GDB) 7.0

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.  Type "show copying"

and "show warranty" for details.

This GDB was configured as "i686-pc-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/2.6.34.7-56.fc13.i686.PAE/vmlinux

    DUMPFILE: /var/kdump/127.0.0.1-2010-10-04-16:14:09/vmcore  [PARTIAL DUMP]

        CPUS: 2

        DATE: Mon Oct  4 16:13:36 2010

      UPTIME: 00:32:28

LOAD AVERAGE: 0.94, 0.65, 0.41

       TASKS: 328

    NODENAME: Derek-Laptop

     RELEASE: 2.6.34.7-56.fc13.i686.PAE

     VERSION: #1 SMP Wed Sep 15 03:27:15 UTC 2010

     MACHINE: i686  (1662 Mhz)

      MEMORY: 2 GB

       PANIC: "Oops: 0002 [#1] SMP " (check log for details)

         PID: 3347

     COMMAND: "bash"

        TASK: efcb4c80  [THREAD_INFO: efcca000]

         CPU: 0

       STATE: TASK_RUNNING (PANIC)

crash> 

     Crash使用了对应的vmlinux来分析保存的vmcore，同时也打印出了一些信息^_^

    下面就是一些Debug工作了，比如说bt命令：

crash> bt

PID: 3347    TASK: efcb4c80  CPU: 0    COMMAND: " bash "

 #0 [efccbe38] crash_kexec at c046f511

 #1 [efccbe90] bad_area at c04280b1

 #2 [efccbea8] do_page_fault at c07a5e61

 #3 [efccbed4] error_code (via page_fault) at c07a3a65

     EAX: 00000063  EBX: 00000063  ECX: c0aa4e08  EDX: 00000000  EBP: efccbf14 

     DS:  007b        ESI: c09c171c  ES:  007b        EDI: 00000003  GS:  00e0

     CS:  0060        EIP: c0637138  ERR: ffffffff  EFLAGS: 00210046 

 #4 [efccbf08] sysrq_handle_crash at c0637138

 #5 [efccbf18] __handle_sysrq at c06374f7

 #6 [efccbf40] write_sysrq_trigger at c06375af

 #7 [efccbf50] proc_reg_write at c05117a1

 #8 [efccbf74] vfs_write at c04da415

 #9 [efccbf90] sys_write at c04da50f

#10 [efccbfb0] ia32_sysenter_target at c0408c98

     EAX: 00000004  EBX: 00000001  ECX: b7835000  EDX: 00000002 

     DS:  007b        ESI: 00000002  ES:  007b        EDI: b7835000

     SS:  007b        ESP: bfc9b1bc  EBP: bfc9b1f4  GS:  0033

     CS:  0073        EIP: 00898424  ERR: 00000004  EFLAGS: 00200246

     可以看到，内核崩溃的元凶就是 bash 了！因为我使用了

[root@Derek-Laptop derek]# echo c > /proc/sysrq-trigger

     除此之外，还可以看到当时的程序栈，相当底层的东西了吧^_^