Патч EEPROM Intel X520 (бит IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) для разблокировки всех SFP+ трансиверов
Автор темы задокументировал, что карты X520 на базе 82599 несут недокументированный бит EEPROM (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, младший бит слова возможностей по смещению байта 0x58, обычно 0xFC заблокировано / 0xFD разблокировано), который решает, принимаются ли не-Intel активные SFP+ модули на ESXi и Windows, где опция драйвера Linux недоступна. В статье приведён поиск ID устройства через lspci -nn, чтение через ethtool -e enp1s0 offset 0x58 length 1 и запись через ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 valuue 0xfd, с предупреждениями менять только этот бит. Читатели сообщали результаты на X520-DA2, картах с eBay, использованных с ESXi и модулями Finisar, Dell-брендированной X520/i350 rNDC (0xFC), HPE NC560SFP+ (уже 0xFD, заработало с MikroTik S+RJ10) и 82599, всё же отказавшемся от модуля Ubiquiti 10GbE RJ45.
- Оборудование: Intel X520-DA1, Intel X520-DA2, Dell Intel 2P X520/2P i350 rNDC, HPE NC560SFP+, Intel 82599ES
- Трансиверы: Finisar SFP+, MikroTik S+RJ10, Ubiquiti UF-RJ45-10G
- Форм-фактор: SFP+
Симптомы / сообщения:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Прочитайте байт 0x58, установите только младший бит (например, с 0xFC на 0xFD) через ethtool -E и magic, составленный из PCI device и vendor ID; после этого карта принимает стороннюю активную оптику в любой ОС. Пассивные DAC и обычные SFP модули обычно работают даже при заблокированном бите.
OEM-карты от HPE, Dell или Cisco могут поставляться уже разблокированными, что говорит о том, что блокировка - это политика Intel; если модуль всё равно не работает после разблокировки, проверьте его под Linux с allow_unsupported_sfp, чтобы отделить реальную несовместимость от блокировки.