嵌入式Linux驱动调试：printk的9个高阶用法，最后一个是救命级
一句话总结：printk不只是printk------掌握这些技巧，你能把内核日志从"噪音"变成"手术刀"。
做嵌入式Linux驱动开发的人，90%的时间都在跟printk打交道。
但我见过太多人只会两种printk用法：
printk(KERN_INFO "xxx = %d\n", xxx);printk(KERN_ERR "error: %d\n", ret);
然后出了问题只会用dmesg看日志，满屏的打印看到眼瞎。
今天我把自己积累的一些printk高阶用法分享出来。每一个都是我在真实项目中验证过的，能让你少掉很多头发。
技巧一：用动态调试（Dynamic Debug）代替手动开关
这是最基础也是最重要的技巧------别再手动注释掉printk了。
大多数嵌入式工程师做调试的经典操作：
c
#define DEBUG
#ifdef DEBUG
printk(KERN_DEBUG "fifo_write: offset=%d\n", off);
#endif调试完了，把#define DEBUG注释掉。过两周又出问题了，再取消注释，编译，烧录，复现...
你一天的时间就浪费在"注释-编译-烧录-复现"这个循环里了。
正确的做法是用内核的动态调试机制（Dynamic Debug）：
c
pr_debug("fifo_write: offset=%d\n", off);然后在运行时动态控制：
bash
# 打开某个文件的全部调试信息
echo 'file fifo.c +p' > /sys/kernel/debug/dynamic_debug/control
# 打开某个函数的调试信息
echo 'func fifo_write +p' > /sys/kernel/debug/dynamic_debug/control
# 带条件的调试
echo 'file fifo.c line 123 +p' > /sys/kernel/debug/dynamic_debug/control
# 关闭
echo 'file fifo.c -p' > /sys/kernel/debug/dynamic_debug/control优势：不需要重新编译内核，不需要重启设备，线上也能开日志。用完关掉，不占用生产环境的性能。
注意 ：需要在编译内核时打开
CONFIG_DYNAMIC_DEBUG。大部分嵌入式Linux发行版都默认开了，但如果你是自己裁剪的内核，记得加上。
技巧二：用printk的级别控制过滤噪音
printk有8个级别，从高到低：
| 级别 | 宏 | 含义 |
|---|---|---|
| 0 | KERN_EMERG | 紧急消息 |
| 1 | KERN_ALERT | 需要立即处理 |
| 2 | KERN_CRIT | 严重错误 |
| 3 | KERN_ERR | 错误 |
| 4 | KERN_WARNING | 警告 |
| 5 | KERN_NOTICE | 通知 |
| 6 | KERN_INFO | 信息 |
| 7 | KERN_DEBUG | 调试 |
关键配置是/proc/sys/kernel/printk：
bash
cat /proc/sys/kernel/printk
# 输出: 7 4 1 7
# ^console ^default ^min ^console_loglevel这四个数字分别是：
- console_loglevel：比这个数字高的消息会打印到控制台
- default_message_loglevel：没指定级别的printk默认使用这个
- minimum_console_loglevel：console_loglevel能设置的最小值
- default_console_loglevel：console_loglevel的默认值
实战用法：
bash
# 只打印错误以上的消息（生产环境）
echo "3 4 1 7" > /proc/sys/kernel/printk
# 全部打开（调试时）
echo "8 4 1 7" > /proc/sys/kernel/printk
# 只打印你自己的驱动日志（配合自定义级别）
echo "3 4 1 7" > /proc/sys/kernel/printk这样你就不用在一堆"怪异鸡肋"的内核日志里大海捞针了。
技巧三：printk_ratelimited --- 防止"日志风暴"
嵌入式设备上最常见的调试事故：你在一个中断处理函数或者高频调用的函数里加了一行printk，然后------
boom！系统直接卡死。
不是printk本身卡死，而是你的串口/控制台被海量的日志撑爆了。特别是在115200波特率下，printk的传输速度大约只有11KB/s。如果你在1ms调一次的中断里打印一行50字节的日志，瞬间就有50KB/s的日志量------4倍于串口吞吐能力。
内核提供了限速版本：
c
printk_ratelimited(KERN_INFO "spi_transfer: %d bytes\n", len);默认配置是：5秒内最多打印10条，超出的丢弃。
也可以自定义：
c
// 在文件开头定义自己的限速参数
static DEFINE_RATELIMIT_STATE(my_ratelimit, 5 * HZ, 10);
if (__ratelimit(&my_ratelimit))
printk(KERN_INFO "i2c_transfer timeout: addr=0x%02x\n", addr);这个技巧能救你一命------我见过不止一个同事因为在中断里加printk把系统打崩溃了，然后怀疑是硬件问题排查了两天。
技巧四：pr_cont --- 分步打印一行日志
当你需要在一个循环里打印数组或者缓冲区的完整内容时：
c
// 错误的做法------每个元素一行
for (i = 0; i < len; i++)
printk(KERN_DEBUG "buf[%d] = 0x%02x\n", i, buf[i]);
// 正确的做法------一行打印完
for (i = 0; i < len; i++)
pr_cont("%02x ", buf[i]);
printk("\n");pr_cont会延续上一行printk的输出，而不是另起一行。
但是要注意：pr_cont在多核系统中可能会被其他CPU的printk打断，导致输出错乱。如果实在需要保证完整性，可以先把内容拼接到一个局部缓冲区里，再用一次printk输出：
c
char hexbuf[256];
int pos = 0;
for (i = 0; i < min(len, 64); i++)
pos += snprintf(hexbuf + pos, sizeof(hexbuf) - pos, "%02x ", buf[i]);
printk(KERN_DEBUG "rx data: %s\n", hexbuf);技巧五：printk + timestamp --- 精确测时
嵌入式调试中非常常见的问题："这个操作到底花了多长时间？"
不要用jiffies手动算时间差------printk自带时间戳：
bash
# 在printk消息前加上相对时间戳（从系统启动开始的秒数.微秒）
echo "Y" > /sys/module/printk/parameters/time
# 或者直接在kernel cmdline加
# printk.time=y效果：
ini
[ 5.123456] dwc_otg_hcd: USB reset on port 1
[ 5.234567] dwc_otg_hcd: USB reset done这样你就能精确知道两个事件之间的时间差（在微秒级别）。
更高级的做法------用trace_printk代替printk做性能测量：
c
// 比printk快100倍以上，适合高频调用场景
trace_printk("irq_handler: took %lu us\n", delta);通过/sys/kernel/debug/tracing/trace查看输出。这是printk的替代方案中最轻量级的。
技巧六：hex_dump --- 协议调试神器
调试I2C/SPI/USB这类总线协议时，经常需要查看原始数据内容。
传统做法：
c
for (i = 0; i < len; i++)
printk(KERN_DEBUG "buf[%d] = 0x%02x\n", i, buf[i]);内核提供了专用函数：
c
print_hex_dump(KERN_DEBUG, "i2c tx: ", DUMP_PREFIX_OFFSET,
16, 1, tx_buf, tx_len, true);输出效果：
bash
i2c tx: 00000000: 12 34 ab cd 78 9a bc de f0 12 34 56 78 9a ab cd
i2c tx: 00000010: 12 34 56 78参数含义：
DUMP_PREFIX_OFFSET：显示偏移地址16：每行16字节1：每个字节用1列true：显示ASCII字符
这个函数在调试通信协议时，比任何调试器都好用。
技巧七：dump_stack --- 谁在调用我？
有时候你打开了一个驱动，发现某个函数被莫名其妙地调用了。你想知道是谁调的，怎么办？
c
dump_stack();输出：
yaml
CPU: 0 PID: 123 Comm: kworker/u2:1 Not tainted 5.10.120 #1
Hardware name: MyBoard (DT)
Call trace:
dump_backtrace+0x0/0x1a0
show_stack+0x20/0x30
dump_stack+0x74/0x90
my_driver_write+0x3c/0x100 // <- 当前函数
vfs_write+0xc4/0x1e0
ksys_write+0x64/0xe0
__arm64_sys_write+0x1c/0x30
el0_svc_common+0x80/0x180
do_el0_svc+0x24/0x90
el0_sync_handler+0x88/0x100
el0_sync+0x158/0x17c一次调用就暴露了调用链，比你看3天的代码逻辑图都有效。
搭配技巧五的时间戳：
c
if (delta > 100)
dump_stack(); // 只有延迟超过100us才打印调用栈技巧八：dev_dbg/dev_err --- 比printk更专业
驱动开发中，最好用dev_dbg/dev_err/dev_info系列函数，而不是裸printk：
c
// 不推荐
printk(KERN_ERR "my_i2c_probe: i2c_add_driver failed\n");
// 推荐
dev_err(&i2c_client->dev, "i2c_add_driver failed\n");输出效果：
css
[ 12.345678] my_i2c_device i2c-0: i2c_add_driver failed优势：
- 自动带上设备名称，多设备时一眼看出是哪个实例
- 支持动态调试 （
dev_dbg可以被dynamic debug控制） - 代码更干净，更符合内核编码规范
- 一致性------所有内核驱动都用这套接口
我见过最混乱的项目：一个驱动里混用了printk、pr_info、dev_err、print_msg（自己封装的）四种打印方式，后来排查问题时队友直接崩溃。
统一用dev_xxx系列，跟内核社区保持一致。
技巧九：最后一个是救命级 --- printk死锁与NMI panic
最最最危险的情况：系统已经死了，但你想知道死在哪。
正常情况下，printk要用到自旋锁（console_lock）来保护串口输出。但如果系统是在持有这个锁的时候死锁的，你的printk永远也打不出来。
这时候你需要NMI（Non-Maskable Interrupt）printk：
c
// 配置NMI watchdog
echo 1 > /proc/sys/kernel/nmi_watchdog
echo 10 > /proc/sys/kernel/panic
// 或者在内核cmdline加上
// nmi_watchdog=1 panic=10当系统死锁超过10秒，NMI watchdog会触发panic，然后打印一个"神奇"的backtrace------即使console_lock被死锁持有，NMI中断也能绕过它直接写串口。
bash
# 模拟死锁
echo c > /proc/sysrq-trigger或者更优雅地------用SysRq键：
bash
# 触发一次完整的dump
echo t > /proc/sysrq-trigger # 显示所有任务状态
echo w > /proc/sysrq-trigger # 显示D状态（不可中断睡眠）任务
echo l > /proc/sysrq-trigger # 显示所有CPU的backtrace如果硬件串口可用，按Alt+SysRq+t（嵌入式设备上通常是Alt+PrintScreen+t）。
这个技巧在量产现场救过我两次 ------一次是I2C总线死锁，一次是中断处理函数里调了msleep导致系统挂死。没有这个技巧，我只能飞过去用JTAG连板子看，成本差一个数量级。
完整决策流程图
最后
printk看着简单，但真正用好的人不多。这9个技巧如果你能掌握一半以上，你的kernel调试效率至少提升3倍。
记住最核心的原则：
- 不要直接printk --- 用dev_dbg/pr_debug，配合dynamic debug控制
- 不要污染串口 --- 生产环境把console_loglevel设为3
- 不要手动注释代码 --- 用运行时开关
- 不要等系统挂了才想怎么调试 --- 提前配好nmi_watchdog
嵌入式开发最大的成本不是硬件，不是软件，是**"等"**------等编译、等烧录、等复现、等日志。
printk用好了，能让你少等至少一半的时间。