modinfo通过vermagic字段显示模块编译时的内核版本、gcc版本及config_*哈希，若与当前uname -r不匹配（尤其gcc大版本或config差异），加载将失败；depends字段列出依赖模块，其vermagic也须一致；intree为y表示内核源码树自带模块，严格绑定当前内核。
怎么用 modinfo 查驱动支持的内核版本范围
驱动模块本身不直接声明“兼容哪些内核”，但它的编译环境和符号依赖会暴露兼容边界。modinfo 是最直接的切入点，它能读出模块构建时的内核版本和导出符号要求。
执行 modinfo <module_name></module_name>（比如 modinfo ahci 或 modinfo nvme），重点关注以下字段：
-
vermagic：显示该模块编译时的内核版本、GCC 版本、以及 CONFIG_* 编译选项哈希。如果当前内核的uname -r输出与之不匹配（尤其 GCC 大版本或 CONFIG 符号差异），加载会失败并报Invalid module format -
depends：列出依赖的其他模块（如libata），这些模块也必须同时满足vermagic一致 -
intree：值为Y表示它是内核源码树自带模块，通常与当前内核严格绑定；N则多为第三方闭源驱动（如 NVIDIA），需额外验证
为什么 dmesg | grep -i "nvme\|ahci\|sd\|fail" 比看文档更可靠
内核日志是运行时真实兼容性的最终仲裁者。即使驱动声称支持某内核，实际加载或设备探测阶段仍可能因 ABI 变更、DMA 页对齐限制、PCIe ASPM 协商失败等问题触发静默降级或完全拒绝。
典型线索包括：
-
nvme 0000:01:00.0: failed to set queue count: -19→ 内核 NVMe 驱动与设备固件在队列数协商上不兼容 -
ahci 0000:00:1f.2: can't disable ASPM; OS doesn't support it→ 主板 BIOS 和内核 ASPM 支持开关不一致，可能导致休眠唤醒异常 -
sd 0:0:0:0: [sda] Assuming drive cache: write through（后接WARNING）→ 内核无法正确识别磁盘缓存策略，常出现在老旧 SATA 控制器 + 新内核组合中
注意：这类消息不会阻止系统启动，但会影响 IO 行为和稳定性，必须结合 smartctl -a /dev/sda 和 iostat -x 1 观察实际延迟与重试率。
lspci -k 显示的 “Kernel driver in use” 并不等于“完全兼容”
lspci -k 能告诉你哪个驱动被绑定到某个磁盘控制器（如 ahci、nvme、virtio-pci），但它不反映驱动是否启用全部功能或规避已知缺陷。
常见陷阱：
- 虚拟化环境中显示
Kernel driver in use: virtio_scsi，但实际使用的是旧版virtio-scsi协议，不支持WRITE SAME命令 → 导致 LVM thin-provisioning 初始化极慢 - 某些 Intel RST RAID 控制器在 Linux 下被识别为
ahci，但实际固件未关闭 RST 模式 →lsblk看不到物理盘，且mdadm无法管理 -
Kernel driver in use: ata_piix（IDE 模式）在较新内核中已被标记为 deprecated，虽能工作，但不支持 NCQ 和热插拔，hdparm -I /dev/sda中会显示NCQ = not supported
真正关键的兼容性检查点藏在 /boot/config-$(uname -r) 里
驱动能否启用高级特性，取决于内核编译时是否开启对应配置项。例如：
- NVMe over Fabrics 需要
CONFIG_NVME_FC=y或=m，否则即使模块存在也无法加载nvme-fc - TRIM 支持依赖
CONFIG_ATA_TRIM=y（SATA）或CONFIG_NVME_CORE=y（NVMe），缺失则fstrim无效果 - 多队列调度（mq-deadline/io_uring）需要
CONFIG_BLK_MQ=y，否则 SSD 性能受限于单队列瓶颈
查法：grep -E "(NVME|ATA|BLK_MQ|TRIM)" /boot/config-$(uname -r)。若输出含 =n，说明该功能被彻底禁用，换内核或重编译是唯一解。
别只盯着驱动有没有加载——内核配置才是底层能力的闸门。很多“驱动兼容”问题，本质是内核没开对应开关。
