简介：本资源是专为银河麒麟V10操作系统适配优化的e1000e与RTL8125网卡驱动源码包，面向国产化信创环境下的Linux内核开发者、系统集成工程师及政企IT运维人员，解决在麒麟V10上因内核版本差异导致的Intel千兆网卡（如82574L）和Realtek RTL8125B/C控制器无法编译加载的核心兼容性问题。压缩包共56个文件，含19个C源文件（实现核心网络协议栈交互）、21个头文件（定义硬件寄存器、数据结构与函数接口）、3个Makefile（支持多内核版本构建）、2个README（含编译说明与适配要点），以及补丁脚本、校验文件与许可证文本，总大小483KB，结构完整、即取即用。已有2745人学习下载，用户可直接获取已验证的可编译源码树、关键修改痕迹（如重复定义清理、函数参数适配）、配套自动安装脚本（autorun.sh）及详细日志与支持列表，大幅降低国产平台网卡驱动移植门槛。

1. 银河麒麟V10上编译e1000e与rtl8125驱动：不是“装不上”，而是“版本锁死了”

某高校实验室部署一批国产化服务器，统一要求银河麒麟V10 SP1（内核 4.19.90-24.4.ky10.aarch64）环境。运维同事按常规流程下载 Intel 官方 e1000e-3.8.7 和 Realtek 官方 r8125-9.008.01 源码，make && make install一路回车——结果网卡根本识别不到，lspci -k显示设备存在但Kernel driver in use: none，dmesg | grep e1000e报Unknown symbol in module。这不是编译失败，而是典型的「内核符号不匹配」：麒麟V10的内核启用了模块签名强制验证（CONFIG_MODULE_SIG_FORCE=y），且对导出符号表做了裁剪和重排，官方驱动源码里调用的__const_udelay、netif_napi_add_weight等函数在麒麟内核中要么被重命名，要么压根没导出。更玄学的是，同一份 rtl8125-9.008.01，在 Ubuntu 20.04（内核5.4）上秒编译成功，到麒麟V10上却卡在#include <linux/pci.h>报错——因为麒麟把pci_dma_mapping_error的宏定义从linux/pci.h移到了asm-generic/dma-mapping.h。这不是驱动写得烂，是国产化内核定制带来的真实水土不服。本文整理的是一套经实测在银河麒麟V10 SP1/SP2（x86_64 & aarch64）、内核 4.19.90–4.19.90-52.5.ky10 可稳定编译、加载、收发包的驱动源码+补丁+配置方案，覆盖 e1000e（千兆）与 rtl8125（2.5G）两类高频网卡，专治“麒麟V10驱动编译玄学”。

2. 环境准备与源码选择：为什么必须放弃官网最新版？

2.1 银河麒麟V10内核特性清单（关键约束项）

银河麒麟V10并非简单复刻 CentOS 或 Ubuntu 内核，其内核构建时启用了多项加固策略，直接影响驱动兼容性：

提示：这些配置无法通过make menuconfig在运行时修改，必须匹配源码级适配。强行关闭MODULE_SIG_FORCE需重新编译整个内核，成本远高于适配驱动。

2.2 驱动版本选型逻辑（非越新越好）

• e1000e 驱动：Intel 官方最新版 e1000e-3.8.7（2022年发布）已移除对 4.19 内核的兼容代码，其e1000e_main.c中大量使用struct napi_struct的napi.poll_list字段（4.20+ 引入），在麒麟V10内核中该字段不存在。实测e1000e-3.6.3是最后一个完整支持 4.19.x 的稳定版，且其 Makefile 未启用-Werror，避免因麒麟内核头文件警告升级为错误。

• rtl8125 驱动：Realtek 官网 r8125-9.008.01（2023年）依赖devm_platform_ioremap_resource()（5.0+ 引入），在 4.19 中需回退至r8125-9.005.01。该版本仍使用传统platform_get_resource()+ioremap()流程，与麒麟V10的arch/arm64/kernel/bios32.c兼容性最佳。

• 关键补丁来源：所有适配补丁均来自银河麒麟官方内核源码树（kernel-4.19.90-*.src.rpm中的patches/目录），非社区零散patch。例如e1000e-kernel-4.19-compat.patch修复了netif_napi_add_weight符号缺失问题；r8125-dma-coherent-fix.patch重写了rtl8125_pci_probe()中的DMA映射逻辑，绕过麒麟内核对dma_set_coherent_mask()的强校验。

2.3 系统环境确认（三步必查）

在开始编译前，请严格验证以下三项，任一不满足将导致后续全部失败：

# 1. 确认内核版本与架构（x86_64 或 aarch64） $ uname -r 4.19.90-24.4.ky10.x86_64 $ uname -m x86_64 # 2. 确认内核头文件与开发包已安装（麒麟V10 SP1起，头文件包名含"-devel"） $ rpm -qa | grep "kernel.*devel" kernel-devel-4.19.90-24.4.ky10.x86_64 # 若未安装，执行： # sudo yum install kernel-devel-$(uname -r) -y # 3. 确认模块签名工具链可用（麒麟V10自带，无需额外安装） $ which sign-file /usr/src/kernels/$(uname -r)/scripts/sign-file $ ls /usr/src/kernels/$(uname -r)/certs/ signing_key.pem x509.genkey # 必须存在，否则无法签名

注意：sign-file工具依赖/usr/src/kernels/$(uname -r)/certs/signing_key.pem。若该文件不存在（常见于最小化安装），需手动从麒麟ISO镜像中提取kernel-headers-*.rpm并安装，或运行sudo /usr/lib/rpm/kernel-install.sh重建证书。

3. e1000e 驱动编译与签名：从源码到可加载模块

3.1 下载与解压（使用经麒麟适配的源码包）

不要直接下载 Intel 官网源码。本文使用的e1000e-3.6.3-ky10-patched.tar.gz包含：

• 原始 e1000e-3.6.3 源码
• 0001-e1000e-kernel-4.19-compat.patch（修复 NAPI weight、symbol export）
• 0002-e1000e-disable-module-sign-warning.patch（关闭MODULE_SIG编译警告）
• Makefile.ky10（覆盖原Makefile，预设麒麟专用编译参数）

# 创建工作目录 $ mkdir -p ~/driver-build/e1000e && cd ~/driver-build/e1000e # 下载适配版源码（假设已获取，若需原始包可联系提供SHA256校验值） $ wget https://example.com/e1000e-3.6.3-ky10-patched.tar.gz $ tar -xzf e1000e-3.6.3-ky10-patched.tar.gz $ cd e1000e-3.6.3

3.2 应用补丁并验证（关键步骤，跳过即失败）

# 应用麒麟内核兼容补丁 $ patch -p1 < ../0001-e1000e-kernel-4.19-compat.patch # 输出应为：patching file src/e1000e_main.c, patching file src/Makefile # 应用签名警告抑制补丁（避免因警告中断编译） $ patch -p1 < ../0002-e1000e-disable-module-sign-warning.patch # 验证补丁效果：检查 e1000e_main.c 是否已替换 netif_napi_add 调用 $ grep -n "netif_napi_add" src/e1000e_main.c # 正确输出应为第1234行类似：netif_napi_add(netdev, &adapter->napi, e1000e_poll, 64); # 注意末尾参数为 64（非0），这是麒麟内核要求的最小weight值

3.3 编译与签名（四步不可省略）

# 步骤1：使用麒麟内核头文件路径编译（-C 指向内核源码树） $ make -C /lib/modules/$(uname -r)/build M=$(pwd)/src modules # 成功标志：生成 src/e1000e.ko # 步骤2：签名模块（必须！否则 insmod 拒绝加载） $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \ /usr/src/kernels/$(uname -r)/certs/signing_key.pem \ /usr/src/kernels/$(uname -r)/certs/x509_certificate.crt \ src/e1000e.ko # 步骤3：验证签名有效性 $ modinfo src/e1000e.ko | grep -i "sign" # 正确输出应包含：signature: 0x...（一长串十六进制）和 sig_id: PKCS#7 # 步骤4：备份原驱动（重要！后悔药） $ sudo cp /lib/modules/$(uname -r)/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko{,.bak}

参数说明：sign-file四个参数依次为：哈希算法（sha256）、私钥路径、公钥证书路径、待签名ko路径。麒麟内核要求sig_id必须为PKCS#7，若输出为module则签名失败。

3.4 加载与持久化（避免重启失效）

# 卸载原驱动（若已加载） $ sudo modprobe -r e1000e # 加载新驱动 $ sudo insmod src/e1000e.ko $ dmesg | tail -10 | grep e1000e # 正确输出示例：e1000e 0000:02:00.0: Intel(R) PRO/1000 Network Connection # 验证网卡识别 $ ip link show | grep "enp\|eth" # 应看到 enp2s0 或 eth0 等接口状态为 DOWN（正常，尚未配置IP） # 设置开机自动加载（写入 /etc/modules.d/） $ echo "e1000e" | sudo tee /etc/modules.d/e1000e.conf $ sudo dracut -f # 重建initramfs，确保启动时加载

4. rtl8125 驱动编译与签名：2.5G网卡的麒麟适配要点

4.1 源码包结构与补丁说明

r8125-9.005.01-ky10-patched.tar.gz结构如下：

r8125-9.005.01/ ├── src/ # 核心驱动源码 ├── patches/ │ ├── 0001-r8125-dma-coherent-fix.patch # 重写DMA映射，适配麒麟PCI一致性内存 │ └── 0002-r8125-export-symbols-for-ky10.patch # 显式导出 rtl8125_init_one 等符号 ├── Makefile.ky10 # 启用 -DUSE_KY10_DMA_API 编译宏 └── install.sh # 自动化安装脚本（含签名逻辑）

血泪经验：Realtek 官方驱动install.sh默认不签名，且硬编码insmod路径。麒麟V10必须禁用其原生install.sh，全程手动控制。

4.2 编译前关键修改（两处必须改）

进入src/目录后，需手动编辑两个文件：

# 修改1：src/Makefile —— 指定麒麟内核头文件路径与签名工具 $ sed -i 's/^KDIR :=.*$/KDIR := \/lib\/modules\/'$(uname -r)'\/build/' src/Makefile $ sed -i '/^ccflags-y/a ccflags-y += -DUSE_KY10_DMA_API' src/Makefile # 修改2：src/r8125_nic.c —— 修复DMA映射API调用（补丁已做，但需人工确认） $ grep -n "dma_set_coherent_mask" src/r8125_nic.c # 正确输出应为第892行：if (dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(64)) < 0) { ... } # 若看到 `pci_set_dma_mask` 则补丁未生效，需重打

4.3 编译与签名全流程（aarch64平台需额外处理）

$ cd ~/driver-build/rtl8125/r8125-9.005.01/src # 对于 x86_64 平台（标准流程） $ make clean && make modules $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \ /usr/src/kernels/$(uname -r)/certs/signing_key.pem \ /usr/src/kernels/$(uname -r)/certs/x509_certificate.crt \ r8125.ko # 对于 aarch64 平台（关键差异！需指定交叉编译器） # 麒麟V10 aarch64 内核要求模块用 aarch64-linux-gnu-gcc 编译 $ make clean $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- \ -C /lib/modules/$(uname -r)/build M=$(pwd) modules $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \ /usr/src/kernels/$(uname -r)/certs/signing_key.pem \ /usr/src/kernels/$(uname -r)/certs/x509_certificate.crt \ r8125.ko

参数说明：ARCH=arm64告知Makefile目标架构；CROSS_COMPILE=aarch64-linux-gnu-指定交叉编译器前缀。若系统未安装交叉工具链，需先sudo yum install aarch64-linux-gnu-gcc -y。

4.4 加载与冲突规避（Realtek驱动常见陷阱）

rtl8125 驱动易与内核内置r8169驱动冲突（尤其在旧BIOS中），必须彻底屏蔽：

# 1. 屏蔽 r8169 模块（永久） $ echo "blacklist r8169" | sudo tee /etc/modprobe.d/blacklist-r8169.conf $ echo "install r8169 /bin/true" | sudo tee -a /etc/modprobe.d/blacklist-r8169.conf # 2. 卸载并加载 rtl8125 $ sudo modprobe -r r8169 $ sudo insmod ./r8125.ko $ dmesg | grep -i "r8125\|rtl" # 正确输出：r8125 0000:03:00.0: RTL8125 2.5G Ethernet Controller # 3. 验证速率协商（关键！） $ ethtool enp3s0 | grep "Speed\|Duplex" # 应显示：Speed: 2500Mb/s, Duplex: Full # 若显示 1000Mb/s，检查网线（需Cat6A）及交换机端口是否开启2.5G模式

5. 常见问题排查：五条踩坑记录与现场急救方案

5.1 现象：insmod: ERROR: could not insert module e1000e.ko: Unknown symbol in module

• 原因：驱动调用了麒麟内核未导出的符号，如__const_udelay、netif_napi_add_weight。常见于未应用0001-e1000e-kernel-4.19-compat.patch或补丁打错行。
• 解决：

  # 查看具体缺失符号 $ dmesg | tail -20 | grep "Unknown symbol" # 定位到符号后，检查补丁是否覆盖对应文件。例如缺失 __const_udelay，则需在 src/e1000e_main.c 开头添加： # #include <linux/delay.h> # 并确保 patch 中已加入该行。

5.2 现象：make报错fatal error: linux/pci.h: No such file or directory

• 原因：kernel-devel包未安装，或安装版本与当前内核不匹配（如uname -r为4.19.90-24.4.ky10.x86_64，但安装了kernel-devel-4.19.90-23.1.ky10.x86_64）。
• 解决：

  # 严格匹配版本 $ rpm -qa | grep kernel-devel $ sudo yum remove kernel-devel-$(rpm -q kernel-devel | sed 's/kernel-devel-//; s/\.x86_64$//') $ sudo yum install kernel-devel-$(uname -r) -y # 验证头文件路径 $ ls /lib/modules/$(uname -r)/build/include/linux/pci.h

5.3 现象：dmesg显示e1000e 0000:02:00.0: Cannot map resource 0或rtl8125: probe of 0000:03:00.0 failed with error -12

• 原因：内存分配失败（-12 = ENOMEM），本质是麒麟内核对ioremap()的地址空间限制更严，旧驱动未做pci_resource_len()边界检查。
• 解决：

  # 在驱动源码中增加资源长度校验（以 rtl8125 为例） # 编辑 src/r8125_nic.c，找到 pci_request_regions() 调用前，插入： // Add resource length check for Kylin V10 if (!pci_resource_len(pdev, 0)) { dev_err(&pdev->dev, "Invalid PCI BAR0 length\n"); return -ENODEV; }

5.4 现象：网卡能加载，但ip link show显示state DOWN，且ethtool enpXsY显示Link detected: no

• 原因：BIOS中禁用了PCIe ASPM（Active State Power Management），导致麒麟V10无法正确初始化PCIe链路。
• 解决：

  # 临时禁用ASPM（验证用） $ echo 'options pcie_aspm policy=performance' | sudo tee /etc/modprobe.d/aspm.conf $ sudo update-initramfs -u # Ubuntu系；麒麟V10用： $ sudo dracut -f $ sudo reboot # 进BIOS，找到 `Advanced > PCIe Configuration > ASPM` 设为 `Disabled`

5.5 现象：rtl8125.ko加载后dmesg报rtl8125: Unknown symbol rtl8125_init_one，但modinfo r8125.ko显示该符号存在

• 原因：模块签名时未使用与内核编译相同的证书，导致符号表校验失败。
• 解决：

  # 强制使用内核源码树中的证书（绝对路径！） $ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \ /usr/src/kernels/$(uname -r)/certs/signing_key.pem \ /usr/src/kernels/$(uname -r)/certs/x509_certificate.crt \ ./r8125.ko # 验证证书指纹是否一致 $ openssl x509 -in /usr/src/kernels/$(uname -r)/certs/x509_certificate.crt -noout -fingerprint

6. 验证驱动功能完整性：从链路层到应用层的七步测试法

装完驱动只是起点，能否稳定承载业务流量才是关键。我习惯用一套七步测试法闭环验证，每一步失败都指向不同层级的问题，比单纯ping有效得多。

6.1 步骤1：硬件链路层连通性（绕过驱动，直击PHY）

# 使用 mii-tool（e1000e）或 ethtool（rtl8125）读取物理层寄存器 $ sudo ethtool -d enp2s0 | head -20 # 关键字段： # Link detected: yes # PHY已检测到链路 # Speed: 1000Mb/s # 协商速率为千兆（e1000e）或2500Mb/s（rtl8125） # Duplex: Full # 全双工 # 若为 "no"，检查网线、交换机端口、BIOS PCIe设置

6.2 步骤2：内核网络栈注册（确认驱动接管设备）

# 检查设备是否绑定到正确驱动 $ lspci -k -s $(lspci | grep Ethernet | head -1 | awk '{print $1}') # 输出应包含： # Kernel driver in use: e1000e # 或 r8125 # Kernel modules: e1000e, r8169 # r8169 必须在 modules 列但不在 "in use" 行 # 检查驱动参数是否生效 $ cat /sys/module/e1000e/parameters/InterruptThrottleRate # 应为 3（麒麟V10推荐值，平衡延迟与CPU占用）

6.3 步骤3：基础网络功能（IP配置与ARP）

# 配置IP并测试本地环回 $ sudo ip addr add 192.168.1.100/24 dev enp2s0 $ sudo ip link set enp2s0 up $ ping -c 3 127.0.0.1 # 测试网关ARP解析（关键！驱动需正确处理L2） $ sudo ip neigh flush all $ ping -c 3 192.168.1.1 $ ip neigh show | grep 192.168.1.1 # 正确输出：192.168.1.1 dev enp2s0 lladdr 00:11:22:33:44:55 REACHABLE # 若为 `INCOMPLETE`，说明驱动发送ARP请求失败，检查 `e1000e_main.c` 中 `e1000e_clean_tx_irq` 是否被补丁正确修复

6.4 步骤4：TCP吞吐压力测试（暴露驱动稳定性）

# 使用 iperf3 进行10分钟持续压测（服务端在另一台麒麟V10机器） # 服务端：iperf3 -s -i 1 # 客户端： $ iperf3 -c 192.168.1.200 -t 600 -i 10 -P 4 --get-server-output # 关键指标： # [ ID] Interval Transfer Bitrate Retr # [ 4] 0.00-10.00 sec 1.12 GBytes 962 Mbits/sec 0 # 若 `Retr`（重传数）持续增长 > 100，或 `Bitrate` 波动超±20%，说明驱动在高负载下丢包，需检查 `e1000e_clean_rx_irq` 中的 `rx_desc->wb.upper.status_error` 解析逻辑是否适配麒麟内核

6.5 步骤5：中断亲和性与CPU绑定（生产环境刚需）

# 查看当前中断分布 $ cat /proc/interrupts | grep enp2s0 # 示例：123: 456789 0 0 0 IR-PCI-MSI-edge enp2s0 # 将中断绑定到CPU1（避免与系统进程争抢CPU0） $ echo 2 | sudo tee /proc/irq/123/smp_affinity_list # 验证 $ cat /proc/irq/123/smp_affinity_list # 应输出：1（注意：此处2表示CPU1，因CPU编号从0开始） # 持久化（写入 /etc/rc.local） $ echo 'echo 2 > /proc/irq/123/smp_affinity_list' | sudo tee -a /etc/rc.local

6.6 步骤6：内核日志深度分析（定位偶发故障）

# 启用e1000e详细日志（需重新编译驱动时加 -DE1000E_DEBUG） $ echo 'options e1000e debug=16' | sudo tee /etc/modprobe.d/e1000e-debug.conf $ sudo modprobe -r e1000e && sudo modprobe e1000e # 捕获1小时日志，过滤关键事件 $ sudo dmesg -w | grep -E "(e1000e|ERROR|WARNING|reset)" > /tmp/e1000e-log.txt & $ sleep 3600 && sudo kill %1 # 分析重点： # - "Reset adapter" 出现频率 > 3次/小时 → 硬件或电源问题 # - "TX hang" → 驱动tx cleanup逻辑缺陷（检查补丁中 `e1000e_clean_tx_irq`） # - "RX desc count" 为0 → ring buffer溢出，需调大 `RxDescriptors` 参数

6.7 步骤7：业务场景模拟（最终验收）

在实验室模拟某跨平台系统的真实流量模型：

• 每秒 500 个 UDP 小包（64字节） + 50 个 TCP 大包（1500字节）
• 持续运行 24 小时，监控netstat -s | grep -A 5 "Udp\|Tcp"中的inErrors、fragments、retransmits

# 使用 pktgen 模拟（需内核启用 CONFIG_NET_PKTGEN） $ cd /proc/net/pktgen/ $ echo "add_device enp2s0" > kpktgend_0 $ echo "dst 192.168.1.200" > enp2s0 $ echo "count 0" > enp2s0 # 0 = forever $ echo "pkt_size 64" > enp2s0 $ echo "flag UDP" > enp2s0 $ echo "start" > enp2s0 # 观察 /proc/net/snmp 中 UdpInErrors 是否归零

从那以后我每次给麒麟V10部署网卡驱动，都强制走一遍这七步测试——不是为了炫技，而是因为曾经在交付现场，第六步iperf3压测到第8分钟时Bitrate突然跌到0，dmesg里静静躺着一行e1000e 0000:02:00.0: Reset adapter，而客户就在身后盯着屏幕。现在，我把补丁、签名、测试脚本全打包进一个ky10-driver-check.sh，双击运行，绿字刷屏，心里才真正踏实。希望帮到你。

本文还有配套的精品资源，点击获取