嵌入式Linux驱动调试：printk的9个高阶用法，最后一个是救命级

嵌入式Linux驱动调试：printk的9个高阶用法，最后一个是救命级

一句话总结：printk不只是printk——掌握这些技巧，你能把内核日志从"噪音"变成"手术刀"。

做嵌入式Linux驱动开发的人，90%的时间都在跟printk打交道。

但我见过太多人只会两种printk用法：

1. printk(KERN_INFO "xxx = %d\n", xxx);
2. printk(KERN_ERR "error: %d\n", ret);

然后出了问题只会用dmesg看日志，满屏的打印看到眼瞎。

今天我把自己积累的一些printk高阶用法分享出来。每一个都是我在真实项目中验证过的，能让你少掉很多头发。

技巧一：用动态调试（Dynamic Debug）代替手动开关

这是最基础也是最重要的技巧——别再手动注释掉printk了。

大多数嵌入式工程师做调试的经典操作：

#defineDEBUG#ifdefDEBUGprintk(KERN_DEBUG"fifo_write: offset=%d\n",off);#endif

调试完了，把#define DEBUG注释掉。过两周又出问题了，再取消注释，编译，烧录，复现…

你一天的时间就浪费在"注释-编译-烧录-复现"这个循环里了。

正确的做法是用内核的动态调试机制（Dynamic Debug）：

pr_debug("fifo_write: offset=%d\n",off);

然后在运行时动态控制：

# 打开某个文件的全部调试信息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个级别，从高到低：

关键配置是/proc/sys/kernel/printk：

cat/proc/sys/kernel/printk# 输出: 7 4 1 7# ^console ^default ^min ^console_loglevel

这四个数字分别是：

1. console_loglevel：比这个数字高的消息会打印到控制台
2. default_message_loglevel：没指定级别的printk默认使用这个
3. minimum_console_loglevel：console_loglevel能设置的最小值
4. default_console_loglevel：console_loglevel的默认值

实战用法：

# 只打印错误以上的消息（生产环境）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倍于串口吞吐能力。

内核提供了限速版本：

printk_ratelimited(KERN_INFO"spi_transfer: %d bytes\n",len);

默认配置是：5秒内最多打印10条，超出的丢弃。

也可以自定义：

// 在文件开头定义自己的限速参数staticDEFINE_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 — 分步打印一行日志

当你需要在一个循环里打印数组或者缓冲区的完整内容时：

// 错误的做法——每个元素一行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输出：

charhexbuf[256];intpos=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自带时间戳：

# 在printk消息前加上相对时间戳（从系统启动开始的秒数.微秒）echo"Y">/sys/module/printk/parameters/time# 或者直接在kernel cmdline加# printk.time=y

效果：

[ 5.123456] dwc_otg_hcd: USB reset on port 1 [ 5.234567] dwc_otg_hcd: USB reset done

这样你就能精确知道两个事件之间的时间差（在微秒级别）。

更高级的做法——用trace_printk代替printk做性能测量：

// 比printk快100倍以上，适合高频调用场景trace_printk("irq_handler: took %lu us\n",delta);

通过/sys/kernel/debug/tracing/trace查看输出。这是printk的替代方案中最轻量级的。

技巧六：hex_dump — 协议调试神器

调试I2C/SPI/USB这类总线协议时，经常需要查看原始数据内容。

传统做法：

for(i=0;i<len;i++)printk(KERN_DEBUG"buf[%d] = 0x%02x\n",i,buf[i]);

内核提供了专用函数：

print_hex_dump(KERN_DEBUG,"i2c tx: ",DUMP_PREFIX_OFFSET,16,1,tx_buf,tx_len,true);

输出效果：

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 — 谁在调用我？

有时候你打开了一个驱动，发现某个函数被莫名其妙地调用了。你想知道是谁调的，怎么办？

dump_stack();

输出：

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天的代码逻辑图都有效。

搭配技巧五的时间戳：

if(delta>100)dump_stack();// 只有延迟超过100us才打印调用栈

技巧八：dev_dbg/dev_err — 比printk更专业

驱动开发中，最好用dev_dbg/dev_err/dev_info系列函数，而不是裸printk：

// 不推荐printk(KERN_ERR"my_i2c_probe: i2c_add_driver failed\n");// 推荐dev_err(&i2c_client->dev,"i2c_add_driver failed\n");

输出效果：

[ 12.345678] my_i2c_device i2c-0: i2c_add_driver failed

优势：

1. 自动带上设备名称，多设备时一眼看出是哪个实例
2. 支持动态调试（dev_dbg可以被dynamic debug控制）
3. 代码更干净，更符合内核编码规范
4. 一致性——所有内核驱动都用这套接口

我见过最混乱的项目：一个驱动里混用了printk、pr_info、dev_err、print_msg（自己封装的）四种打印方式，后来排查问题时队友直接崩溃。

统一用dev_xxx系列，跟内核社区保持一致。

技巧九：最后一个是救命级 — printk死锁与NMI panic

最最最危险的情况：系统已经死了，但你想知道死在哪。

正常情况下，printk要用到自旋锁（console_lock）来保护串口输出。但如果系统是在持有这个锁的时候死锁的，你的printk永远也打不出来。

这时候你需要NMI（Non-Maskable Interrupt）printk：

// 配置NMI watchdogecho1>/proc/sys/kernel/nmi_watchdog echo10>/proc/sys/kernel/panic// 或者在内核cmdline加上// nmi_watchdog=1 panic=10

当系统死锁超过10秒，NMI watchdog会触发panic，然后打印一个"神奇"的backtrace——即使console_lock被死锁持有，NMI中断也能绕过它直接写串口。

# 模拟死锁echoc>/proc/sysrq-trigger

或者更优雅地——用SysRq键：

# 触发一次完整的dumpechot>/proc/sysrq-trigger# 显示所有任务状态echow>/proc/sysrq-trigger# 显示D状态（不可中断睡眠）任务echol>/proc/sysrq-trigger# 显示所有CPU的backtrace

如果硬件串口可用，按Alt+SysRq+t（嵌入式设备上通常是Alt+PrintScreen+t）。

这个技巧在量产现场救过我两次——一次是I2C总线死锁，一次是中断处理函数里调了msleep导致系统挂死。没有这个技巧，我只能飞过去用JTAG连板子看，成本差一个数量级。

完整决策流程图

最后

printk看着简单，但真正用好的人不多。这9个技巧如果你能掌握一半以上，你的kernel调试效率至少提升3倍。

记住最核心的原则：

1. 不要直接printk— 用dev_dbg/pr_debug，配合dynamic debug控制
2. 不要污染串口— 生产环境把console_loglevel设为3
3. 不要手动注释代码— 用运行时开关
4. 不要等系统挂了才想怎么调试— 提前配好nmi_watchdog

嵌入式开发最大的成本不是硬件，不是软件，是**“等”**——等编译、等烧录、等复现、等日志。

printk用好了，能让你少等至少一半的时间。