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 2024] nvme 0000:01:00.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) [Mon Apr 1 10:22:34 2024] nvme 0000:01:00.0: device has been reset
真正难的不是命令怎么敲，而是判断哪一行是“果”、哪一行是“因”。比如看到 device has been reset，得往回翻 3～5 秒找 PCIe Bus Error 或 I/O timeout 才能定位到物理链路问题——缓冲区太小、没开 -T、没设 -l，都会让这个链条断掉。
