dmesg 默认输出全量日志难以使用，应筛选 err/warn 级别、添加可读时间戳（-t）、避免无效 grep，用 -c 导出并清空日志，而 -c 仅清空不可逆；关键在结合现象判断日志严重性。
dmesg 默认输出全量内核日志，但直接跑 dmesg 基本没法用——错误被淹没在几万行启动杂讯里。真正有用的姿势是加筛选、带时间、实时盯住关键事件。
只看 err/warn 级别，别靠 grep 字符串硬捞
dmesg 的日志有明确级别（err、warn、info、debug），内核自己标记的错误比“timeout”“fail”这类关键词可靠得多：
• 用 dmesg -l err,warn 直接过滤真实错误和警告，90% 的硬件异常、驱动加载失败、IO 超时都落在这两级
• 加 -L 开彩色：dmesg -L -l err,warn，红色高亮一眼定位问题行
• 别写 dmesg | grep -i error——很多“error”只是日志里带这个词，实际是 info 级别，干扰极大
时间戳必须用 -T，别信 [1.234567] 这种开机秒数
默认时间戳是“距系统启动的秒数”，重启或休眠后就失效，根本没法对齐故障时刻：• dmesg -T 输出本地可读时间，比如 [Wed Jun 11 13:22:45 2026]
• 查最近半分钟：dmesg -T | tail -n 30
• 混合使用：dmesg -T -l err,warn，既带时间又只抓关键级别
• 注意：-T 在某些老旧内核（journalctl -k --since "1 minute ago" 替代
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
实时监控硬件事件，-w 是唯一靠谱选项
USB 插拔、NVMe 链路中断、网卡重置这类事件转瞬即逝，翻历史日志基本找不到：• dmesg -w 是内核原生支持的实时流式监听，缓冲区翻转时自动续读，不会丢消息
• dmesg -f 已被官方标记为弃用，某些内核版本下会卡住或中断
• 实战组合：dmesg -w | grep -i "usb\|nvme\|ata"，插设备或复现问题时终端立刻响应
• 如果 dmesg -w 无输出，先检查是否启用了 CONFIG_PRINTK（常见于容器或精简内核），此时改用 journalctl -k -f
清空前务必导出，-c 和 -C 完全不是一回事
内核环形缓冲区大小有限（通常 128KB–256KB），旧消息会被覆盖。排查中途清空，很可能把关键线索刷没了：• 先备份：dmesg > /tmp/dmesg-before.log
• 用 -c（read-and-clear）：dmesg -c 会先输出全部内容再清空，相当于“导出+清空”一步到位
• 绝对别用 -C（clear-only）：dmesg -C 只清不输出，清完就啥都没了，无法回溯
• 如果你刚执行了 dmesg -C，且没其他日志留存（如 journalctl -k 或 /var/log/kern.log），那线索大概率已永久丢失
buffer I/O error 往往意味着磁盘开始掉块；而 ACPI: EC: GPE storm detected 多数只是 BIOS bug，不用干预。这种判断来自反复对照现象和日志，不是堆参数能解决的。
