Parcheando el EEPROM del Intel X520 (bit IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) para desbloquear todos los transceptores SFP+
El autor del hilo documentó que las tarjetas X520 basadas en 82599 llevan un bit de EEPROM no documentado (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, el bit más bajo de la palabra de capacidades en el desplazamiento de byte 0x58, típicamente 0xFC bloqueado / 0xFD desbloqueado) que decide si se aceptan módulos SFP+ activos que no sean de Intel en ESXi y Windows, donde la opción del driver de Linux no está disponible. El escrito da la búsqueda con lspci -nn del ID del dispositivo, ethtool -e enp1s0 offset 0x58 length 1 para leer, y ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 valuue 0xfd para escribir, con advertencias de cambiar solo ese bit. Los seguidores reportaron resultados en X520-DA2, tarjetas de eBay usadas con ESXi y módulos Finisar, Dell-branded X520/i350 rNDC (0xFC), HPE NC560SFP+ (ya en 0xFD, funcionó con un MikroTik S+RJ10) y un 82599 que aún rechazaba un 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
- Factor de forma: SFP+
Síntomas / mensajes:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Lee el byte 0x58, activa solo el bit más bajo (por ejemplo de 0xFC a 0xFD) con ethtool -E y el magic formado por el ID de dispositivo y de fabricante PCI; después la tarjeta acepta ópticas activas de terceros en cualquier sistema operativo. Los DAC pasivos y los módulos SFP normales suelen funcionar incluso bloqueados.
Las tarjetas OEM de HPE, Dell o Cisco pueden venir de fábrica desbloqueadas, lo que sugiere que el bloqueo es una política de Intel; si un módulo sigue fallando tras desbloquear, pruébalo bajo Linux con allow_unsupported_sfp para separar una incompatibilidad real del bloqueo.