dmesg需结合-T、-w、-l等参数精准排查：用dmesg -T看时间戳，dmesg -w | grep实时捕获硬件事件，dmesg -l指定日志级别，避免缓冲区过小导致信息丢失。

直接看内核日志：dmesg 命令最简用法

dmesg 默认输出全部内核环形缓冲区（ring buffer）内容，但通常刷屏太快、干扰多。实际排查硬件或驱动问题时，应配合过滤和时间控制——不加参数直接跑 dmesg 很可能错过关键信息。

• 首次查看建议加 -T 显示本地时间戳：dmesg -T
• 只看最近 20 行：用 dmesg | tail -n 20（注意管道会丢失颜色和部分元数据，但够用）
• 清空缓冲区前先备份：dmesg > /tmp/dmesg.log，避免误执行 dmesg -C 后无从回溯
• 某些嵌入式系统或容器环境里 dmesg 可能被禁用或返回空，此时需确认是否启用了 CONFIG_PRINTK 内核配置

按关键字实时监控硬件事件：grep + --follow

USB 插拔、磁盘识别、网卡重置这类瞬态事件，必须用实时跟踪方式捕获。单纯翻历史日志容易漏掉刚发生的那一行。

• 监听新出现的 USB 设备：dmesg -w | grep -i "usb\|xhci\|ehci"
• 关注 NVMe 盘异常：dmesg -w | grep -i "nvme\|timeout\|reset"
• -w（即 --follow）比老版本的 -f 更可靠，它会在缓冲区翻转时自动续读，不会中断
• 避免用 tail -f /var/log/kern.log 替代——该文件依赖 rsyslog 转发，有延迟且可能丢日志；dmesg -w 是直接读内核缓冲区，零延迟

日志级别与过滤：理解 loglevel 参数的实际影响

内核日志分 8 级（0=emerg 到 7=debug），但默认只显示 4（warning）及以上。很多驱动调试信息（如 probe 流程）是 KERN_DEBUG（级别 7），不显式设置就看不到。

• 显示所有级别（含 debug）：dmesg -l emerg,alert,crit,err,warn,notice,info,debug
• 只看错误和警告：dmesg -l err,warn
• 临时提升内核 loglevel（需 root）：sudo dmesg -n 8，但重启后失效；持久化要改 /proc/sys/kernel/printk 或内核启动参数 loglevel=8
• 注意：有些厂商驱动（如 NVIDIA）会绕过标准 printk，它们的日志可能不出现在 dmesg 中，得查专用工具（如 nvidia-bug-report.sh）

日志被截断或丢失？检查 ring buffer 大小和覆盖策略

内核缓冲区默认只有 16KB（旧内核）或 64KB（5.4+），高频日志（如频繁中断、DMA 错误）极易被覆盖。看到 “Some messages are lost.” 就说明已经丢了。

• 查当前大小：cat /proc/sys/kernel/dmesg_restrict（0=普通用户可读，1=仅 root）和 cat /proc/sys/kernel/printk（第四个数字是控制台 loglevel）
• 增大缓冲区（需编译内核时设置）：CONFIG_LOG_BUF_SHIFT=18（256KB），但运行时无法调整
• 启用日志持久化：确保 rsyslog 或 journald 正常工作，并配置 imkmsg 模块（rsyslog）或 ForwardToKernel=yes（journald）
• 紧急抓取完整日志：用 dmesg -x -T --color=always | less -R，-x 显示优先级标签，less -R 保留颜色，方便快速定位 error/warning 行

dmesg -T -l err,warn | head -n 10
[Mon Apr  1 10:22:34 2025] nvme 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)
[Mon Apr  1 10:22:34 2025] nvme 0000:01:00.0: device has been reset

真正难的不是命令怎么敲，而是判断哪一行是“果”、哪一行是“因”。比如看到 device has been reset，得往回翻 3～5 秒找 PCIe Bus Error 或 I/O timeout 才能定位到物理链路问题——缓冲区太小、没开 -T、没设 -l，都会让这个链条断掉。