什么是Kdump？
Kdump 是一种的新的crash dump捕获机制，用来捕获kernel crash时候产生的crash dump。Kdump需要配置两个不同目的的kernel，其中一个我们在这里称作standard(production) kernel；另外一个称之为Crash(capture)kernel。
standard（production）kernel，是指我正在使用的kernel，当standard kernel在使用的过程中出现crash的时候， kdump会切换到crash kernel, 简单来说，standard kernel会正运行时发生crash，而crash(capture) Kernel 会被用来捕获production kernel crash时候产生的crash dump。
捕获crash dump是在新的crash(capture) kernel 的上下文中来捕获的，而不是在standard kernel上下文进行。
具体是当standard kernel方式crash的时候，kdump通过kexec（后面介绍）自动启动进入到crash kernel当中。如果启动了kdump服务，standard kernel会预留一部分内存， 这部分内存用来启动crash kernel。
kdump机制主要包括两个组件：kdump和kexec
kexec是一个快速启动机制，允许通过已经运行的内核的上下文启动一个Linux内核，不需要经过BIOS。BIOS可能会消耗很多时间，特别是带有众多数量的外设的大型服务器。这种办法可以为经常启动机器的开发者节省很多时间。Kexec是实现kdump机制的关键，它包括2个组成部分：一是内核空间的系统调用kexec_load，负责在生产内核（production kernel 或 first kernel）启动时将捕获内核（capture kernel或sencond kernel）加载到指定地址。二是用户空间的工具kexec-tools，他将捕获内核的地址传递给生产内核，从而在系统崩溃的时候能够找到捕获内核的地址并运行。没有kexec就没有kdump。先有kexec实现了在一个内核中可以启动另一个内核，才让kdump有了用武之地。
kdump是一种先进的基于kexec的内核崩溃转储机制。当系统崩溃时，kdump使用kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以很小内存启动以捕获转储镜像。第一个内核保留了内存的一部分给第二内核启动用。由于kdump利用kexec启动捕获内核，绕过了 BIOS，所以第一个内核的内存得以保留。这是内核崩溃转储的本质。kdump需要两个不同目的的内核，生产内核和捕获内核。生产内核是捕获内核服务的对像。捕获内核会在生产内核崩溃时启动起来，与相应的ramdisk一起组建一个微环境，用以对生产内核下的内存进行收集和转存。注意，在启动时，kdump保留了一定数量的重要的内存，为了计算系统需要的真正最小内存，加上kdump使用的内存数量，以决定真正的最小内存的需求。
kexec和kdump的设计区别：
Kexec的设计是用新内核去覆盖原内核位置；而KDUMP是预留一块内存来加载第二个内核(和相关数据)，Crash后第二个内核在原位置运行(不然就达不到相关目的了)，收集第一个内核的相关内存信息。
下面开始试验kdump特性：
操作系统：ubuntu 12.10(3.5.0-17-generic)
安装kdump工具
apt-get install kexec-tools crash
发现安装过程中修改了grub，在引导内核配置上(/boot/grub/grub.cfg)多了如下参数
crashker nel=384M-2G:64M,2G-:128M
crashkernel用来指定保留内存的大小，我们可以知道crashkernel帮我们设定的保留区域的大小是：如果内存小于384M，不保留内存；如果内存大于等于384M但小于2G，保留64M；如果内存大于2G，保留128M。
修改kdump配置文件(/etc/default/kdump-tools)
USE_KDUMP=1
下载dbgsym文件，改文件是用来吊事内核信息的文件
wagt 'http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-3.5.0-17-generic-dbgsym_3.5.0-17.28_amd64.ddeb'
dpkg -i linux-image-3.5.0-17-generic-dbgsym_3.5.0-17.28_amd64.ddeb
重启机器使配置生效。
启动kdump-tools
/etc/init.d/kdump-tools start
Starting kdump-tools: setup_linux_vesafb: 1280x1024x32 @ d9800000 +500000
* loaded kdump kernel
kdump-tools配置(kdump-config show)：
USE_KDUMP: 1
KDUMP_SYSCTL: kernel.panic_on_oops=1
KDUMP_COREDIR: /var/crash
crashkernel addr: 0x2e000000
current state: ready to kdump
kernel link:
/usr/lib/debug/boot/vmlinux-3.5.0-17-generic
kexec command:
/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=9386113e-a6db-4a1c-9565-8c8c1de4a55a ro irqpoll maxcpus=1 nousb" --initrd=/boot/initrd.img-3.5.0-17-generic /boot/vmlinuz-3.5.0-17-generic
可以通过sysrq强制系统崩溃。
echo ‘c’ > /proc/sysrq-trigger
这造成内核崩溃，如配置有效，系统将重启进入kdump内核，当系统进程进入到启动 kdump服务的点时，(dump.时间戳文件)将会拷贝到你在kdump配置文件中设置的位置。ubuntu的缺省目录是:/var/crash/时间戳文件夹。然后系统重启进入到正常的内核。一旦回复到正常的内核，就可以在上述的目录下发现dump文件，即内存转储文件。可以使用之前安装的crash工具来进行分析。
生成dump文件后/var/crash的目录结构：
├── 201305061817
│ ├── config_link -> /boot/config-3.5.0-17-generic
│ ├── dump.201305061817
│ ├── kernel_link -> /usr/lib/debug/boot/vmlinux-3.5.0-17-generic
│ └── system.map_link -> /boot/System.map-3.5.0-17-generic
├── config_link -> /boot/config-3.5.0-17-generic
├── kernel_link -> /usr/lib/debug/boot/vmlinux-3.5.0-17-generic
├── kexec_cmd
└── system.map_link -> /boot/System.map-3.5.0-17-generic
ump.201305061817就是生成的dump文件，后面的一串数字诶当时的时间戳。
接下来用crash进行分析
crash /usr/lib/debug/boot/vmlinux-3.5.0-17-generic dump.201305061817
出现如下错误提示： crash: cannot resolve: "xtime"，此时crash的版本为5.1.6，版本太低，调试不了3.5的内核，需要升级crash，可以手动安装crash。