Patching the Intel X520 EEPROM (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP bit) to unlock all SFP+ transceivers
The thread starter documented that 82599-based X520 cards carry an undocumented EEPROM bit (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, lowest bit of the capability word at byte offset 0x58, typically 0xFC locked / 0xFD unlocked) that decides whether non-Intel active SFP+ modules are accepted on ESXi and Windows, where the Linux driver option is unavailable. The write-up gives the lspci -nn lookup of the device ID, ethtool -e enp1s0 offset 0x58 length 1 to read, and ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd to write, with warnings to flip only that bit. Followers reported results on X520-DA2, eBay cards used with ESXi and Finisar modules, Dell-branded X520/i350 rNDC (0xFC), HPE NC560SFP+ (already 0xFD, worked with a MikroTik S+RJ10) and an 82599 that still refused a Ubiquiti 10GbE RJ45 module.
- Hardware: Intel X520-DA1, Intel X520-DA2, Dell Intel 2P X520/2P i350 rNDC, HPE NC560SFP+, Intel 82599ES
- Transceivers: Finisar SFP+, MikroTik S+RJ10, Ubiquiti UF-RJ45-10G
- Form factor: SFP+
Symptoms / messages:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Read byte 0x58, set only the lowest bit (e.g. 0xFC to 0xFD) with ethtool -E and the magic made of PCI device and vendor ID; afterwards the card accepts third-party active optics on any OS. Passive DACs and plain SFP modules usually work even when locked.
OEM cards from HPE, Dell or Cisco may ship unlocked, suggesting the lock is an Intel policy setting; if a module still fails after unlocking, test it under Linux with allow_unsupported_sfp to separate a real incompatibility from the lock.