常见问题解决 --- Intel X722 网卡故障分析报告

高负载下硬件停止响应问题根因及解决方案

适用设备：c3h 服务器（X710 / X722 Fortville 系列网卡）

---

一、故障现象

系统事件日志中反复出现 NDIS Event ID 10400 / 252，报错信息为"网络驱动检测到其硬件已停止响应命令"，网卡随后自动重置。故障表现为瞬时丢包、ping 超时、连接中断，约数秒后自愈。

关键数据

项目	详情
故障时段	集中于下午 4 点等业务高峰时段
累计重置	63 次
影响芯片	Intel X710 / X722（Fortville 系列）
高危固件	NVM 4.00 / 4.10 及以下版本

---

二、根因分析

事件日志中的核心报错本质是网卡在高吞吐量下发生 TX Hang（发送队列卡死），驱动检测到硬件不再响应命令后，强制执行 Reset 以恢复通信。此为 Intel X722 / X710（Fortville）系列芯片的已知固件缺陷。

故障集中于业务高峰时段的原因：流量越大、并发越高，越容易触发固件中发送队列卡死的 Bug；同时，部分硬件卸载功能（如 LSO）在高并发场景下会放大该问题的发生概率。

重要结论

重置 63 次并不代表网卡硬件损坏。绝大多数情况下，根因为固件 Bug、驱动版本错配与硬件卸载功能配置不当三者叠加所致。根治方案是升级固件与驱动，而非仅靠关闭功能项临时缓解。

故障触发流程

text

网卡在高吞吐量下触发固件 Bug
        ↓
发送队列（TX Queue）卡死
        ↓
NDIS 驱动看门狗超时，检测到硬件不再响应命令
        ↓
驱动记录 Event ID 10400 / 252，强制执行硬件 Reset
        ↓
重置期间网络中断，数秒后自动恢复（表现为"自愈"）

---

三、解决方案（按优先级排列）

---

（一）优先级一：调整网卡高级属性——立即应急止血

为什么放在第一位？
此操作无需等待固件包、无需联系厂商、无需业务窗口，5 分钟内即可完成，且对绝大多数现场有立竿见影的效果——是争取后续根因修复时间的关键手段。

操作路径：设备管理器 → 该网卡 → 属性 → 高级，按下表修改各项参数。

设置项	推荐值	优先级	说明
Large Send Offload V2（IPv4）	Disabled	最高	关闭后大多数现场 10400 报错直接消失
Large Send Offload V2（IPv6）	Disabled	最高	与 IPv4 同步关闭
Energy Efficient Ethernet（EEE）	Disabled	最高	服务器场景无需节能以太网功能
VMQ（虚拟机队列）	Disabled	高	运行 Hyper-V 或虚拟化环境时必须关闭
Interrupt Moderation（中断节流）	调整	中	先调整参数，必要时关闭
TCP / UDP Checksum Offload	Disabled	中	作为进一步排查项尝试关闭

---

驱动 / 固件升级后，是否有必要重新开启这些功能？

结论：升级完成后，建议分项评估是否恢复，而非全部重新开启。

以下为每项功能的恢复建议：

功能项	升级后是否建议恢复	理由
LSO V2（IPv4 / IPv6）	建议恢复开启	固件 Bug 修复后，LSO 的 TX Hang 触发路径已消除；恢复后可降低 CPU 负载、提升大文件传输吞吐量。恢复后需观察 2—3 个业务高峰日确认无 10400 事件。
EEE	建议保持关闭	服务器 24 小时在线，EEE 的节能意义极小，而其引入的链路状态切换在任何固件版本下都是潜在的抖动来源，保持关闭是服务器最佳实践。
VMQ	视环境决定	若运行 Hyper-V 且 VM 数量较多，固件升级后可尝试重新开启并观察；若为物理机纯业务场景，建议保持关闭。
Checksum Offload	建议恢复开启	校验和卸载对 CPU 压力有实质性影响，固件修复后可恢复，同样需高峰期观察验证。
Interrupt Moderation	保持默认或按需调整	维持驱动默认值即可，无需特别处理。

恢复操作建议： 不要一次性全部恢复，建议每次只恢复一项，间隔一个业务高峰日观察后再恢复下一项，便于快速定位问题。

---

（二）优先级二：关闭网卡电源管理

1. 设备管理器 → 该网卡 → 属性 → 电源管理，取消勾选"允许计算机关闭此设备以节约电源"；
2. 控制面板 → 电源选项，将电源计划切换为**"高性能"**；
3. 高性能计划 → 更改计划设置 → 高级电源设置 → PCI Express → 链路状态电源管理，设置为**"关闭"**。

---

（三）优先级三：禁用 Intel PROSet（DMIX）

此为 Dell / Intel 针对同类 X722 / X710 故障给出的官方 Workaround 之一。禁用 PROSet 后，网卡驱动本身继续正常工作，仅关闭 PROSet 功能层。

注意事项

以下命令须在**管理员权限的 CMD（命令提示符）**中运行，不得在 PowerShell 中执行。

cmd

"C:\Program Files\Intel\Umb\Winx64\PROSETDX\DxSetup.exe" DMIX=0 /qn

---

（四）优先级四：升级网卡固件（NVM）——根因修复

此步骤为彻底解决问题的关键操作，应急止血后须尽快安排执行。

X722 系列 NVM 固件经历多个版本迭代，专门修复了高负载下发送卡死类 Bug。Intel 700 系列最新 NVM 版本为 6.50，而许多服役机器仍停留在 4.00 / 4.10 等问题高发版本。

注意事项

因使用 c3h 服务器，必须使用 c3h 官方适配验证的固件包，禁止直接使用 Intel 官网通用包刷写，以避免兼容性问题。

具体操作步骤：

1. 登录 c3h 官网「服务支持 → 下载中心」，按服务器型号（如 R4900 G3、R2700 G3 等）查找兼容性列表或版本说明书，找到 X722 网卡（部件号类似 NIC-ETH-X722）对应的固件包；
2. 升级前在设备管理器或 c3h HDM / BMC 管理界面中记录当前固件版本与驱动版本，并核对 c3h 提供的**「固件 + 驱动 + BIOS」兼容矩阵**；
3. 选择**业务低峰期（建议凌晨）**执行升级，升级前做好系统快照或数据备份；
4. 如不确定机型或固件包版本，可直接拨打 c3h 技术支持热线 400-810-0504，提供服务器型号及事件日志，c3h 对此问题较为熟悉，可提供对应固件包及升级指引。

---

（五）优先级五：升级配套网卡驱动

固件与驱动版本错配本身亦可触发 Reset。升级完固件后，须同步将驱动更新至 c3h 为该机型认证的配套版本，不得使用 Windows Update 自动安装的泛用驱动或 Intel 官网通用驱动。

1. 从 c3h 官网下载该机型对应的 Windows 网卡驱动；
2. 固件升级完成后立即配套升级驱动，不得分开操作；
3. 升级完成后，在设备管理器中确认驱动版本与 c3h 兼容矩阵一致；
4. 升级后于业务高峰时段观察 1—2 天，确认 Event ID 10400 不再出现。

如果 c3h 配套驱动安装后仍有问题，可尝试使用 Intel 官网通用驱动再验证一次，链接见文末参考链接。

---

四、外部因素排查

虽然事件日志已明确指向网卡侧问题，但鉴于故障集中于高峰时段，仍需同步排查以下外部因素。

排查项	检查内容	排查方法
交换机端口	CRC 错误、流控不匹配、端口 flap	查看对端交换机端口日志，确保两端流控配置一致
线缆 / 光模块	线缆质量、接口虚接	更换优质网线交叉验证，检查接口是否松动
散热状况	进风温度、风扇策略、热堆积	检查服务器进风温度及风扇转速，确认机箱内无热堆积

---

五、实施路线建议

阶段	操作内容	预期效果	是否需重启
立即止血	执行优先级一、二（关 LSO、EEE、VMQ，关闭电源管理，切高性能电源计划）	重置频率显著降低或停止	部分需重启
辅助止血	执行优先级三（禁用 PROSet DMIX）	进一步降低触发概率	无需重启
根因修复	联系 c3h 获取固件包，升级 NVM 固件及配套驱动（优先级四、五）	彻底消除 TX Hang 根因	需重启
功能恢复评估	固件升级后，按建议逐项恢复 LSO、Checksum Offload 等功能，每次恢复一项并观察一个高峰日	在稳定前提下恢复性能最优配置	部分需重启
验证观察	升级后观察 3—5 个业务高峰日，持续检查事件日志	Event ID 10400 不再出现	无需重启
兜底方案	升级后仍复现，则拨打 c3h 400 报修，提交完整日志申请备件交叉验证	排除硬件批次问题	视情况而定

---

参考链接

• https://support.lenovo.com/cm/zh/solutions/ht507020/
• https://support.lenovo.com/sr/en/downloads/ds506365
• https://support.lenovo.com/iq/zc/solutions/ht508005-link-issues-with-intel-x722-network-adapter-lenovo-thinksystem
• https://www.intel.cn/content/www/cn/zh/search.html#cf-tabfilter=Downloads&cf-downloadsppth=以太网产品,700%20系列网络适配器（高达%2040GbE）,英特尔®%20以太网网络适配器%20X722
• https://www.c3h.com/cn/BizPortal/DownLoadAccessory/AccessoryDetail.aspx?ID=cc746a32-d053-4c30-be0d-9d8b78c2d241

https://www.cnblogs.com/smith9527/p/10522501.html

 

 

 

 

 

 

 

 

为什么关闭这些功能可以缓解故障？

以下逐项解释每个功能关闭后能缓解故障的底层原因，帮助理解这不是"玄学"，而是有明确的工程逻辑。

---

① Large Send Offload V2（LSO）—— 缓解效果最显著

LSO 是一种将大块数据的 TCP 分段工作从 CPU 卸载到网卡硬件完成的机制，目的是减轻 CPU 负担、提升吞吐量。

触发故障的原因：

在 Fortville 系列固件存在 Bug 的版本中，当网卡以硬件方式处理 LSO 分段时，发送队列（TX Queue）的描述符管理存在竞争条件（Race Condition）缺陷。具体表现为：在高并发大流量场景下，硬件在处理超大 LSO 段时会陷入内部死锁状态，导致发送队列停止推进，即 TX Hang。

关闭后为何缓解：

关闭 LSO 后，TCP 分段工作回退由操作系统协议栈（NDIS）完成，网卡只需处理已经分好的标准大小数据包。发送队列的操作模式从"处理巨型 LSO 段"变为"处理普通小包"，完全绕开了固件中触发死锁的代码路径，因此 TX Hang 不再发生。

 

代价： CPU 占用率会略有上升（需承担分段计算），但在服务器场景下通常完全可以接受。

---

② Energy Efficient Ethernet（EEE，节能以太网）—— 消除状态切换风险

EEE 是 IEEE 802.3az 标准定义的功能，允许网卡在链路空闲时进入低功耗睡眠状态（LPI，Low Power Idle），有流量时再唤醒。

触发故障的原因：

在业务高峰时段，流量呈现"突发性"特征——短暂空闲后立刻涌入大量数据包。EEE 会在空闲片段将网卡推入 LPI 状态，而部分固件版本在从 LPI 唤醒的过渡阶段存在时序缺陷，与 TX Hang 的触发窗口叠加，加剧了发送队列的不稳定性。此外，EEE 的唤醒延迟（通常为数微秒到数百微秒）本身也会在高并发场景下造成微小抖动，被看门狗误判的概率上升。

关闭后为何缓解：

网卡链路始终保持全功率运行状态，消除了 LPI 唤醒的状态切换过程，移除了一个额外的不稳定触发源。

代价： 极小的额外功耗，在服务器场景下忽略不计。

---

③ VMQ（Virtual Machine Queue，虚拟机队列）—— 消除队列竞争

VMQ 是专为 Hyper-V 等虚拟化环境设计的功能，允许网卡为每个虚拟机分配独立的硬件接收队列，减少 VM 间的数据包分发开销。

触发故障的原因：

VMQ 启用后，网卡需要在硬件层面维护多个并行队列，并动态分配接收描述符。在 Fortville 固件的 Bug 版本中，多队列的描述符管理与 TX Hang 缺陷存在交互效应——VMQ 的队列分配逻辑会加重硬件调度器的负担，在高并发时进一步压缩触发 TX Hang 的阈值。即便在非虚拟化场景下，VMQ 仍会保持多队列处于激活状态，造成不必要的硬件资源消耗。

关闭后为何缓解：

网卡回退为单队列或标准 RSS 模式运行，减少硬件内部的队列管理开销，降低触发固件 Bug 的概率。

代价： 虚拟化环境下 VM 间数据包分发效率略有下降，但对稳定性的收益远大于此。

---

④ TCP / UDP Checksum Offload —— 减少硬件计算路径介入

校验和卸载将数据包完整性校验的计算从 CPU 卸载到网卡硬件完成。

触发故障的原因：

校验和卸载本身不是 TX Hang 的主要触发因素，但在固件存在 Bug 的状态下，硬件卸载路径越多，涉及的固件代码路径越复杂，潜在的竞争条件触发概率越高。关闭校验和卸载是在其他措施效果不足时的进一步排查项。

关闭后为何缓解：

减少网卡硬件参与数据路径处理的环节数量，降低固件 Bug 被触发的总体概率。

代价： CPU 承担额外的校验和计算，在万兆以上流量下可能有明显感知，建议优先关闭 LSO 和 EEE，校验和卸载作为后备手段。

 

 注意如果有多张网卡需要同时都要配置