Symptoms:
During periods of sustained, high-throughput network operations (such as scheduled enterprise backup windows or large-scale data migrations), you observe the following symptoms across affected ESXi hosts:
vmkX), occasionally exceeding ~1000+ ms.vmnicX) unexpectedly drop link states or flap simultaneously under heavy concurrent I/O./var/log/vmkernel.log), concurrent hardware core trace dumps are registered across multiple physical interfaces managed by the same network controller chip:YYYY-MM-DDTHH:MM:SS.fffZ In(182) vmkernel: cpuX:XXXXXXX)[driver_name]: dev_dump_fw_trace: [vmnicX : <address>] Dumping FW Trace:YYYY-MM-DDTHH:MM:SS.fffZ In(182) vmkernel: cpuX:XXXXXXX)[driver_name]: dev_dump_fw_trace: [vmnicY : <address>] Dumping FW Trace:YYYY-MM-DDTHH:MM:SS.fffZ In(182) vmkernel: cpuX:XXXXXXX)netschedHClk: NetSchedHClkPortQuiesce: vmnicX: received a force quiesce for port <port_ID>YYYY-MM-DDTHH:MM:SS.fffZ In(182) vmkernel: cpuX:XXXXXXX)Uplink: vmnicX: set flags 0xXXXXX DEVICE_REENABLING"txqueue": { "count": 73, "uplink_stats": [{"pps": 175, "eps": 0, "qstops": 0}], "active": 1 }VMware vCenter Server
VMware vSphere ESXi
This issue occurs due to a transmit completion timeout defect within certain legacy network adapter driver branches when handling large, offloaded packet streams under extreme load.
When large-scale network operations occur, Transmit Segment Offloading (TSO) passes massive consolidated data segments (frequently exceeding standard Jumbo Frame MTU limits) directly down to the interface layer.
Due to design limitations in the outdated driver module, multi-queue balancing logic fails to distribute these heavy outbound bursts. As a result, the driver forces 100% of outbound serialization through a single hardware queue index (Queue 0).