Fazendo patch na EEPROM da Intel X520 (bit IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) para destravar todos os transceptores SFP+
Quem abriu o tópico documentou que placas X520 baseadas em 82599 carregam um bit de EEPROM não documentado (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, o bit mais baixo da palavra de capacidade no offset de byte 0x58, tipicamente 0xFC travado / 0xFD destravado) que decide se módulos SFP+ ativos não-Intel são aceitos no ESXi e no Windows, onde a opção do driver Linux não está disponível. O texto traz a consulta lspci -nn do device ID, ethtool -e enp1s0 offset 0x58 length 1 para ler, e ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd para escrever, com avisos para alterar só esse bit. Quem acompanhou reportou resultados em X520-DA2, placas de eBay usadas com ESXi e módulos Finisar, rNDC X520/i350 de marca Dell (0xFC), HPE NC560SFP+ (já em 0xFD, funcionou com um MikroTik S+RJ10) e um 82599 que continuou recusando um módulo Ubiquiti 10GbE RJ45.
- Hardware: Intel X520-DA1, Intel X520-DA2, Dell Intel 2P X520/2P i350 rNDC, HPE NC560SFP+, Intel 82599ES
- Transceptores: Finisar SFP+, MikroTik S+RJ10, Ubiquiti UF-RJ45-10G
- Fator de forma: SFP+
Sintomas / mensagens:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Leia o byte 0x58, ajuste só o bit mais baixo (por exemplo, 0xFC para 0xFD) com ethtool -E e o magic formado pelo device ID e vendor ID do PCI; depois disso a placa aceita óptica ativa de terceiros em qualquer SO. DACs passivos e módulos SFP comuns costumam funcionar mesmo travados.
Placas OEM da HPE, Dell ou Cisco podem vir destravadas de fábrica, sugerindo que o travamento é uma configuração de política da Intel; se um módulo continuar falhando depois de destravado, teste ele no Linux com allow_unsupported_sfp para separar uma incompatibilidade real do travamento.