dmesg -n 7 能让驱动调试信息显示在控制台，是因为它将 console_loglevel 设为 7，使级别 ≤7 的所有日志（含 KERN_DEBUG）均满足“消息等级 ≤ 控制台级别”的输出条件，从而不再被过滤。
内核日志级别不是“调高就能看到更多”，而是“调低才能让调试信息上控制台”——因为默认的 console_loglevel 是 4（KERN_ERR），而 KERN_DEBUG 是 7，数字越大等级越低，越容易被过滤掉。
为什么 dmesg -n 7 能让驱动调试信息出来
执行 dmesg -n 7 实际是把 /proc/sys/kernel/printk 的第一个值（即 console_loglevel）设为 7，意味着“控制台只拒绝等级
- 常见错误现象：你加了
printk(KERN_DEBUG "xxx");，但控制台/串口完全没输出 → 很可能console_loglevel还是默认的 4 或更低 - 验证方式：运行
cat /proc/sys/kernel/printk，输出形如4 4 1 7；第一个数就是当前控制台阈值 - 注意：这个操作只影响 控制台输出，不影响
dmesg命令本身能读到的内容（后者由default_message_loglevel控制） - 临时生效即可，别急着写进启动参数——多数调试场景不需要重启，
dmesg -n 7+dmesg -w组合足够定位问题
永久修改要改 GRUB 参数，但别直接加 loglevel=7
在 /etc/default/grub 中修改 GRUB_CMDLINE_LINUX 时，loglevel=7 看似合理，但实际效果受限于内核早期初始化阶段的 console 初始化顺序。更可靠的是显式指定 console_loglevel：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 正确写法示例：
GRUB_CMDLINE_LINUX="quiet loglevel=4 console_loglevel=7" -
quiet抑制 splash 和部分 early boot 冗余，loglevel=4影响内核消息缓冲区默认级别，console_loglevel=7才真正决定控制台显示上限 - 改完必须运行
sudo grub-mkconfig -o /boot/grub/grub.cfg，否则不生效 - 风险提示：生产环境长期设为 7 可能导致串口刷屏、嵌入式设备 buffer 溢出或干扰 watchdog 超时判断
想屏蔽某类日志？别动全局级别，用 rsyslog 过滤更安全
如果你只是想让 kern.* 不上 /dev/console，但又希望 dmesg 和 journal 里保留完整记录，硬调 console_loglevel 是粗暴方案。rsyslog 提供精准路由：
- 编辑
/etc/rsyslog.d/50-kern-filter.conf，添加：kern.* /var/log/kern.log（存盘）+~（丢弃） - 或者只过滤警告以上：
kern.warning /dev/console，这样KERN_INFO和KERN_DEBUG就不会刷屏 - 生效前务必
sudo systemctl restart rsyslog，且确认ForwardToConsole=yes在/etc/systemd/journald.conf中未被禁用，否则 rsyslog 规则无效 - 优势：不影响内核日志缓冲区内容，
dmesg仍可查全量，只是控制台变干净
最常被忽略的一点：很多驱动调试信息在模块加载前就结束了（比如 probe 阶段失败），此时 dmesg -n 7 已来不及捕获——必须在 insmod 前就调好级别，或用 journalctl -k -o cat -b 查本轮启动的完整内核日志。
