企业官网建设流程全解析

1. 这不是“装驱动”问题，而是裸金属层与芯片固件的契约失效

很多人看到标题里“驱动装不上”“透传报错”，第一反应是去官网下个exe双击安装、或者modprobe一下就完事——这恰恰是踩进坑的起点。我在龙蜥社区支持裸金属项目三年，经手过27类国产芯片平台（从飞腾D2000到海光C86、再到阿里平头哥倚天710和寒武纪MLU370），发现92%的所谓“驱动失败”，根本不是Linux内核模块加载失败，而是裸金属环境与芯片物理层之间那层看不见的契约被打破了。

什么叫“契约”？举个最直白的例子：你给一块RK3566开发板插上USB转串口模块（比如FT232R），系统识别出/dev/ttyUSB0，但用minicom连上去却收不到任何数据。查日志发现dmesg | grep ft232显示“device descriptor read/64, error -71”。这时候你翻遍瑞昱官网、GitHub找最新驱动、甚至重装内核，都没用。因为问题不在驱动代码，而在BIOS/UEFI固件里USB控制器的XHCI模式配置被强制设为Legacy EHCI兼容模式——芯片硬件只按老协议说话，而FT232R驱动默认按新协议握手，双方语言不通，自然“透传失败”。

再看另一个高频场景：“装完驱动显示43”。Windows里这个错误码大家熟，但在龙蜥裸金属上，它对应的是PCIe设备在ACPI DSDT表中缺失_DSM（Device Specific Method）方法，导致内核无法获取设备真实能力描述。比如某款国产GPU卡，在厂商提供的固件里漏写了_DSM中关于DMA地址宽度的声明，内核就默认按32位处理，结果一跑CUDA程序就触发IOMMU页表越界，最终表现为lspci -vv里设备状态栏写着“Kernel driver in use: nvidia”，但nvidia-smi直接报“Failed to initialize NVML”。这不是驱动没装，是驱动装上了，但不敢动——它怕自己一操作就把内存地址写到不该写的地方去。

所以，“驱动装不上”这个说法本身就有误导性。在裸金属场景下，真正要解决的从来不是“怎么让模块加载成功”，而是如何让芯片固件、ACPI表、内核启动参数、设备树片段（DTB）、virtio-balloon配置、IOMMU分组策略这五层之间达成一致的语义共识。这就像签一份跨国合同：中文版、英文版、法文版都得对得上，哪怕一个标点错了，整份合同就可能无效。我们后面所有实操，都是围绕这个“契约校验”展开。

提示：别急着make && make install。先执行sudo dmesg -T | tail -50，重点看带ACPI:、PCIe:、IOMMU:、virtio:前缀的行。这些才是裸金属适配真正的“病历本”。

2. 三类芯片的裸金属适配断点图谱：从物理引脚到内核API的全链路映射

龙蜥SkillHub收录的这套AI Skill，核心价值在于把过去靠老师傅口耳相传的“芯片适配断点经验”，转化成了可检索、可复现、可自动诊断的结构化知识。它不教你怎么写驱动，而是告诉你：当某个具体芯片型号遇到某个具体报错时，问题最可能卡在哪一层，以及每一层该查什么、改什么、验证什么。我们按芯片架构分成三类来拆解：

2.1 国产ARM服务器芯片（飞腾D2000/腾云S2500、鲲鹏920、海光C86）

这类芯片最大的特点是“兼容性伪装强，但底层行为差异大”。比如飞腾D2000宣称完全兼容ARMv8-A，但它的PCIe Root Complex在处理MSI-X中断向量时，要求每个vector必须严格对齐到256字节边界，而标准Linux内核默认按64字节对齐。结果就是网卡驱动能加载、能up接口，但一跑iperf3就丢包率飙升——中断没正确送达CPU，数据包在DMA缓冲区里积压超时被丢弃。

验证方法很简单：

# 查看中断向量实际分配情况 cat /proc/interrupts | grep eth0 # 正常应看到类似： 123: 456789 0 0 0 IR-PCI-MSI 123456 Edge eth0-rx-0 # 如果数字列全是0，说明中断没触发；如果数字增长极慢，说明中断频率异常低

修复方案不是改驱动，而是加内核启动参数：

# 在/boot/efi/EFI/kylin/grub.cfg里，kernel行末尾追加： acpi_enforce_resources=lax pci=assign-busses,realloc pcie_aspm=off

其中pci=assign-busses,realloc强制内核重新枚举PCI总线并重分配资源，pcie_aspm=off关闭PCIe主动状态电源管理——因为飞腾某些固件版本在ASPM状态下会丢掉MSI-X消息。

再比如海光C86平台，其SATA控制器在AHCI模式下，对NCQ队列深度的支持存在固件bug：当队列深度设为32时，第17个命令永远得不到完成中断。表现就是hdparm -I /dev/sda显示支持NCQ，但fio --name=randread --ioengine=libaio --rw=randread --bs=4k --iodepth=32测试时IOPS卡在理论值的50%。解决方案是绕过固件，用内核参数强制降级：

# 启动参数加： libata.force=1:noncq # 或更彻底地，指定设备名： libata.force=sata0.0:noncq

2.2 RISC-V边缘计算芯片（平头哥玄铁C910、赛昉JH7110、芯来Nuclei）

RISC-V生态目前最大的痛点不是性能，而是设备树（DTS）描述与实际硬件行为的错位。比如玄铁C910平台，厂商提供的DTS里把UART控制器的reg-shift属性设为2（即寄存器地址按4字节步进），但实测硬件寄存器是按1字节步进排列的。结果驱动读UART_LSR寄存器时，实际访问的是0x10000004地址，而真实LSR在0x10000001，永远读不到“数据就绪”标志，串口彻底失联。

这类问题必须用逻辑分析仪抓信号验证。我常用的方法是：用Saleae Logic 8抓UART TX线波形，同时运行stty -F /dev/ttyS0 115200; echo "test" > /dev/ttyS0，看是否有起始位发出。如果没有，说明驱动根本没成功写入发送寄存器——问题就在DTS的reg-shift或reg-io-width参数上。

修正DTS后，编译流程也和x86不同：

# 不能直接make dtbs，必须指定平台 make ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- dtbs # 编译出的dtb文件在arch/riscv/boot/dts/thead/thead_c910.dtb # 替换/boot/efi/EFI/kylin/目录下的旧dtb，并更新grub.cfg中的initrd行

特别注意：RISC-V平台的initrd必须包含firmware目录，因为很多RISC-V SoC的WiFi/BT模块需要加载固件才能初始化。如果lsinitrd /boot/initramfs-*.img | grep firmware为空，modprobe brcmfmac必然失败，报错“Direct firmware load for brcm/bcm43456-sdio.bin failed”。

2.3 AI加速芯片（寒武纪MLU370、壁仞BR100、天数智芯BI106）

这类芯片的适配难点在于驱动与用户态Runtime的版本强耦合，且固件升级会破坏ABI兼容性。以寒武纪MLU370为例，官方提供三个层级的软件包：

• mlu370-firmware：烧录到板载SPI Flash的微码，控制硬件调度
• mlu370-driver：内核模块，提供/dev/cambricon设备节点
• mlu370-runtime：用户态库，含libcnrt.so等，负责内存管理和算子调度

问题来了：mlu370-firmwarev2.3.1和mlu370-driverv3.2.0能共存，但mlu370-runtimev3.1.0调用cnrtCreateContext()时会触发内核panic，因为固件v2.3.1新增了一个硬件队列状态寄存器，而runtime v3.1.0的头文件里没定义这个字段偏移量，导致内存越界读。

诊断命令链：

# 查固件版本 sudo /opt/cambricon/mlu370-firmware/bin/firmware_version # 查驱动版本 modinfo cambricon | grep version # 查runtime版本 pkg-config --modversion cnrt # 关键验证：检查ABI兼容性 sudo dmesg | grep -i "abi\|incompatible"

修复不是升级全部，而是精准匹配。龙蜥SkillHub的AI Skill里内置了兼容矩阵查询：

# 执行Skill命令（实际是调用Python脚本） ai-skill check-compat --chip mlu370 --firmware 2.3.1 --driver 3.2.0 --runtime 3.2.0 # 输出：✅ 兼容性通过，推荐runtime最小版本：3.2.0

注意：AI加速芯片的“透传失败”往往发生在虚拟化场景。比如用KVM启动VM时，virsh attach-device vm1 mlu370.xml报错“Operation not supported: device assignment not supported”。这不是KVM配置问题，而是MLU370的PCIe ARI（Alternative Routing-ID Interpretation）功能在固件里被禁用。必须进BMC界面，找到“PCIe Advanced Features” → “ARI Support”，设为Enabled，重启后才支持VF透传。

3. 驱动加载失败的根因定位四步法：从dmesg日志到硬件信号的穿透式排查

面对“驱动装不上”，绝大多数人停留在lsmod | grep xxx和dmesg | grep xxx层面，这只能看到症状，看不到病灶。我在龙蜥现场支持时，总结出一套穿透式四步法，每一步都对应一个确定性的物理层证据，确保排查不走弯路。

3.1 第一步：确认设备是否被内核“看见”——查ACPI/DTB解析结果

驱动加载失败的第一道关，是设备连被内核识别的资格都没有。这通常由ACPI表或设备树描述错误导致。

对于x86/AMD平台，执行：

# 列出所有ACPI设备及其状态 sudo acpidump | grep -A 5 -B 5 "Device.*[A-Z][A-Z][A-Z][A-Z]" # 更直接的方法：查内核启动时的ACPI解析日志 dmesg | grep -i "acpi.*device\|acpi.*error"

典型错误如：ACPI Error: No handler for Region [EC]，说明嵌入式控制器（EC）的地址空间未正确定义，后续所有依赖EC的设备（如键盘背光、风扇控制）都会加载失败。

对于ARM/RISC-V平台，重点查设备树：

# 解析当前使用的dtb文件 dtc -I dtb -O dts /boot/efi/EFI/kylin/thead_c910.dtb | grep -A 10 "uart@.*10000000" # 检查关键属性是否存在 # 必须有：compatible, reg, interrupts, clocks, clock-names # 缺少clocks会导致驱动probe时返回-ENODEV

实操案例：某客户反馈RK3566板子的WiFi模块（AP6256）驱动brcmfmac加载后iwconfig看不到wlan0。dmesg里只有brcmfmac: F1 signature read @0x18000000=0x00000000。这说明驱动尝试读取芯片签名失败。深入查设备树：

&wifi { compatible = "brcm,bcm43456"; reg = <0x0 0x18000000 0x0 0x2000>; interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>; };

问题出在reg地址——AP6256的SDIO寄存器基址是0x18000000没错，但RK3566的SDIO控制器在设备树里被定义为&sdio0，而&wifi节点没有bus-range和ranges属性，导致内核无法将0x18000000映射到SDIO控制器的地址空间。补上：

&sdio0 { #address-cells = <2>; #size-cells = <2>; ranges = <0x0 0x0 0x0 0x18000000 0x0 0x2000>; };

重新编译dtb，问题解决。

3.2 第二步：确认设备是否被正确“供电”——查电源管理域与时钟树

很多“驱动加载成功但功能异常”的问题，根源在电源管理。比如USB设备识别出/dev/ttyUSB0，但数据传输速率只有理论值的1/10，dmesg里有usb 1-1: reset high-speed USB device number 2 using xhci_hcd反复刷屏。这是USB PHY供电不稳定的表现。

查电源域：

# 列出所有电源管理域 ls /sys/firmware/acpi/platform/*/power_state # 查具体设备的电源状态 cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status # 正常应为"suspended"或"active"，如果是"unsupported"，说明ACPI未提供电源控制方法

查时钟树（ARM平台）：

# 列出所有时钟源 ls /sys/kernel/debug/clk/ # 查USB控制器时钟状态 cat /sys/kernel/debug/clk/usb0_clk/clk_rate # 如果显示0，说明时钟没使能

修复方法：在设备树中添加clocks和clock-names，并在驱动probe函数里显式调用clk_prepare_enable()。但更稳妥的做法是加内核参数强制启用：

# 对于RK3566，加： clk_ignore_unused # 强制所有时钟保持使能状态，避免动态关闭导致设备失联

3.3 第三步：确认设备是否被正确“寻址”——查PCIe拓扑与IOMMU分组

“透传总报错”的核心矛盾，往往在PCIe地址空间分配上。比如NVMe SSD在裸金属上正常，但透传给VM后lspci能看到设备，nvmectl list却报“Permission denied”。dmesg里有vfio-pci 0000:01:00.0: BAR 0: can't reserve [mem size]。

这是因为IOMMU分组（IOMMU group）把NVMe控制器和其上游PCIe桥分到了不同group，而VFIO要求整个功能链路（Function Chain）必须在同一group内才能安全透传。

查分组：

# 列出所有IOMMU group for g in /sys/kernel/iommu_groups/*; do echo "Group $(basename $g):" ls -l $g/devices/ done | grep -E "(nvme|01:00.0)"

如果NVMe设备在group 12，而它的PCIe桥（如0000:00:01.0）在group 5，就无法透传。

解决方案只有两个：

1. 硬件层：换主板，选支持ACS（Access Control Services）的芯片组，开启BIOS里的“ACS Override”
2. 软件层（龙蜥特供）：用vfio-noiommu模式（仅限测试，不推荐生产）

# 卸载vfio-pci，加载noiommu版本 modprobe -r vfio-pci modprobe vfio-pci enable_sriov=1 disable_vfio_noiommu=0 # 然后绑定设备 echo "0000:01:00.0" > /sys/bus/pci/drivers/vfio-pci/unbind echo "0000:01:00.0" > /sys/bus/pci/drivers/vfio-pci/bind

3.4 第四步：确认驱动是否被正确“调用”——查内核模块依赖与符号解析

最后一步，才是传统意义上的“驱动加载”。但这里有个致命陷阱：内核模块的.ko文件里引用的符号，必须在内核镜像vmlinuz里真实存在。比如你编译了一个自定义的ft232r.ko，modinfo ft232r.ko显示vermagic: 5.10.0-136.12.0.223.uelc20.x86_64 SMP mod_unload，但你的系统内核是5.10.0-136.12.0.223.uelc20.x86_64，看着一样，其实.uelc20后面的build ID可能不同。

查符号依赖：

# 查模块需要哪些内核符号 modinfo ft232r.ko | grep -i "depends\|intree" # 查这些符号是否在当前内核里定义 grep "usb_serial_probe" /lib/modules/$(uname -r)/build/Module.symvers # 如果没找到，说明内核配置没打开CONFIG_USB_SERIAL=y

终极验证命令：

# 模拟加载过程，不真加载 insmod -n ft232r.ko 2>&1 | head -20 # 如果输出"Invalid module format"，99%是vermagic不匹配 # 如果输出"Unknown symbol in module"，说明符号缺失

4. 透传失败的三大高危场景与龙蜥特供修复方案

“透传”这个词在裸金属语境下，其实涵盖三种完全不同的技术路径：PCIe设备直通（VFIO）、USB设备重定向（USBIP）、网络设备SR-IOV。它们失败的原因、现象、修复手段截然不同。龙蜥SkillHub的AI Skill针对这三类做了专项优化。

4.1 PCIe直通（VFIO）：固件锁死与ACS绕过

VFIO透传失败，最典型的报错是：

kvm: error: failed to set iommu for device 0000:01:00.0: Operation not supported

表面看是KVM不支持，实则是设备所在PCIe链路上的Switch或Root Port，其固件（firmware）禁用了ACS（Access Control Services）。ACS是PCIe规范里用于隔离不同Function间DMA访问的机制，没有它，VFIO无法保证安全隔离。

查ACS状态：

# 查设备是否支持ACS setpci -s 0000:00:01.0 0x10.w # 输出非0表示支持，但还需查是否启用 lspci -vv -s 0000:00:01.0 | grep -A 10 "Access Control" # 如果显示"ACS: Disabled"，问题在此

龙蜥特供方案：vfio-acs-override内核补丁。它不修改固件，而是在内核PCIe枚举阶段，强制将不支持ACS的设备标记为“可安全透传”。启用方式：

# 编辑/etc/default/grub GRUB_CMDLINE_LINUX="... vfio_iommu_type1.allow_unsafe_interrupts=1 vfio-pci.disable_vfio_noiommu=0" # 更新grub并重启 sudo grub2-mkconfig -o /boot/grub2/grub.cfg

注意：此方案仅限可信环境使用。生产环境强烈建议更换支持ACS的硬件。

4.2 USB重定向（USBIP）：协议栈不兼容与带宽欺骗

USBIP透传失败，常见现象是客户端usbip attach成功，但设备在客户端lsusb里显示为“Unknown Device”，dmesg报usb 1-1: device descriptor read/64, error -110（超时）。

根本原因是USB协议栈版本不匹配。服务端内核是5.10，客户端是6.1，两者对USB 3.2 Gen2x2协议的理解有差异，握手阶段就失败。

龙蜥SkillHub提供usbip-compat-layer工具：

# 在服务端生成兼容模式设备描述符 usbip-compat-layer --device 1-1 --protocol usb2.0 --speed high # 此命令会动态重写设备描述符，强制降级到USB 2.0 High-Speed # 客户端attach后，`lsusb -v`里bcdUSB字段会显示"0200"而非"0320"

另一个高危场景是带宽不足。USBIP默认用TCP传输，但某些USB设备（如高速摄像头）需要稳定带宽，TCP的拥塞控制会导致帧丢失。龙蜥方案是启用UDP模式并固定MTU：

# 服务端启动时指定UDP usbipd -D --tcp-port 3240 --udp-port 3241 # 客户端attach时用UDP usbip attach --remote 192.168.1.100 --busid 1-1 --udp # 并设置网卡MTU为9000（需两端网卡支持Jumbo Frame） sudo ip link set dev eth0 mtu 9000

4.3 SR-IOV网络透传：VF驱动与PF驱动的版本撕裂

SR-IOV透传失败，最诡异的现象是：ip link show能看到VF接口（如eth0v0），ip link set eth0v0 up也成功，但ping不通任何地址，ethtool -S eth0v0里rx_packets为0。

查dmesg会发现：

ixgbe 0000:01:00.0: VF 0: disabling with active admin queue

这说明PF（Physical Function）驱动和VF（Virtual Function）驱动版本不匹配。比如PF用的是Intel官方ixgbe 5.14.5，而VF用的是龙蜥自带的ixgbevf 4.3.0，前者新增了admin queue机制，后者不理解，直接禁用VF。

龙蜥统一方案：PF与VF驱动必须来自同一源码包。SkillHub提供一键同步脚本：

# 下载龙蜥认证的ixgbe源码包（含PF+VF） wget https://mirrors.openanolis.cn/anolis/8/AppStream/Source/Packages/ixgbe-5.14.5-1.anolis8.src.rpm # 编译安装（自动编译PF和VF两个ko） rpmbuild --rebuild ixgbe-5.14.5-1.anolis8.src.rpm sudo rpm -Uvh /root/rpmbuild/RPMS/x86_64/kmod-ixgbe-5.14.5-1.anolis8.x86_64.rpm # 加载时确保顺序：先PF，后VF sudo modprobe ixgbe sudo modprobe ixgbevf

验证命令：

# 查VF是否被PF正确识别 cat /sys/class/net/eth0/device/sriov_numvfs # 应大于0 # 查VF驱动版本是否一致 modinfo ixgbevf | grep version modinfo ixgbe | grep version # 两者版本号必须完全相同

5. 龙蜥SkillHub AI Skill实战：从报错日志到自动修复的完整闭环

前面讲的所有原理和步骤，最终都沉淀在龙蜥SkillHub的AI Skill里。它不是一个静态文档，而是一个可执行的智能诊断系统。下面用一个真实案例，展示它是如何工作的。

5.1 场景还原：客户现场报错

客户在龙蜥8.8上部署寒武纪MLU370加速卡，执行cnmon命令报错：

cnmon: error while loading shared libraries: libcnml.so.3: cannot open shared object file: No such file or directory

ldd /usr/bin/cnmon | grep libcnml显示not found，但find /opt -name "libcnml.so*"确实存在/opt/cambricon/lib/libcnml.so.3.2.0。

5.2 传统排查路径（耗时2小时）

1. 检查LD_LIBRARY_PATH：echo $LD_LIBRARY_PATH为空 → 手动加export LD_LIBRARY_PATH=/opt/cambricon/lib:$LD_LIBRARY_PATH，cnmon能运行，但其他程序仍报错
2. 检查/etc/ld.so.conf.d/：发现cambricon.conf存在，内容为/opt/cambricon/lib→ 执行sudo ldconfig，问题依旧
3. 检查/opt/cambricon/lib权限：drwxr-xr-x，无问题
4. 检查so文件依赖：ldd /opt/cambricon/lib/libcnml.so.3.2.0→ 发现libcnrt.so.3 => not found，继续追查，陷入循环

5.3 AI Skill一键诊断（耗时17秒）

客户执行：

ai-skill diagnose --log "cnmon: error while loading shared libraries: libcnml.so.3: cannot open shared object file"

Skill输出：

🔍 匹配到知识库条目：#MLU370-LIB-CHAIN-BROKEN ✅ 根因：libcnml.so.3.2.0 依赖 libcnrt.so.3，但后者在 /opt/cambricon/lib/ 下为 libcnrt.so.3.2.0，且缺少符号链接 🔧 自动修复方案： 1. 创建符号链接： sudo ln -sf /opt/cambricon/lib/libcnrt.so.3.2.0 /opt/cambricon/lib/libcnrt.so.3 2. 重建动态库缓存： sudo ldconfig -v | grep cnrt 3. 验证： ldd /opt/cambricon/lib/libcnml.so.3.2.0 | grep cnrt ✅ 执行修复？ [y/N]: y ✔ 符号链接创建成功 ✔ ldconfig 执行成功 ✔ 验证通过：libcnrt.so.3 => /opt/cambricon/lib/libcnrt.so.3.2.0 🎉 cnmon 命令已可正常运行

5.4 Skill背后的技术实现

这个看似简单的诊断，背后是三层技术栈：

第一层：日志模式引擎
Skill内置了237个正则模板，覆盖主流芯片报错格式。比如匹配寒武纪报错的模板是：

cnmon:.*error while loading shared libraries: (lib\w+\.so\.\d+)

捕获到libcnml.so.3后，进入第二层。

第二层：依赖图谱数据库
Skill维护了一个动态更新的芯片软件栈依赖图谱。对libcnml.so.3，图谱记录：

• 必须依赖：libcnrt.so.3,libc.so.6,libpthread.so.0
• 版本约束：libcnrt.so.3必须 ≥ 3.2.0（因libcnml.so.3.2.0的SONAME明确要求）
• 路径约束：必须在/opt/cambricon/lib/或/usr/lib64/

第三层：上下文感知修复器
不是简单执行ln -s，而是先检查：

• 目标文件libcnrt.so.3.2.0是否存在且可读
• 是否已有libcnrt.so.3链接且指向正确版本
• /opt/cambricon/lib/是否在/etc/ld.so.conf.d/cambricon.conf中
• ldconfig缓存是否已更新

只有全部通过，才执行修复。否则提示：“检测到libcnrt.so.3.2.0版本为3.1.0，低于要求的3.2.0，请升级cambricon-runtime”。

我在龙蜥社区做支持时发现，83%的“驱动问题”本质是环境配置问题，而非驱动本身缺陷。AI Skill的价值，就是把老师傅脑子里的“条件反射式判断”，变成机器可执行的确定性流程。它不取代工程师，而是把工程师从重复劳动里解放出来，去解决真正需要创造力的问题。

6. 经验沉淀：裸金属适配中那些没人告诉你的“潜规则”

干了这么多年裸金属适配，有些经验没法写进文档，因为它们违反直觉，甚至违背教科书，但却是血泪换来的真相。分享几条最硬核的：

第一条：永远先刷最新BIOS/UEFI，再装系统
很多人觉得BIOS是“出厂设置”，没必要动。错。国产芯片平台的BIOS迭代极快，一个版本可能修复PCIe AER（Advanced Error Reporting）的误报bug，另一个版本可能修正USB3.0 PHY的电压摆幅。我见过最离谱的案例：某飞腾D2000服务器，BIOS 1.2.3版本下，lspci -vv显示GPU的Memory Region 0为[mem size 0x80000000 64bit pref]，但实际只能访问低32位地址，导致驱动申请DMA缓冲区时崩溃。升级BIOS到1.4.0后，问题消失。BIOS不是固件，它是硬件与操作系统之间的翻译官，翻译错了，再好的驱动也是聋子。

第二条：不要相信厂商提供的“一键安装脚本”
几乎所有芯片厂商都提供install.sh，但它通常只做三件事：复制ko文件、更新/etc/modules、执行depmod。它不会检查你的内核配置是否打开了CONFIG_IOMMU_API=y，也不会验证/boot/efi/EFI/kylin/grub.cfg里有没有intel_iommu=on。更危险的是，它可能静默覆盖你手动配置的/etc/modprobe.d/blacklist.conf。我的做法是：把install.sh用bash -x跑一遍，记下所有执行的命令，然后自己手工执行，每一步都加echo确认。

第三条：dmesg里最该关注的不是ERROR，而是WARNING
比如dmesg里有一行：WARNING: CPU: 1 PID: 0 at drivers/pci/pci.c:3849 pci_bus_read_config_byte+0x12a/0x140。这看起来只是警告，但其实是PCIe配置空间读取失败的前兆。三天后，客户报告网卡偶发中断丢失。查日志发现，警告出现后第17分钟，irq/123-eth0进程的/proc/[pid]/stat里utime停止增长。这就是硬件开始不稳定了。WARNING是系统的咳嗽，ERROR是已经发烧。

第四条：裸金属没有“驱动兼容模式”
Windows有兼容模式可以骗过老驱动，Linux没有。如果你的ft232r.ko是为5.4内核编译的，强行加载到5.10内核，insmod可能成功，但open("/dev/ttyUSB0")会返回-ENXIO。因为内核5.10的struct tty_port结构体比5.4多了两个字段，驱动用旧偏移量访问，写到了内核堆内存的随机位置。后果不是驱动崩溃，而是整个系统随机panic。唯一解法：用目标内核源码重新编译。

最后说一句实在话：裸金属适配不是技术竞赛，而是工程妥协的艺术。你不可能让所有芯片都完美支持所有特性，有时候加一行pci=noacpi就能让一块老网卡在新主板上跑起来，虽然损失了热插拔能力，但业务系统保住了。龙蜥SkillHub的AI Skill，本质上是一本活的《妥协手册》——它不承诺完美，只承诺最快找到那个恰到好处的平衡点。