dmesg是诊断内核模块加载失败的根本工具，能精准揭示“为什么失败”：如Unknown symbol、version magic不匹配、module verification failed等直接证据；配合modinfo查vermagic与depends、lspci/lsusb验证绑定状态、检查固件和内核配置，实现四维交叉验证。
用 dmesg 抓第一手加载日志，不是“有没有”，而是“为什么失败”
驱动兼容性问题往往在模块加载瞬间就埋下伏笔，dmesg 是唯一能还原现场的工具。它不告诉你“是否兼容”，但会明确打印出不兼容的证据：Unknown symbol、version magic 不匹配、module verification failed 或直接 disagrees about version of symbol。
实操建议：
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 加载前清空日志：
dmesg -c，避免干扰 - 加载模块后立刻执行：
dmesg | tail -20，重点关注最后几行 - 若已知驱动名（如
igb），直接过滤：dmesg | grep -i "igb\|error\|fail" - 遇到
version magic报错，说明模块编译内核版本（如6.6.15-1）与当前运行内核（uname -r输出）不一致，必须重编或换包
modinfo 看模块元数据，重点盯 vermagic 和 depends
modinfo 不显示“兼容性结论”，但它暴露了所有兼容性前提条件。尤其注意两个字段：
vermagic：包含编译时内核版本 + SMP/DEBUG/CONFIG_* 等标记。若当前内核启用了 CONFIG_MODULE_SIG 但模块没签名，就会被拒载；若标记含 mod_unload 而当前内核禁用了该配置，同样失败。
depends：列出依赖的其他模块（如 usbcore、libphy）。如果依赖项未加载或版本不匹配，本模块根本不会启动——这不是本模块的问题，而是依赖链断裂。
实操建议：
- 查模块路径再
modinfo：modinfo $(modprobe -n -v your_driver | awk '{print $NF}')，避免查错文件 - 比对
vermagic中的内核版本和uname -r，字符级一致才安全 - 检查
depends列出的每个模块是否已加载：lsmod | awk '{print $1}' | grep -E '^(usbcore|libphy|...)$'
lspci -k 或 lsusb -v 确认设备绑定关系，而非只看“有没有驱动”
很多用户误以为 lspci -v 显示了 Kernel driver in use: r8169 就代表兼容。错。它只说明“当前绑定了这个驱动”，不保证功能正常。真正要看的是：设备是否被正确识别 + 驱动是否成功 probe。
实操建议：
- 用
lspci -k -s 00:1f.6（替换为你的bus:slot.func）查看具体设备的驱动绑定和模块名 - 配合
dmesg | grep -A5 -B5 "00:1f.6"，确认 probe 阶段有无probed、initialized等成功字样 - 对 USB 设备，
lsusb -v -d vid:pid可看到 bInterfaceClass 和 driver claimed 的接口号，若某接口显示Driver=none，说明驱动未覆盖全部功能面 - Realtek RTL8111 常见陷阱：
lspci显示r8169，但dmesg里反复出现link down或rx_missed_errors暴涨 → 实际是驱动不兼容，需换r8168
查 /lib/firmware 和内核配置，固件缺失和 CONFIG 关闭才是静默杀手
很多“驱动加载成功但硬件不工作”的问题，根源不在驱动本身，而在固件或内核配置。比如 AMD RDNA3 显卡，amdgpu 模块能加载，但若 /lib/firmware/amdgpu/navi31_mes.bin 缺失，dmesg 会报 failed to load firmware 并静默退出 probe；又如 Intel Arc，若内核未启用 CONFIG_DRM_XE，xe 模块根本不会编译进系统，modprobe xe 直接报 Module not found。
实操建议：
- 查固件是否存在：
find /lib/firmware -name "*navi31*" -o -name "*mtl_dmc*"（按实际芯片型号调整） - 查内核是否支持该功能：
zcat /proc/config.gz | grep -i "drm_xe\|amdgpu\|i40e"（若无/proc/config.gz，用grep CONFIG_DRM_XE /boot/config-$(uname -r)） - 确认固件权限：
ls -l /lib/firmware/amdgpu/，确保文件非空且可读（-rw-r--r--） - 某些驱动（如
i40e）要求CONFIG_NET_CLS_U32，缺了会导致 QoS 功能失效，但模块仍能加载——这种属于“部分兼容”，需结合业务场景判断
驱动兼容性没有“一键报告”，因为内核不生成汇总诊断。真正有效的检查，是把 dmesg 的错误、modinfo 的约束、lspci -k 的绑定状态、固件和内核配置四者交叉验证。最容易被忽略的，是固件缺失和 CONFIG 关闭——它们不会导致模块加载失败，却让硬件处于“假在线真瘫痪”状态。
