新手看内核启动日志应先抓时间戳、子系统标识和日志级别：时间戳为开机后秒数，用于串联事件链；子系统标识（如ata1.00:、usb1-1:）比“error”等词更早暴露根源；必须用dmesg -l err,warn过滤，而非grep "error"；遇oops/bug时优先分析call trace调用栈，并联动lspci、modinfo、journalctl -k交叉验证。
新手看内核启动日志，别从头逐行读，先抓三样东西：时间戳、子系统标识、日志级别。硬件冲突和潜在风险往往藏在这些细节里，而不是“conflict”“error”这类词本身。
盯住时间戳和设备标识，比搜关键词更靠谱
内核日志的时间戳是开机后秒数，比如[ 2.345678]代表启动后2.35秒。同一类问题（如硬盘识别→驱动加载→IO失败）会跨多个时间点，靠这个标尺才能串起事件链。
真正暴露问题的，常是冒号前那一段，比如：
- ata1.00: 后面跟 exception Emask 0x0 frozen → 主控卡死，不是硬盘坏了
- usb1-1: 后面跟 device descriptor read/64, error -110 → USB供电不足或线材问题
- iwlwifi 0000:02:00.0: 后面跟 Failed to load firmware → 缺少固件，不是驱动没装
这些标识比“failed”“error”更早指向根源，优先看它们。
只信 dmesg -l err,warn，别用 grep “error”
很多关键问题根本不带“error”字眼，比如：
- dma timeout、overrun、stuck —— 常见于网卡或声卡异常
- irq X: nobody cared —— 中断没人处理，大概率驱动bug或硬件冲突
- ACPI: \_OSC: OS supports all requested features 后紧跟 ACPI Error —— BIOS与内核电源管理不兼容
正确做法是：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- dmesg -l err,warn —— 只留真正要人工干预的日志
- dmesg -T | grep -E "(ata|nvme|usb|pci)" | grep -E "(err|warn|fail|timeout)" —— 加人类时间+按设备类型聚焦
- 避免
dmesg | grep -i error—— 容易漏掉重点，还被固件自检等无害信息干扰
看到 Oops 或 BUG，先看调用栈，别急着查地址
遇到类似下面这种输出：
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
Call Trace:
ext4_writepages+0x123
do_writepages+0x45
__writeback_single_inode+0x67
关键在 Call Trace 最上面那行：ext4_writepages —— 说明是 ext4 文件系统写回路径出的问题，不是通用内存或调度子系统故障。
如果调用栈里出现 workqueue、timer、softirq，基本可判定是异步上下文里的竞态，常见于驱动在中断上下文中执行了不该睡眠的操作。
联动几个命令，交叉验证才稳
单看 dmesg 很容易误判。发现可疑线索后，立刻补这几条命令：
- sudo lspci -vv -s 0000:02:00.0 —— 查具体PCI设备的详细配置和中断分配
- lsmod | grep iwlwifi 和 modinfo iwlwifi —— 确认驱动是否加载、参数是否合理
- journalctl -k -S "2 minutes ago" —— 查最近两分钟内核日志，看是否持续刷屏同类报错
- cat /proc/interrupts | grep " 0000:02:" —— 检查该设备中断是否长期为0或突增，判断是否失联或风暴
比如看到 irq 45: nobody cared，马上用 lspci -vv -s 定位到对应设备，再用 modinfo 看驱动是否支持该硬件ID —— 这才是闭环排查。
