跳到主要内容

3.4 剩余的 printk 杂项与终极调试手段

走到这里，我们其实已经覆盖了 90% 的日常调试场景。从最基础的 printk，到分级的 pr_debug，再到用来防止刷屏的 ratelimit，以及那个像上帝视角一样的 Dynamic Debug。你的工具箱里现在应该有一套相当趁手的家伙了。

但内核的世界从来不是平坦的。有些边缘情况——比如内核刚启动还没准备好控制台的时候？比如系统已经彻底挂掉连键盘都按不动的时候？又或者你想从用户空间往内核日志里塞点东西做标记？

还有一些零散但极其有用的技巧，比如「只打印一次」的宏，或者用来优雅地转储内存块的工具。如果不把这些收尾工作做了，你的调试技能树就永远缺几个关键节点。

这一节，我们就来把这些零散的「大招」收集齐。

3.4.1 控制台初始化前的呐喊——Early printk​

你肯定遇到过这种时刻：内核刚启动了几行，屏幕突然黑了，串口也没输出。你心里清楚，问题出在极早期的初始化代码里——可能是某个驱动探测失败，或者是内存映射出了鬼。

但问题是，那时候真正的控制台还没初始化好。你发出了 printk，但没人听。这些消息静静地躺在内存里的环形缓冲区中，而你没有任何办法看到它们。

这就像是飞机起飞前引擎故障，黑匣子还没开始录音。

什么是控制台？​

在解决这个问题之前，我们先搞清楚「控制台」到底是个什么东西。

在传统的 Linux 概念里，控制台是内核直接输出的终端，也就是那个 /dev/console。在图形界面还没接管一切的年代，这就是超级用户登录的那个纯文本窗口。

有趣的是，Linux 可以定义多种「控制台」：

  • TTY：比如 /dev/ttyS0 这种串口设备。
  • VGA 文本模式：古老的黑白蓝屏显示器。
  • Framebuffer：图形化控制台。
  • USB 串口：嵌入式开发板常见。

当你用一根 USB 转 TTL 串口线把树莓派连到笔记本上，用 minicom 或者 screen 连上去时，你看到的就是 tty 设备。这是开发者最亲密的朋友。

早期打印的困境​

问题就出在「时机」上。

在内核启动的极早期，它自己还是个婴儿，连走路都还没学会，更别提操作显卡或者复杂的串口驱动了。这时候如果内核崩溃了，普通的 printk 根本无法到达物理设备（因为驱动没跑起来）。

你只能眼睁睁看着系统卡死，而唯一的线索——那些至关早期的报错信息——被锁在了还没连通的管道里。

解决方案：early_printk()​

这就需要动用「旁门左道」了。内核社区提供了一个叫做 early printk 的机制。

它的原理听起来非常极客：不依赖任何复杂的驱动，直接通过最底层、最原始的硬件操作，把字符一个一个地「敲」到串口线上（或者直接写显存）。这叫 bit-banging。这就是为什么它叫 early_——因为它不仅快，而且极其原始，不需要太多基础设施。

要启用它，你需要完成三步走：

1. 配置内核（一次性）​

这东西是架构相关的。

  • x86：开启 CONFIG_EARLY_PRINTK=y。路径通常在 Kernel hacking -> x86 Debugging -> Early printk。文档里通常会警告你：这东西格式不正规，还会干扰正常的日志，除非你在调试启动问题，否则别开。
  • ARM (32位)：选项叫 CONFIG_DEBUG_LL，路径在 Kernel hacking -> Kernel low-level debugging functions。进入子菜单，你还得选具体的调试端口（是 EmbeddedICE DCC 还是 UART）。

2. 启动参数​

光编译进去还不行，你得在启动的时候告诉内核要用它。在 bootargs 里加上：

earlyprintk=serial,ttyS0,115200

或者更简单的 x86 VGA：

earlyprintk=vga

内核文档里有一大堆参数组合（什么 sclp, xen, dbgp），但核心意思就是：指定一个设备，指定波特率，告诉内核「把早期的字儿吐这儿」。

还有一个好用的参数叫 keep。加上它之后，即使真正的控制台（比如正常的串口驱动）接手了，早期的这个 early_printk 输出也不会关掉。这在诊断「接管瞬间发生了什么」时非常有用。

3. 代码里调用​

API 非常直观，叫 early_printk()，长得跟 printf 一模一样。

内核代码里就有现成的例子。比如在 kernel/events/core.c 里，如果性能采样的中断处理时间过长，它就会用 early_printk 发出警告：

// kernel/events/core.c
if (!irq_work_queue(&perf_duration_work)) {
    early_printk("perf: interrupt took too long (%lld > %lld), lowering "
                 "kernel.perf_event_max_sample_rate to %d\n",
                 __report_avg, __report_allowed,
                 sysctl_perf_event_sample_rate);
}

这招在调试那些「跑两步就死机」的 Bug 时简直是救命稻草。

3.4.2 给 printk 带上「标签」​

有些错误特别有身份感。如果是固件写错了，你应该骂固件厂商；如果是硬件废了，你应该让人找硬件工程师；如果是某个 API 我不想让你用了，我得告诉你「这玩意过时了」。

内核提供了一组宏，专门用来给 printk 加这种「官方前缀」。

它们定义在 include/linux/printk.h 里：

#define FW_BUG      "[Firmware Bug]: "
#define FW_WARN     "[Firmware Warn]: "
#define FW_INFO     "[Firmware Info]: "

/*
 * HW_ERR
 * Add this to a message for hardware errors, so that user
 * can report it to hardware vendor instead of LKML or software
 * vendor.
 */
#define HW_ERR      "[Hardware Error]: "

/*
 * DEPRECATED
 * Add this to a message whenever you want to warn userspace
 * about the use of a deprecated aspect of an API so they can stop using it
 */
#define DEPRECATED  "[Deprecated]: "

你看那个 HW_ERR 的注释，字里行间都能感觉到维护者的一片苦心：「别发到内核邮件列表了，去找卖硬件的吵架吧」。

用起来也很直接，就像这样：

// drivers/acpi/thermal.c
} else if (tmp <= 2732) {
    pr_warn(FW_BUG "Invalid critical threshold (%llu)\n", tmp);

输出出来就是：

[ 123.456] [Firmware Bug]: Invalid critical threshold (2730)

这种带前缀的日志，在自动化的日志分析系统里特别好识别——一眼就能看出来这是谁的责任。

3.4.3 只说一次——printk_once()​

有些警告很重要，但如果你在一个高频中断或者循环里打印它，你的控制台瞬间就会被淹没，而且系统性能会直线下降。

你想说的是：「嘿，这事儿不对劲，我告诉你一次，你记住，但别让我一直念叨。」

这时候就要用 printk_once()。

它保证这条消息在整个系统运行期间只会被打印一次。不管你调用它一万次，它只吐第一遍。

当然，那一大家子 pr_* 宏都有对应的 _once 版本： pr_err_once(), pr_warn_once(), pr_info_once() 等等。

看个例子，TCP 协议栈里发现了一个不该出现的 SYN 包，这绝对是异常情况，但又不能因为这个把系统搞瘫：

// net/ipv4/tcp.c
if (unlikely(TCP_SKB_CB(skb)->tcp_flags & TCPHDR_SYN))
    pr_err_once("%s: found a SYN, please report !\n", __func__);

如果你是写驱动的，记得用 dev_*_once()。

// drivers/rtc/rtc-mxc_v2.c
if (!--timeout) {
    dev_err_once(dev, "SRTC_LPSCLR stuck! Check your hw.\n");
    return;
}

另外还有一个大招：dev_WARN_ONCE()。这个宏不仅会打印一次，还会像 WARN_ON() 那样，顺手给你 Dump 一个栈轨迹出来。这东西威力很大，用的时候得慎重。

3.4.4 从用户空间往内核喊话——/dev/kmsg​

有时候我们在写自动化测试脚本。脚本在用户空间跑，控制着内核模块的测试流程。

echo "test data 123" > /dev/mydevnode

这时候你会在 dmesg 里看到内核模块的一堆输出。但你有个问题：这一大堆日志里，哪一条是哪个测试用例触发的？

要是能在日志里插个书签就好了。比如在测试用例开始的时候，往内核日志里写一行： my_test_script: start testcase 1。

其实你不用写内核代码来做这件事。内核提供了一个特殊的设备文件：/dev/kmsg。

你可以直接用 echo 往里面写东西：

sudo bash -c "echo \"my_test_script: start testcase 1\" > /dev/kmsg"

这样写进去的消息，默认会被当成 KERN_WARNING（级别 4）。如果你想指定级别，比如 KERN_INFO（级别 6），就在前面加上尖括号：

sudo bash -c "echo \"<6>my_test_script: start testcase 1\" > /dev/kmsg"

然后你在 dmesg 里就能看到：

user  :info  : [33561.862960] my_test_script: start testcase 1

这里有个很有意思的点：一旦消息进了 /dev/kmsg，它就和内核自己生成的 printk 长得一模一样了。你分不出谁是爹谁是娘。

所以，建议加上一个显眼的前缀（比如 @US_TEST@），这样你在翻日志 grep 的时候，能一眼挑出这些你自己注入的标记。

3.4.5 优雅地转储内存——print_hex_dump_bytes()​

最后一个常见需求：我想看某个数据结构或者某个网络包的内容，但我又不想自己写那个恶心循环——什么 for 循环打印十六进制，还要判断是不是可打印字符，对齐还要算半天……

别浪费时间了。内核早就给你准备好了。

print_hex_dump_bytes() 就是专门干这个的。

它的定义很长，但参数解释得很清楚：

/**
 * print_hex_dump_bytes - shorthand form of print_hex_dump() with default params
 * @prefix_str: string to prefix each line with; caller supplies trailing spaces for alignment if desired
 * @prefix_type: controls whether prefix of an offset, address, or none is printed
 *               (%DUMP_PREFIX_OFFSET, %DUMP_PREFIX_ADDRESS, %DUMP_PREFIX_NONE)
 * @buf: data blob to dump
 * @len: number of bytes in the @buf
 */
#define print_hex_dump_bytes(prefix_str, prefix_type, buf, len) \
        print_hex_dump_debug(prefix_str, prefix_type, 16, 1, buf, len, true)

这个宏本质上是对 print_hex_dump_debug() 的封装。注意到了吗？它用的是 _debug 后缀。

这意味着什么？ 意味着它是和 Dynamic Debug 挂钩的！你用得越多，就越能体会到 Dynamic Debug 的威力——这些十六进制转储平时是关着的，不影响性能，关键时刻在 /sys/kernel/debug/dynamic_debug/control 里开一下就行了。

看个无线网卡驱动里的实际用法：

// drivers/net/wireless/ath/ath6kl/debug.c
void ath6kl_dbg_dump(enum ATH6K_DEBUG_MASK mask,
             const char *msg, const char *prefix,
             const void *buf, size_t len)
{
    if (debug_mask & mask) {
        if (msg)
            ath6kl_dbg(mask, "%s\n", msg);
        print_hex_dump_bytes(prefix,
            DUMP_PREFIX_OFFSET, buf, len);
    }
    [...]
}

这段代码跑起来的效果，大概是这样：

00000000: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff  ."3DUw........
00000010: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10  ................

清晰，对齐，还带着 ASCII 显示。调试网络包、DMA 缓冲区的时候，这就是你的眼睛。

3.4.6 绝境求生：崩溃时怎么办？​

如果系统已经彻底挂死了，连 dmesg 都输不出来，连 printk 都调不动了，我们该怎么办？

这里有几招比较「硬核」的备选方案。

Warm Reset 与 Bootloader 偷窥​

有些高级玩法是在系统死机后，做一个「热重启」。

所谓的 Warm Reset，是指重启 CPU，但保持 RAM 内容不掉电。这就像是你电脑死机了，但你没拔电源，内存条里的数据还在。

有些板子上有专门的软复位按键，或者你可以通过 Magic SysRq（这个我们后面会有专门章节讲）来触发。

这时候，如果你能迅速进入 Bootloader（比如 U-Boot）的命令行，你可以利用 Bootloader 的内存查看命令（比如 md - memory display）去读刚才内核日志缓冲区所在的物理地址。

这里有个坑：你在 /proc/kallsyms 里查到的 __log_buf 地址是虚拟地址，Bootloader 只认物理地址。你需要查阅芯片手册，把这个虚拟地址翻译成物理地址。

一旦翻译成功，你用 md 命令一刷，就能看到死机前最后几秒的内核日志。这招虽然冷门，但在「现场复现一次太难了」的场合，能救命。

LED 闪烁调试​

再极端一点，板子连串口都没接，或者连 Bootloader 都挂了怎么办？

回到最原始的方式：GPIO 点灯。

这叫「穷人的 printf」。你在关键的代码路径上把一个 GPIO 口拉高、拉低，外面的 LED 就会闪烁。

  • 初始化阶段闪两下？
  • 中断里闪三下？
  • 死循环里一直亮？

树莓派官方就是这么干的——如果启动失败，红灯会闪烁特定次数来代表错误码。

甚至有人会把 OLED 屏幕接在 I2C 上，直接把错误信息画在屏幕上。虽然听起来很土，但在毫无输出的黑盒设备上，这往往是唯一的线索。

网络控制台​

最后不得不提 netconsole。

这个机制允许把内核的 printk 通过 UDP 包直接扔到局域网里的另一台机器上。

即使本地的硬盘挂了、显卡崩了，只要网卡还能动，日志就能实时发到远程服务器上保存下来。这是调试服务器内核崩溃的神器。关于它的详细配置，我们会在后续章节深入探讨。

本章回响​

这一章我们走得很深，从最简单的插桩打印，一直聊到了系统崩溃后的内存取证。

如果你回头看看，会发现这里有一个清晰的心智模型升级路径：

一开始，你只是把 printk 当作一个更高级别的 printf，用来确认「代码跑没跑到这儿」。

接着，你开始意识到它是内核日志系统的一部分，开始关心日志级别和环形缓冲区。

再后来，你遇到了生产环境的性能问题，学会了限速和动态调试，懂得了在不重启系统的情况下按需开关诊断信息。

最后，在极端的死机场景下，你学会了 Early printk 和 内存转储，这些手段不再只是「看日志」，而是在和硬件的最底层直接对话。

这不仅仅是工具的积累，更是视角的转换。现在的你，不再害怕那个黑漆漆的控制台窗口了。

有了这套插桩和打印的本领，我们就可以放心地进入下一个更宏大的主题了。下一章，我们将介绍内核的 Kprobes 框架——一种比插桩更狠的、可以在运行时动态「hook」任意内核函数的魔法。

到时候，你将真正拥有「透视」内核运行轨迹的能力。

练习题​

练习 1：understanding​

题目：在 Linux 内核编程中，为什么不能直接使用标准 C 库的 printf() 函数，而必须使用 printk()？请简述两者在运行环境及可用性上的核心区别。

答案与解析

答案：Linux 内核不依赖标准 C 库（libc），printf() 是用户空间库函数。printk() 是内核原生的 API，可以在任何上下文（如中断上下文、持有自旋锁时）安全调用，并且直接写入内核环形缓冲区。

解析：这个知识点考察对内核与用户空间界限的理解。printf 依赖于大量的用户空间库支持，而这些在内核环境中是不存在的。printk 不仅实现了格式化输出，还处理了内核特有的日志级别和缓冲机制，且设计为在任何上下文中都安全（SMP-safe），这是普通 printf 无法保证的。

练习 2：application​

题目：假设你正在编写一个网络设备驱动，需要在 open() 函数中打印调试信息。为了使日志更具辨识度并自动包含设备信息，你会选择以下哪种宏？并说明理由。

A. printk(KERN_DEBUG "device opened\n") B. pr_info("device opened\n") C. dev_dbg(&pdev->dev, "device opened\n")

答案与解析

答案：C

解析：在编写设备驱动时，最佳实践是使用 dev_dbg() (或 dev_info() 等 dev_* 宏)。虽然 pr_info 比 printk 更方便，但 dev_* 系列宏的第一个参数是 struct device * 指针。这意味着打印出的日志会自动包含设备的具体信息（如设备名称、总线编号等），这对于区分系统中多个同类设备的日志非常有用。此外，dev_dbg 配合动态调试功能更为强大。

练习 3：application​

题目：你需要在驱动程序中打印一个内核空间指针和一个 16 字节的数据缓冲区内容。出于安全考虑，请写出正确的 printk 代码（假设缓冲区指针为 buf）。

答案与解析

答案：printk("Pointer: %pK, Data: %*ph\n", ptr, 16, buf);

解析：这考察对内核格式说明符的掌握。1. 为了防止内核指针泄露导致的安全漏洞，打印指针应使用 %pK（它会打印哈希后的值）而不是 %px（真实地址），除非处于调试阶段。2. 打印一小段十六进制缓冲区，%*ph 是最高效的方式，其中 * 表示长度，16 是长度值，h 代表小端十六进制字节，buf 是数据源。

练习 4：thinking​

题目：假设你编写的内核模块中有一个高频中断处理函数，里面有一行 printk(KERN_INFO "IRQ fired\n");。请分析这可能带来的两个主要负面影响，并给出至少一种解决方案。

答案与解析

答案：负面影响：1. 性能下降/活锁：高频打印会导致 CPU 大量时间花在 I/O 上，甚至导致系统响应缓慢或死锁。2. 日志泛滥：有用信息被淹没，且容易导致日志缓冲区过快覆盖旧数据（ syslog 爆炸）。解决方案：使用 pr_info_ratelimited() 或者在非关键路径移除/替换为 trace_printk()。

解析：这是一个综合性的工程问题。printk 虽然是同步的，但在中断上下文频繁执行会严重拖慢系统。题目考察了对 printk 代价的认知及对“限速”和“跟踪”机制的理解。printk_ratelimit 机制（通过宏封装）可以限制每秒打印次数，而 trace_printk 则专门用于高频路径，开销极低且不阻塞。

要点提炼​

内核环境下的调试机制远比用户空间复杂，核心工具 printk 并不是简单的 printf 替代品。它通过环形缓冲区暂存日志，并依据 0-7 的日志级别（如 KERN_EMERG 到 KERN_DEBUG）决定消息是否输出到控制台，开发者应优先使用 pr_info() 等封装宏以保持代码整洁。利用 pr_fmt() 可以自动为所有日志添加模块名、函数名和行号前缀，这在多模块并发调试时能极大地提升信息筛选效率。

为了防止高频路径下的调试打印导致系统“活锁”或日志刷屏，内核提供了 pr_*_ratelimited() 系列宏来进行限速保护。这种机制基于 /proc/sys/kernel/printk_ratelimit（时间窗口）和 burst（爆发阈值）来丢弃多余消息，防止关键信息被覆盖。若需在极高频率场景下追踪，应考虑使用 trace_printk()，它直接写入追踪缓冲区，性能损耗远低于 printk。

最强大的调试手段是 Dynamic Debug（动态调试），它允许在不重新编译内核的情况下，运行时动态开启或关闭任何 pr_debug() 或 dev_dbg() 调用点。通过向 /proc/dynamic_debug/control 或 debugfs 写入匹配规范和标志位（如 module misc +p），开发者可以精确控制特定模块、文件甚至行号的日志输出，从而在生产环境中实现“零开销”的按需调试。

针对驱动程序开发，必须使用 dev_*() 系列函数（如 dev_dbg()）替代通用的 pr_*()。这些函数不仅自动携带设备上下文信息（如设备名称、总线编号），还能在有多个同类设备的系统中精确定位问题源头。配合 Dynamic Debug 使用，dev_dbg() 能在不影响性能的前提下提供极其详细的硬件交互日志。

当系统处于启动早期控制台尚未初始化的阶段，普通的 printk 无法输出，此时需依赖 Early printk。该机制绕过复杂的驱动层级，直接通过底层硬件操作向串口或 VGA 显存写入字符，是诊断内核启动崩溃、内存初始化故障等“黑屏”问题的关键救命稻草。启用它通常需要特定的内核配置项（如 CONFIG_EARLY_PRINTK）和启动参数。

编辑此页
最后由 Charliechen114514 于 更新