dmesg读取内核ring buffer（非日志文件），记录启动及运行时事件；-e显示高精度相对时间，-t依赖系统时钟易偏移；--level=err,warn精准过滤，-f实时监听；-c读清、-c只清，均不影响/var/log/dmesg。
直接看启动日志，dmesg 默认输出就是它
系统启动时内核写入 ring buffer 的所有信息，dmesg 不加参数就默认读取这个缓冲区。它不是“日志文件”，而是运行时内存中的环形缓冲区，所以重启后旧内容会被覆盖（除非已落盘到 /var/log/dmesg）。
常见误区是以为 dmesg 只能看开机瞬间——其实只要内核没重启，它持续记录硬件热插拔、驱动加载、OOM killer 触发、磁盘 I/O 错误等事件。比如你刚插了 USB 设备，立刻执行 dmesg 就能看到识别过程。
-
dmesg | head -20查看最早 20 行（通常是 CPU/内存初始化） -
dmesg | tail -20查看最近 20 行（更可能是你关心的设备或错误） -
less /var/log/dmesg看上次启动保存的完整快照（只含 boot 阶段，不包含运行时事件）
dmesg -T 和 dmesg -e 时间戳的区别很关键
dmesg -T 输出的是绝对时间（如 [Sat Apr 19 20:12:03 2026]），但它依赖系统时钟是否在启动后被校准过；如果机器启用了 NTP 或手动改过时间，这个时间可能不准，尤其在 suspend/resume 后容易偏移。
dmesg -e 输出的是相对时间（如 [ +3.245123]），表示距离上一条消息过了多少秒，精度高且稳定，适合分析事件时序，比如判断某块 NVMe 盘是不是在挂载前就报了 timeout 错误。
- 排查硬件响应延迟，优先用
-e - 需要和
journalctl或应用日志对齐时间点，再考虑-T，但务必确认系统未发生过时间跳变 -
dmesg -t（不带时间戳）纯属干扰阅读，基本没实用场景
过滤错误和警告，别只靠 grep 模糊匹配
dmesg | grep -i "error\|warn\|fail" 看似方便，但会漏掉大量真实问题：比如内核用 err 而非 error，或把关键信息藏在设施（facility）字段里。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
正确做法是用 dmesg 原生过滤：
-
dmesg --level=err,warn精确筛选内核定义的错误/警告级别（比字符串匹配可靠得多） -
dmesg -L --level=err加上-L彩色输出，红色高亮一眼定位 err 级别条目 -
dmesg -f -l err实时监听新出现的错误（-f类似tail -f） - 配合设施过滤：
dmesg -f -l err -f kern只看内核自身产生的错误，排除用户空间干扰
dmesg -c 和 dmesg -C 清空操作的实际影响
dmesg -c（小写 c）是“读完即清”，输出当前全部内容后清空 ring buffer；dmesg -C（大写 C）是“只清不读”，清空后不输出任何东西。两者都只影响内存中的 ring buffer，不影响 /var/log/dmesg 文件。
这两个命令的真实用途不是“清理日志”，而是为后续观察做准备：
- 执行
dmesg -c后再触发某个操作（如modprobe nvme），就能干净地捕获该操作引发的全部内核消息 -
dmesg -C多用于自动化脚本中，先清空缓冲区，再等待特定事件发生 - 注意：普通用户执行会失败，必须有
syslog或cap_syslog权限，通常需sudo
真正容易被忽略的是：ring buffer 大小有限（默认约 16KB），高频日志（如频繁 USB 插拔）会导致旧消息被自动覆盖，所以看到“找不到某条报错”不一定是没发生，很可能是被挤掉了——这时得调大缓冲区：dmesg -s 65536（单位字节）。
