dmesg是内核环形缓冲区快照，需时间、级别、关键词三重过滤才能定位硬件问题；-t时间易失准，推荐--time-format=iso或-dmesg -h；应优先筛选err/warn级日志并结合硬件关键词分析，配合lspci、smartctl等工具交叉验证。
dmesg 是内核环形缓冲区的快照，不是“查硬件错”的开关，不加筛选基本没法用。它能抓到驱动 probe 失败、PCIe 链路重训练、内存 ECC 上报、网卡 PHY 超时这些底层信号，但必须配合时间、级别、关键词三重过滤，否则等于在日志海里捞针。
为什么 dmesg -T 显示的时间经常不准
它把内核启动后的相对秒数（比如 [ 12.345678]）硬加上当前系统时间来反推“当时几点”，一旦系统启动后发生过 NTP 大步长校正、手动 date 修改、或运行在虚拟机里，这个换算就崩了——可能早 8 分钟，也可能倒退 3 秒。
- 检查是否失准：对比
dmesg | head -1和dmesg -T | head -1的时间差 - 更稳的替代：用
dmesg --time-format=iso，它读的是内核写日志时的真实时间戳，输出如2026-06-10T16:22:03.456789 - 老内核没
--time-format？改用dmesg -H（Linux 5.7+），自带倒序+颜色+稳定时间格式
怎么快速筛出真硬件问题，而不是启动杂讯
默认 dmesg 输出包含大量 info 级别启动信息，硬件故障线索往往藏在 err/warn 级别或特定关键词里。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先过滤级别：
dmesg -l err,warn剔掉 90% 的噪音 - 再加硬件关键词：
dmesg -l err,warn | grep -i "error\|fail\|timeout\|reset\|ecc\|nvme\|ata\|pcie\|thermal" - 重点盯成簇出现的日志：比如连续几条
nvme0n1: I/O timeout后跟nvme 0000:01:00.0: reset controller，大概率是链路不稳定，不是盘坏了 - 别只搜 “error”：像
link down、no carrier、PHY status changed这些物理层信号，不带 error 字眼但就是硬件链路断了
实时监控硬件事件，别等出事再翻日志
USB 拔插、网卡 link flapping、NVMe 驱动重置，都是毫秒级事件，等你敲完 dmesg | grep，日志早被刷没了。
- 用
dmesg -w实时流式监听（-f已弃用，别用） - 组合过滤实时看：
dmesg -w | grep -i "usb\|nvme\|ata\|link.*down\|phy" - 复现问题前先清空缓冲区并存档：
dmesg > /tmp/dmesg-before.log && dmesg -c，避免关键上下文被覆盖 - 注意权限：RHEL/CentOS 8+ 默认
kernel.dmesg_restrict=1，普通用户看不到寄存器值等字段，需临时放开
真正难的不是命令怎么写，而是哪条日志该信、哪条该忽略。比如 ACPI: EC: GPE storm detected 多数是 BIOS bug，而连续三次 buffer I/O error on dev nvme0n1 就得立刻停业务查盘。时间戳只是坐标，关键还得结合设备型号（lspci -s 0000:01:00.0 -vv）、固件版本（sudo smartctl -i /dev/nvme0n1）、BMC 日志（ipmitool sel list）交叉印证——dmesg 提供的是第一声警报，不是最终诊断书。
