Kernel development is more challenging than user space development. One reason is that kernel debugging is very difficult. Kernel errors often cause system crashes, and it is difficult to retain on-site information at the time of the error. Therefore, the key to debugging the kernel is to have a deep understanding of the kernel.
We have compiled advanced embedded tutorials, and the content is divided into categories for easy reference. Due to the large amount of content, only part of it is shown here.
Before debugging a bug, the preparations we need to do are:
There is a confirmed bug, including the kernel version number of the bug. It is necessary to analyze in which version the bug was introduced. This is of great help in solving the problem. The binary search method can be used to gradually lock the bug introduction version number.
The deeper the understanding of the kernel code, the better. It also requires a little bit of luck. The bug can be reproduced. If you can find the pattern, you are not far from finding the cause of the problem; minimize the system. Eliminate factors that may cause bugs one by one.
Bugs in the kernel are also diverse. There are countless reasons for their occurrence, and their appearance is also varied. From errors hidden in the source code to bugs revealed to witnesses, their onset is often triggered by a series of chain reaction events. Although kernel debugging is somewhat difficult, with your efforts and understanding, you may enjoy the challenge.
To learn to write drivers, you need to build and install your own kernel (standard mainline kernel). One of the most important reasons is this: the kernel developers have built in several features for debugging. But because these features cause extra output and lead to energy degradation, distribution manufacturers often disable debugging functions in the distribution kernel.
Kernel configuration
In order to realize kernel debugging, several items have been added to the kernel configuration:
Kernel hacking ---> [*] Magic SysRq key [*] Kernel debugging [*] Debug slab memory allocaTIons [*] Spinlock and rw-lock debugging: basic checks [*] Spinlock debugging: sleep-inside-spinlock checking [*] Compile the kernel with debug info Device Drivers ---> Generic Driver Options ---> [*] Driver Core verbose debug messages General setup ---> [*] Configure standard kernel features (for small systems) ---> [*] Load all symbols for debugging/ksymoops
Developed from kernel 2.5, the kernel provides excellent tools to check various problems caused by atomic operations.
The kernel provides an atomic operation counter, which can be configured to print a warning message and provide tracking clues once it frequently goes to sleep or performs some operations that may cause sleep during an atomic operation.
Therefore, various potential bugs can be detected, including calling schedule() when using a lock, requesting memory allocation in a blocking manner when using a lock, etc.
The following options can take full advantage of this feature:
CONFIG_PREEMPT = y CONFIG_DEBUG_KERNEL = y CONFIG_KLLSYMS = y CONFIG_SPINLOCK_SLEEP = y
BUG() and BUG_ON()
Some kernel calls can be used to easily mark bugs, provide assertions and output information. The two most commonly used are BUG() and BUG_ON(). Defined in:
#ifndef HAVE_ARCH_BUG #define BUG() do {
printk("BUG: failure at %s:%d/%s()! ", __FILE__, __LINE__, __FUNCTION__);
panic("BUG!"); /* 引发更严重的错误，不但打印错误消息，而且整个系统业会挂起 */
} while (0) #endif #ifndef HAVE_ARCH_BUG_ON #define BUG_ON(condiTIon)
do {
if (unlikely(condiTIon)) BUG();
}
while(0)
#endif
When these two macros are called, they will trigger OOPS, causing stack traceback and error message printing.
※ These two calls can be used as assertions, such as: BUG_ON(bad_thing);
WARN(x) and WARN_ON(x)
WARN_ON calls dump_stack and prints stack information without OOPS. Defined in:
#ifndef __WARN_TAINT#ifndef __ASSEMBLY__extern void warn_slowpath_fmt(
const char *file, const int line, const char *fmt, ...) __attribute__((format(printf, 3,
4)));
extern void warn_slowpath_fmt_taint(const char *file, const int line, unsigned taint, const
char *fmt, ...) __attribute__((format(printf, 4, 5)));
extern void warn_slowpath_null(const char *file, const int line);
#define WANT_WARN_ON_SLOWPATH
#endif#define __WARN() warn_slowpath_null
(__FILE__, __LINE__)
#define __WARN_printf(arg...) warn_slowpath_fmt(__FILE__, __
LINE__, arg)
#define __WARN_printf_taint(taint, arg...) warn_slowpath_fmt_taint(__FILE_
_, __LINE__, taint, arg)
#else#define __WARN() __WARN_TAINT(TAINT_WARN)
#define __WARN_print
f(arg...) do { printk(arg); __WARN();
} while (0)#define __WARN_printf_taint(taint, arg...)
do { printk(arg); __W
ARN_TAINT(taint);
}
while (0)
#endif#ifndef WARN_ON#define WARN_ON(condition) ({
int __ret_warn_on = !!(condition); if (unlikely(__ret_warn_on)) __WARN();
unlikely(__ret_warn_on); })#endif#ifndef WARN#define WARN(condition, format...) ({
int __ret_warn_on = !!(condition); if (unlikely(__ret_warn_on)) __WARN_printf(format);
unlikely(__ret_warn_on); })
#endif
dump_stack()
Sometimes, you just need to print the stack traceback information on the terminal to help you debug. You can use dump_stack() at this time. This function simply prints the register context and function trace trail to the terminal.
if (!debug_check) { printk(KERN_DEBUG “provide some information…/n”); dump_stack(); }
内核提供的格式化打印函数。
printk函数的健壮性
健壮性是printk最容易被接受的一个特质，几乎在任何地方，任何时候内核都可以调用它（中断上下文、进程上下文、持有锁时、多处理器处理时等）。
printk函数脆弱之处
在系统启动过程中，终端初始化之前，在某些地方是不能调用的。如果真的需要调试系统启动过程最开始的地方，有以下方法可以使用：
使用串口调试，将调试信息输出到其他终端设备。
使用early_printk()，该函数在系统启动初期就有打印能力。但它只支持部分硬件体系。
LOG等级
printk和printf一个主要的区别就是前者可以指定一个LOG等级。内核根据这个等级来判断是否在终端上打印消息。内核把比指定等级高的所有消息显示在终端。
可以使用下面的方式指定一个LOG级别：
printk(KERN_CRIT “Hello, world! ”);
注意，第一个参数并不一个真正的参数，因为其中没有用于分隔级别（KERN_CRIT）和格式字符的逗号（,）。KERN_CRIT本身只是一个普通的字符串（事实上，它表示的是字符串 “”；表 1 列出了完整的日志级别清单）。作为预处理程序的一部分，C 会自动地使用一个名为 字符串串联 的功能将这两个字符串组合在一起。组合的结果是将日志级别和用户指定的格式字符串包含在一个字符串中。
内核使用这个指定LOG级别与当前终端LOG等级console_loglevel来决定是不是向终端打印。 下面是可使用的LOG等级：
#define KERN_EMERG "" /* system is unusable */#define KERN_ALERT "" /* action must be taken immediately */ #define KERN_CRIT "" /* critical conditions */#define KERN_ERR "" /* error conditions */#define KERN_WARNING "" /* warning conditions */#define KERN_NOTICE "" /* normal but significant condition */#define KERN_INFO "" /* informational */#define KERN_DEBUG "" /* debug-level messages */#define KERN_DEFAULT "" /* Use the default kernel loglevel */
注意，如果调用者未将日志级别提供给 printk，那么系统就会使用默认值 KERN_WARNING “”（表示只有KERN_WARNING 级别以上的日志消息会被记录）。由于默认值存在变化，所以在使用时最好指定LOG级别。有LOG级别的一个好处就是我们可以选择性的输出LOG。比如平时我们只需要打印KERN_WARNING级别以上的关键性LOG，但是调试的时候，我们可以选择打印KERN_DEBUG等以上的详细LOG。而这些都不需要我们修改代码，只需要通过命令修改默认日志输出级别：
mtj@ubuntu :~$ cat /proc/sys/kernel/printk4 4 1 7mtj@ubuntu :~$ cat /proc/sys/kernel/printk _delay0mtj@ubuntu :~$ cat /proc/sys/kernel/printk_ratelimit5mtj@ubuntu :~$ cat /proc/sys /kernel/printk_ratelimit_burst10
第一项定义了 printk API 当前使用的日志级别。这些日志级别表示了控制台的日志级别、默认消息日志级别、最小控制台日志级别和默认控制台日志级别。printk_delay 值表示的是 printk 消息之间的延迟毫秒数（用于提高某些场景的可读性）。注意，这里它的值为 0，而它是不可以通过的 /proc 设置的。printk_ratelimit 定义了消息之间允许的最小时间间隔（当前定义为每 5 秒内的某个内核消息数）。消息数量是由 printk_ratelimit_burst 定义的（当前定义为 10）。如果您拥有一个非正式内核而又使用有带宽限制的控制台设备（如通过串口）， 那么这非常有用。注意，在内核中，速度限制是由调用者控制的，而不是在printk 中实现的。如果一个 printk 如果用户要求进行速度限制，那么该用户就需要调用printk_ratelimit 函数。
记录缓冲区
内核消息都被保存在一个LOG_BUF_LEN大小的环形队列中。
关于LOG_BUF_LEN定义：
#define __LOG_BUF_LEN (1
※ 变量CONFIG_LOG_BUF_SHIFT在内核编译时由配置文件定义，对于i386平台，其值定义如下（在
linux26/arch/i386/defconfig中）：
CONFIG_LOG_BUF_SHIFT=18
记录缓冲区操作：
① 消息被读出到用户空间时，此消息就会从环形队列中删除。
② 当消息缓冲区满时，如果再有printk()调用时，新消息将覆盖队列中的老消息。
③ 在读写环形队列时，同步问题很容易得到解决。
※ 这个纪录缓冲区之所以称为环形，是因为它的读写都是按照环形队列的方式进行操作的。
syslogd/klogd
在标准的Linux系统上，用户空间的守护进程klogd从纪录缓冲区中获取内核消息，再通过syslogd守护进程把这些消息保存在系统日志文件中。klogd进程既可以从/proc/kmsg文件中，也可以通过syslog()系统调用读取这些消息。默认情况下，它选择读取/proc方式实现。klogd守护进程在消息缓冲区有新的消息之前，一直处于阻塞状态。一旦有新的内核消息，klogd被唤醒，读出内核消息并进行处理。默认情况下，处理例程就是把内核消息传给syslogd守护进程。syslogd守护进程一般把接收到的消息写入/var/log/messages文件中。不过，还是可以通过/etc/syslog.conf文件来进行配置，可以选择其他的输出文件。
dmesg
dmesg 命令也可用于打印和控制内核缓冲区。这个命令使用 klogctl 系统调用来读取内核环缓冲区，并将它转发到标准输出（stdout）。这个命令也可以用来清除内核环缓冲区（使用 -c 选项），设置控制台日志级别（-n 选项），以及定义用于读取内核日志消息的缓冲区大小（-s 选项）。注意，如果没有指定缓冲区大小，那么 dmesg 会使用 klogctl 的SYSLOG_ACTION_SIZE_BUFFER 操作确定缓冲区大小。
注意
a) 虽然printk很健壮，但是看了源码你就知道，这个函数的效率很低：做字符拷贝时一次只拷贝一个字节，且去调用console输出可能还产生中断。所以如果你的驱动在功能调试完成以后做性能测试或者发布的时候千万记得尽量减少printk输出，做到仅在出错时输出少量信息。否则往console输出无用信息影响性能。
b) printk的临时缓存printk_buf只有1K，所有一次printk函数只能记录
内核printk和日志系统的总体结构
动态调试
动态调试是通过动态的开启和禁止某些内核代码来获取额外的内核信息。
首先内核选项CONFIG_DYNAMIC_DEBUG应该被设置。所有通过pr_debug()/dev_debug()打印的信息都可以动态地显示或不显示。
可以通过简单的查询语句来筛选需要显示的信息。
－源文件名
－函数名
－行号（包括指定范围的行号）
－模块名
－格式化字符串
将要打印信息的格式写入/dynamic_debug/control中。
nullarbor:~ # echo ‘file svcsock.c line 1603 +p’ > /dynamic_debug/control
参考：
1 内核日志及printk结构浅析 — Tekkaman Ninja
2 内核日志：API 及实现
3 printk实现分析
4 dynamic-debug-howto.txt
MEMWATCH
MEMWATCH 由 Johan Lindh 编写，是一个开放源代码 C 语言内存错误检测工具，您可以自己下载它。只要在代码中添加一个头文件并在 gcc 语句中定义了 MEMWATCH 之后，您就可以跟踪程序中的内存泄漏和错误了。MEMWATCH 支持ANSIC，它提供结果日志纪录，能检测双重释放（double-free）、错误释放（erroneous free）、没有释放的内存（unfreedmemory）、溢出和下溢等等。
清单 1. 内存样本（test1.c）
#include #include #include "memwatch.h"int main(void){ char *ptr1; char *ptr2; ptr1 = malloc(512); ptr2 = malloc(512); ptr2 = ptr1; free(ptr2);
free(ptr1);}
清单 1 中的代码将分配两个 512 字节的内存块，然后指向第一个内存块的指针被设定为指向第二个内存块。结果，第二个内存块的地址丢失，从而产生了内存泄漏。
现在我们编译清单 1 的 memwatch.c。
下面是一个 makefile 示例： test1 gcc -DMEMWATCH -DMW_STDIO test1.c memwatchc -o test1
当您运行 test1 程序后，它会生成一个关于泄漏的内存的报告。清单 2 展示了示例 memwatch.log 输出文件。
清单 2. test1 memwatch.log 文件
MEMWATCH 2.67 Copyright (C) 1992-1999 Johan Lindh...double-free: test1.c(15),
0x80517b4 was freed from test1.c(14)...unfreed: test1.c(11),
512 bytes at 0x80519e4{FE FE FE FE FE FE FE FE FE FE FE FE ..............}Memory
usage statistics (global): N)umber of allocations made: 2 L)argest memory usage :
1024 T)otal of all alloc() calls: 1024 U)nfreed bytes totals : 512
MEMWATCH 为您显示真正导致问题出现的信息。如果您释放一个已经释放过的指针，它会告诉您。对于没有释放的内存也一样。日志结尾部分显示统计信息，包括泄露了多少内存，使用了多少内存，以及总共分配了多少内存。
YAMD
YAMD 软件包由 Nate Eldredge 编写，可以查找 C++ 和 C++ 动态的、与内存分配有关的问题。在撰写本文时，YAMD 的最新版本为 0.32。请下载 yamd-0.32.tar.gz。执行 make 命令来构建程序；然后执行 make install 命令安装程序并设置工具。
一旦您下载了 YAMD 之后，请在 test1.c 上使用它。请删除 #include memwatch.h 并对 makefile 进行如下小小的修改：
“
使用 YAMD 的 test1
gcc -g test1.c -o test1
”
清单 3 展示了来自 test1 上的 YAMD 的输出。
清单 3. 使用 YAMD 的 test1 输出
YAMD version 0.32Executable: /usr/src/test/yamd-0.32/test1...INFO: Normal allocation of this blockAddress 0x40025e00, size 512...INFO: Normal allocation of this blockAddress 0x40028e00, size 512...INFO: Normal deallocation of this blockAddress 0x40025e00, size 512...ERROR: Multiple freeing Atfree of pointer already freedAddress 0x40025e00, size 512...WARNING: Memory leakAddress 0x40028e00, size 512WARNING: Total memory leaks:1 unfreed allocations totaling 512 bytes*** Finished at Tue ... 10:07:15 2002Allocated a grand total of 1024 bytes 2 allocationsAverage of 512 bytes per allocationMax bytes allocated at one time: 102424 K alloced internally / 12 K mapped now / 8 K maxVirtual program size is 1416 KEnd.
YAMD 显示我们已经释放了内存，而且存在内存泄漏。让我们在清单 4 中另一个样本程序上试试 YAMD。
清单 4. 内存代码（test2.c）
#include #include int main(void){ char *ptr1; char *ptr2; char *chptr; int i = 1;
ptr1 = malloc(512); ptr2 = malloc(512);
chptr = (char *)malloc(512); for (i; i
您可以使用下面的命令来启动 YAMD：
./run-yamd /usr/src/test/test2/test2
清单 5 显示了该样本程序 test2 上使用 YAMD 得到的输出。YAMD 告诉我们在 for 循环中有“越界（out-of-bounds）”的情况。
清单 5. 使用 YAMD 的 test2 输出
Running /usr/src/test/test2/test2Temp output to /tmp/yamd-out.1243*********./run-yamd: line 101: 1248 Segmentation fault (core dumped)YAMD version 0.32Starting run: /usr/src/test/test2/test2Executable: /usr/src/test/test2/test2Virtual program size is 1380 K...INFO: Normal allocation of this blockAddress 0x40025e00, size 512...INFO: Normal allocation of this blockAddress 0x40028e00, size 512...INFO: Normal allocation of this blockAddress 0x4002be00, size 512ERROR: Crash...Tried to write address 0x4002c000Seems to be part of this block:Address 0x4002be00, size 512...Address in question is at offset 512 (out of bounds)Will dump core after checking heap.Done.
MEMWATCH 和 YAMD 都是很有用的调试工具，不过它们的使用方法有所不同。对于 MEMWATCH，您需要添加包含文件memwatch.h 并打开两个编译时间标记。对于链接（link）语句，YAMD 只需要 -g 选项。
Electric Fence
多数 Linux 分发版包含一个 Electric Fence 包，不过您也可以选择下载它。Electric Fence 是一个由 Bruce Perens 编写的malloc()调试库。它就在您分配内存后分配受保护的内存。如果存在 fencepost 错误（超过数组末尾运行），程序就会产生保护错误，并立即结束。通过结合 Electric Fence 和 gdb，您可以精确地跟踪到哪一行试图访问受保护内存。ElectricFence 的另一个功能就是能够检测内存泄漏。
strace
strace 命令是一种强大的工具，它能够显示所有由用户空间程序发出的系统调用。strace 显示这些调用的参数并返回符号形式的值。strace 从内核接收信息，而且不需要以任何特殊的方式来构建内核。将跟踪信息发送到应用程序及内核开发者都很有用。在清单 6 中，分区的一种格式有错误，清单显示了 strace 的开头部分，内容是关于调出创建文件系统操作（mkfs ）的。strace 确定哪个调用导致问题出现。
清单 6. mkfs 上 strace 的开头部分
execve("/sbin/mkfs.jfs", ["mkfs.jfs", "-f", "/dev/test1"], &...open("/dev/test1",
O_RDWR|O_LARGEFILE) = 4stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...})
= 0ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument)write(2, "mkfs.jfs:
warning - cannot setb" ..., 98mkfs.jfs: warning -cannot set blocksize on block device
/dev/test1: Invalid argument ) =
98stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) =
0open("/dev/test1", O_RDONLY|O_LARGEFILE) = 5ioctl(5, 0x80041272, 0xbfffe124) = -
1 EINVAL (Invalid argument)write(2, "mkfs.jfs: can't determine device"..., ..._exit(1) = ?
清单 6 显示 ioctl 调用导致用来格式化分区的 mkfs 程序失败。 ioctl BLKGETSIZE64 失败。（ BLKGET-SIZE64 在调用 ioctl的源代码中定义。) BLKGETSIZE64 ioctl 将被添加到 Linux 中所有的设备，而在这里，逻辑卷管理器还不支持它。因此，如果BLKGETSIZE64 ioctl 调用失败，mkfs 代码将改为调用较早的 ioctl 调用；这使得 mkfs 适用于逻辑卷管理器。
OOPS（也称 Panic）消息包含系统错误的细节，如 CPU 寄存器的内容等。是内核告知用户有不幸发生的最常用的方式。
内核只能发布OOPS，这个过程包括向终端上输出错误消息，输出寄存器保存的信息，并输出可供跟踪的回溯线索。通常，发送完OOPS之后，内核会处于一种不稳定的状态。
OOPS的产生有很多可能原因，其中包括内存访问越界或非法的指令等。
※ 作为内核的开发者，必定将会经常处理OOPS。
※ OOPS中包含的重要信息，对所有体系结构的机器都是完全相同的：寄存器上下文和回溯线索（回溯线索显示了导致错误发生的函数调用链）。
ksymoops
在 Linux 中，调试系统崩溃的传统方法是分析在发生崩溃时发送到系统控制台的 Oops 消息。一旦您掌握了细节，就可以将消息发送到 ksymoops 使用程序，它将试图将代码转换为指令并将堆栈值映射到内核符号。
※ 如：回溯线索中的地址，会通过ksymoops转化成名称可见的函数名。
ksymoops需要几项内容：Oops 消息输出、来自正在运行的内核的 System.map 文件，还有 /proc/ksyms、vmlinux和/proc/modules。
关于如何使用 ksymoops，内核源代码
/usr/src/linux/Documentation/oops-tracing.txt 中或 ksymoops 手册页上有完整的说明可以参考。Ksymoops 返回编代码部分，指出发生错误的指令，并显示一个跟踪部分表明代码如何被调用。
首先，将 Oops 消息保存在一个文件中以便通过 ksymoops 使用程序运行它。清单 7 显示了由安装 JFS 文件系统的 mount命令创建的 Oops 消息。
清单 7. ksymoops 处理后的 Oops 消息
ksymoops 2.4.0 on i686 2.4.17. Options used... 15:59:37 sfb1 kernel: Unable to handle kernel NULL pointer dereference atvirtual address 0000000... 15:59:37 sfb1 kernel: c01588fc... 15:59:37 sfb1 kernel: *pde = 0000000... 15:59:37 sfb1 kernel: Oops: 0000... 15:59:37 sfb1 kernel: CPU: 0... 15:59:37 sfb1 kernel: EIP: 0010: [jfs_mount+60/704]... 15:59:37 sfb1 kernel: Call Trace: [jfs_read_super+287/688] [get_sb_bdev+563/736] [do_kern_mount+189/336] [do_add_mount+35/208][do_page_fault+0/1264]... 15:59:37 sfb1 kernel: Call Trace: []...... 15:59:37 sfb1 kernel: [>EIP; c01588fc Code; c01588fc 00000000 :Code; c01588fc 6: 55 push %ebp
接下来，您要确定 jfs_mount 中的哪一行代码引起了这个问题。Oops 消息告诉我们问题是由位于偏移地址 3c 的指令引起的。做这件事的办法之一就是对 jfs_mount.o 文件使用 objdump 使用程序，然后查看偏移地址 3c。Objdump 用来反汇编模块函数，看看您的 C 源代码会产生什么汇编指令。清单 8 显示了使用 objdump 后您将看到的内容，接着，我们查看jfs_mount 的 C 代码，可以看到空值是第 109 行引起的。偏移地址 3c 之所以这么重要，是因为 Oops 消息将该处标识为引起问题的位置。
清单 8. jfs_mount 汇编程序清单
109 printk("%d ",*ptr);objdump jfs_mount.ojfs_mount.o: file format elf32-i386Disassembly
of section .text:00000000 : 0:55 push %ebp ... 2c: e8 cf 03 00 00 call
400 31: 89 c3 mov %eax,%ebx 33: 58 pop %eax 34: 85 db test %ebx,%ebx 36: 0f 85
55 02 00 00 jne 291 0x291> 3c: 8b 2d 00 00 00 00 mov 0x0,%ebp kallsyms
开发版2.5内核引入了kallsyms特性，它可以通过定义CONFIG_KALLSYMS编译选项启用。该选项可以载入内核镜像所对应的内存地址的符号名称（即函数名），所以内核可以打印解码之后的跟踪线索。相应，解码OOPS也不再需要System.map和ksymoops工具了。另外， 这样做，会使内核变大些，因为地址对应符号名称必须始终驻留在内核所在内存上。
#cat /proc/kallsyms c0100240 T _stext c0100240 t run_init_process c0100240 T stext c0100269 t init …
什么是 kexec ？
Kexec 是实现 kdump 机制的关键，它包括 2 一是组成部分：一是内核空间的系统调用 kexec_load，负责在生产内核（production kernel 或 first kernel）启动时将捕获内核（capture kernel 或 sencond kernel）加载到指定地址。二是用户空间的工具 kexec-tools，他将捕获内核的地址传递给生产内核，从而在系统崩溃的时候能够找到捕获内核的地址并运行。没有 kexec 就没有 kdump。先有 kexec 实现了在一个内核中可以启动另一个内核，才让 kdump 有了用武之地。kexec 原来的目的是为了节省时间 kernel 开发人员重启系统的时间，谁能想到这个“偷懒”的技术却孕育了最成功的内存转存机制呢？
什么是 kdump ？
Kdump 的概念出现在 2005 左右，是迄今为止最可靠的内核转存机制，已经被主要的 linux™ 厂商选用。kdump是一种先进的基于 kexec 的内核崩溃转储机制。当系统崩溃时，kdump 使用 kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以很小的内存启动以捕获转储镜像。第一个内核保留了内存的一部分给第二个内核启动用。由于 kdump 利用 kexec 启动捕获内核，绕过了 BIOS，所以第一个内核的内存得以保留。这是内核崩溃转储的本质。
kdump 需要两个不同目的的内核，生产内核和捕获内核。生产内核是捕获内核服务的对象。捕获内核会在生产内核崩溃时启动起来，与相应的 ramdisk 一起组建一个微环境，用以对生产内核下的内存进行收集和转存。
如何使用 kdump
构建系统和 dump-capture 内核，此操作有 2 种方式可选：
1）构建一个单独的自定义转储捕获内核以捕获内核转储；
2） 或者将系统内核本身作为转储捕获内核，这就不需要构建一个单独的转储捕获内核。
方法（2）只能用于可支持可重定位内核的体系结构上；目前 i386，x86_64，ppc64 和 ia64 体系结构支持可重定位内核。构建一个可重定位内核使得不需要构建第二个内核就可以捕获转储。但是可能有时想构建一个自定义转储捕获内核以满足特定要求。
如何访问捕获内存
在内核崩溃之前所有关于核心映像的必要信息都用 ELF 格式编码并存储在保留的内存区域中。ELF 头所在的物理地址被作为命令行参数（fcorehdr=）传递给新启动的转储内核。
在 i386 体系结构上，启动的时候需要使用物理内存开始的 640K，而不管操作系统内核转载在何处。因此，这个640K 的区域在重新启动第二个内核的时候由 kexec 备份。
在第二个内核中，“前一个系统的内存”可以通过两种方式访问：
1） 通过 /dev/oldmem 这个设备接口。
一个“捕捉”设备可以使用“raw”（裸的）方式 “读”这个设备文件并写出到文件。这是关于内存的 “裸”的数据转储，同时这些分析 / 捕捉工具应该足够“智能”从而可以知道从哪里可以得到正确的信息。ELF 文件头（通过命令行参数传递过来的 elfcorehdr）可能会有帮助。
2） 通过 /proc/vmcore。
这个方式是将转储输出为一个 ELF 格式的文件，并且可以使用一些文件拷贝命令（比如 cp，scp 等）将信息读出来。同时，gdb 可以在得到的转储文件上做一些调试（有限的）。这种方式保证了内存中的页面都以正确的途径被保存 ( 注意内存开始的 640K 被重新映射了 )。
kdump 的优势
1） 高可靠性
崩溃转储数据可从一个新启动内核的上下文中获取，而不是从已经崩溃内核的上下文。
2） 多版本支持
LKCD(Linux Kernel Crash Dump)，netdump，diskdump 已被纳入 LDPs(Linux Documen-tation Project) 内核。SUSE 和 RedHat 都对 kdump 有技术支持。
配置 kdump
安装软件包和实用程序
Kdump 用到的各种工具都在 kexec-tools 中。kernel-debuginfo 则是用来分析 vmcore 文件。从 rhel5 开始，kexec-tools 已被默认安装在发行版。而 novell 也在 sles10 发行版中把 kdump 集成进来。所以如果使用的是rhel5 和 sles10 之后的发行版，那就省去了安装 kexec-tools 的步骤。而如果需要调试 kdump 生成的 vmcore文件，则需要手动安装 kernel-debuginfo 包。检查安装包操作：
3.3.2 参数相关设置 uli13lp1:/ # rpm -qa|grep kexec kexec-tools-2.0.0-53.43.10 uli13lp1:/ # rpm -qa 'kernel*debuginfo*' kernel-default-debuginfo-3.0.13-0.27.1 kernel-ppc64-debuginfo-3.0.13-0.27.1
系统内核设置选项和转储捕获内核配置选择在《使用 Crash 工具分析 Linux dump 文件》一文中已有说明，在此不再赘述。仅列出内核引导参数设置以及配置文件设置。
1） 修改内核引导参数，为启动捕获内核预留内存
通过下面的方法来配置 kdump 使用的内存大小。添加启动参数”crashkernel=Y@X”，这里，Y 是为 kdump 捕捉内核保留的内存，X 是保留部分内存的开始位置。
对于 i386 和 x86_64, 编辑 /etc/grub.conf, 在内核行的最后添加”crashkernel=128M” 。
对于 ppc64，在 /etc/yaboot.conf 最后添加”crashkernel=128M”。
在 ia64, 编辑 /etc/elilo.conf，添加”crashkernel=256M”到内核行。
2） kdump 配置文件
kdump 的配置文件是 /etc/kdump.conf（RHEL6.2）；/etc/sysconfig/kdump(SLES11 sp2)。每个文件头部都有选项说明，可以根据使用需求设置相应的选项。
启动 kdump 服务
在设置了预留内存后，需要重启机器，否则 kdump 是不可使用的。启动 kdump 服务：
Rhel6.2：
# chkconfig kdump on # service kdump status Kdump is operational # service kdump start
SLES11SP2：
# chkconfig boot.kdump on # service boot.kdump start
测试配置是否有效
可以通过 kexec 加载内核镜像，让系统准备好去捕获一个崩溃时产生的 vmcore。可以通过 sysrq 强制系统崩溃。
# echo c > /proc/sysrq-trigger
这造成内核崩溃，如配置有效，系统将重启进入 kdump 内核，当系统进程进入到启动 kdump 服务的点时，vmcore 将会拷贝到你在 kdump 配置文件中设置的位置。RHEL 的缺省目录是 : /var/crash；SLES 的缺省目录是 : /var/log/dump。然后系统重启进入到正常的内核。一旦回复到正常的内核，就可以在上述的目录下发现 vmcore 文件，即内存转储文件。可以使用之前安装的 kernel-debuginfo 中的 crash 工具来进行分析（crash 的更多详细用法将在本系列后面的文章中有介绍）。
# crash /usr/lib/debug/lib/modules/2.6.17-1.2621.el5/vmlinux /var/crash/2006-08-23-15:34/vmcore crash> bt
载入“转储捕获”内核
需要引导系统内核时，可使用如下步骤和命令载入“转储捕获”内核：
kexec -p --initrd=for-dump-capture-kernel> --args-linux --append="root= init 1 irqpoll"
装载转储捕捉内核的注意事项：
转储捕捉内核应当是一个 vmlinux 格式的映像（即是一个未压缩的 ELF 映像文件），而不能是 bzImage 格式；
默认情况下，ELF 文件头采用 ELF64 格式存储以支持那些拥有超过 4GB 内存的系统。但是可以指定“–elf32-core-headers”标志以强制使用 ELF32 格式的 ELF 文件头。这个标志是有必要注意的，一个重要的原因就是：当前版本的 GDB 不能在一个 32 位系统上打开一个使用 ELF64 格式的 vmcore 文件。ELF32 格式的文件头不能使用在一个“没有物理地址扩展”（non-PAE）的系统上（即：少于 4GB 内存的系统）;
一个“irqpoll”的启动参数可以减低由于在“转储捕获内核”中使用了“共享中断”技术而导致出现驱动初始化失败这种情况发生的概率 ;
Must be specified, the specified format is and the name of the root device to be used. Specifically, you can view the output of the mount command; the "init 1" command will start the "dump capture kernel" into a single-user mode without network support. If you want network support, use "init 3".
postscript
Kdump is a powerful and flexible kernel dump mechanism, and the ability to perform captured kernels in the context of a production kernel is extremely valuable. This article only introduces how to configure kdump in RHEL6.2 and SLES11. I hope it will be helpful to the readers of this article.
The above is the detailed content of 'Technical Tips' Common debugging methods of Linux kernel. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
