Subject: [Help needed] net_ice: MDD event (Malicious Driver Detection) on TX queue when using rte_et

[2524745593]

We are seeing a reproducible and concerning issue when using the net_ice PMD with DPDK 22.11.2, and we would appreciate your help diagnosing it.

Summary
- Environment:
- DPDK: 22.11.2
- net_ice PCI device: 8086:159b
- ice kernel driver: 1.12.7
- NIC firmware: FW 7.3.6111681 (NVM 4.30)
- IOVA mode: PA, VFIO enabled
- Multi-process socket: /var/run/dpdk/PGW/mp_socket
- NUMA: 2, detected lcores: 112
- Bonding: pmd_bond with bonded devices created (net_bonding0 on port 4, net_bonding1 on port 5)
- Driver enabled AVX2 OFFLOAD Vector Tx (log shows "ice_set_tx_function(): Using AVX2 OFFLOAD Vector Tx")

- Problem statement:
- Our application calls rte_eth_tx_prepare before calling rte_eth_tx_burst as part of the normal transmission path.
- After the application has been running for some time (not immediate), the kernel/driver emits the following messages repeatedly:
- ice_interrupt_handler(): OICR: MDD event
- ice_interrupt_handler(): Malicious Driver Detection event 3 by TCLAN on TX queue 1025 PF# 1
- We are using a single TX queue (application-level single queue) and are sending only one packet per burst (burst size = 1).
- The sequence is: rte_eth_tx_prepare (returns) -> rte_eth_tx_burst -> MDD events occur later.
- The events affect stability and repeat over time.

Relevant startup logs (excerpt)
EAL: Detected CPU lcores: 112
EAL: Detected NUMA nodes: 2
EAL: Selected IOVA mode 'PA'
EAL: VFIO support initialized
EAL: Probe PCI driver: net_ice (8086:159b) device: 0000:3b:00.1 (socket 0)
ice_load_pkg_type(): Active package is: 1.3.45.0, ICE COMMS Package (double VLAN mode)
ice_dev_init(): FW 7.3.6111681 API 1.7
...
bond_probe(3506) - Initializing pmd_bond for net_bonding0
bond_probe(3592) - Create bonded device net_bonding0 on port 4 in mode 1 on socket 0.
...
ice_set_tx_function(): Using AVX2 OFFLOAD Vector Tx (port 0).
TELEMETRY: No legacy callbacks, legacy socket not created

What we have tried / preliminary observations
- Confirmed application calls rte_eth_tx_prepare prior to rte_eth_tx_burst.
- Confirmed single TX queue configuration and small bursts (size = 1) — not high-rate, not a typical high-burst/malicious pattern.
- The MDD log identifies "TX queue 1025"; unclear how that maps to our DPDK queue numbering (we use queue 0 in the app).
- No obvious other DPDK errors at startup; interface initializes normally and vector TX is enabled.
- We suspect the driver's Malicious Driver Detection (MDD) is triggering due to some descriptor/doorbell ordering or offload interaction, possibly related to AVX2 Vector Tx offload.

Questions / requests to the maintainers
1. What specifically triggers "MDD event 3 by TCLAN" in net_ice? Which driver check/threshold corresponds to event type 3?
2. How is the "TX queue 1025" value computed/mapped in the log? (Is it queue id + offset, VF mapping, or an internal vector id?) We need to map that log value to our DPDK queue index.
3. Can the rte_eth_tx_prepare + rte_eth_tx_burst call pattern cause MDD detections under any circumstances? If so, are there recommended usage patterns or ordering constraints to avoid false positives?
4. Are there known firmware/driver/DPDK version combinations with similar MDD behavior? Do you recommend specific NIC firmware, kernel driver, or DPDK versions as a workaround/fix?
5. Any suggested workarounds we can test quickly (e.g., disable vector TX offload, disable specific HW offloads, change interrupt/queue bindings, or adjust doorbell behavior)?

[Simon-Intel]

Hi 2524745593,

Thank you for reaching out to Intel Support. We acknowledge receipt of your concern and want to assure you that assisting you is our top priority. To effectively troubleshoot the issue you're facing, we require some additional information from your end.

Could you kindly provide the following details?

1. System/Board details
2. Complete Ethernet card details
3. Was the card shipped with the system or purchased separately?
4. Link to the driver currently in use

Your prompt response with this information will greatly assist us in diagnosing and resolving the issue as quickly as possible.

We look forward to hearing from you soon.

Best regards,

Simon

Intel Customer Support Technician

[2524745593]

Hello Simon,

Thanks for your prompt response. Please find the requested details below.

1、System / Board details
Hostname: 209-2
OS: Oracle Linux Server 8.10 (CPE: cpe:/o:oracle:linux:8:10:server)
Kernel: 5.15.0-305.176.4.el8uek.x86_64
Architecture: x86-64
System Manufacturer / Model: Dell Inc. PowerEdge R740xd
System Serial Number: D9V4TD3
SMBIOS: 3.2.0
Additional: NVRAM_CLR option present in BIOS; system reports “No errors detected” in System Boot Information

2、Complete Ethernet card details
Adapter: Intel Ethernet Controller E810-XXV for SFP (rev 02)
Subsystem: Intel Ethernet Network Adapter E810-XXV-2
VPD Product Name: Intel(R) Ethernet Network Adapter E810-XXVDA2
Part Number (VPD): K57775-011
Device Serial (VPD): B49691C3C99C
PCI address: 0000:3b:00.1 (NUMA node 0, IOMMU group 63)
MSI-X: 1024 vectors
SR-IOV capability: Total VFs 128 (currently Number of VFs: 0)
Kernel driver in use (current): igb_uio (device is bound to userspace for DPDK)
Kernel module available: ice (version 1.12.7)
Module path: /lib/modules/5.15.0-305.176.4.el8uek.x86_64/updates/drivers/net/ethernet/intel/ice/ice.ko
DDP package reference: firmware: intel/ice/ddp/ice.pkg
NVM version: 4.30 (installer package link below)
Note: Since the port is currently bound to igb_uio for DPDK, ethtool -i output is not available unless we temporarily bind back to ice. We can rebind and provide ethtool -i and -S if needed.

3、Was the card shipped with the system or purchased separately?
Purchased separately.

4、Link to the driver currently in use
Kernel driver (ice) 1.12.7:
ice-1.12.7.tar.gz
https://www.intel.cn/content/www/cn/zh/download/19630/789309/intel-network-adapter-driver-for-e810-series-devices-under-linux.html
NVM Version 4.30:
E810_NVMUpdatePackage_v4_30_Linux.tar.gz
https://www.intel.cn/content/www/cn/zh/download/19624/786044/non-volatile-memory-nvm-update-utility-for-intel-ethernet-network-adapter-e810-series.html

Additional context

We operate two servers with identical configurations (same model, NICs, drivers, and NVM). The server named “208” has not shown any MDD so far, while “209” has hit “MDD event 3” multiple times.

Best regards,
Raza

[Fikri_Intel]

Hi 2524745593,

Thank you for your response. To help isolate the issue further, we kindly request you to perform the following actions:

1) Perform a clean removal of the current Ethernet driver: 

https://www.intel.com/content/www/us/en/support/articles/000058304/ethernet-products.html

2) Download and install the Intel generic driver from the link below:

https://www.intel.com/content/www/us/en/download/15084/intel-ethernet-adapter-complete-driver-pack.html

3) Please refer to the Intel Ethernet documentation available here:

Intel Ethernet Linux : https://intel.github.io/ethernet-linux/

Additionally, you may review the DPDK reference materials for guidance:

https://doc.dpdk.org/guides-25.07/index.html

Ensure the following components are updated to the latest recommended versions:

- DPDK: Version 23.07 or newer

- ICE Kernel Driver 2.2.9 or latest

- NIC Firmware (NVM) 4.80 or latest

- COMMS DDP Package 1.3.43

Please proceed with the steps above and share the results for further analysis.

Regards,

Fikri O.

[2524745593]

Hello Fikri O,

Thanks for the follow-up. Our current DPDK/ICE/NVM stack has been stable for a long time in our test environment. We recently deployed the same HW/SW to two new servers; only “209” has reported “MDD event 3,” while “208” has not.

This is a production environment, so we cannot freely upgrade/replace drivers or firmware at this time. Please advise on non-disruptive troubleshooting steps.

Could you please:
1) Clarify exactly what “MDD event 3 by TCLAN” indicates on E810 .
2) Provide a precise data‑collection checklist and exact debug flags/parameters you want us to run. We can promptly collect:
- dmesg around the event window,
- ethtool -i/-S/-k (we can briefly rebind to ice),
- lspci -vvv for the device,
- devlink dev info/health,
- dpdk-devbind status and rte_eth_stats/xstats.

If there is a minimal, targeted mitigation that does not require a full stack upgrade, please advise. We will follow your exact steps and share the artifacts.

Best regards,
Raza

[Simon-Intel]

Hi 2524745593,

Thank you for your response.

Please allow me some time to review this internally. I will get back to you as soon as I have an update.

Thank you for your patience.

Best regards,

Simon

Intel Customer Support Technician

[2524745593]

Hi Simon,

Thank you for the update.I appreciate your help and will wait for your feedback.

Best regards,
Raza

[Simon-Intel]

Hi 2524745593,

Thank you for your patience.

We suggest updating the Linux Driver to the latest version (2.3.10) to rule out any false positives. Along with that, please update the NVM to the latest version.

Additionally, please note that Oracle Linux Server 8.10 is not listed in the supported OS, which may contribute to the issue. For more information, you may refer to the following article: Supported Operating Systems for Retail Intel® Ethernet Adapters

If you have any further questions or need assistance, please feel free to reach out.

Regards,

Simon

Intel Customer Support Technician

[Poojitha]

Hi 2524745593,

Greetings for the day!

We are following up to check if you were able to find the information we shared. Kindly confirm at your earliest convenience, so that we can continue assisting you in resolving this matter.

We appreciate your understanding!

Regards,

Poojitha

Intel Customer Support Technician