嵌入式Linux驱动调试：printk的9个高阶用法，最后一个是救命级
嵌入式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了。
大多数嵌入式工程师做调试的经典操作：
#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个级别，从高到低：
| 级别 | 宏 | 含义 |
|---|---|---|
| 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：
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的默认值
实战用法：
# 只打印错误以上的消息（生产环境）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优势：
- 自动带上设备名称，多设备时一眼看出是哪个实例
- 支持动态调试（
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：
// 配置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倍。
记住最核心的原则：
- 不要直接printk— 用dev_dbg/pr_debug，配合dynamic debug控制
- 不要污染串口— 生产环境把console_loglevel设为3
- 不要手动注释代码— 用运行时开关
- 不要等系统挂了才想怎么调试— 提前配好nmi_watchdog
嵌入式开发最大的成本不是硬件，不是软件，是**“等”**——等编译、等烧录、等复现、等日志。
printk用好了，能让你少等至少一半的时间。