Patcher l'EEPROM de l'Intel X520 (bit IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP) pour débloquer tous les transceivers SFP+
L'auteur du sujet a documenté que les cartes X520 à base de 82599 embarquent un bit EEPROM non documenté (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, bit de poids faible du mot de capacité à l'offset d'octet 0x58, typiquement 0xFC verrouillé / 0xFD déverrouillé) qui décide si des modules SFP+ actifs non-Intel sont acceptés sous ESXi et Windows, là où l'option du pilote Linux n'est pas disponible. Le tutoriel donne la recherche lspci -nn de l'ID du périphérique, ethtool -e enp1s0 offset 0x58 length 1 pour lire, et ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd pour écrire, avec des avertissements de ne modifier que ce bit. Des lecteurs ont rapporté des résultats sur X520-DA2, cartes eBay utilisées avec ESXi et modules Finisar, Dell-branded X520/i350 rNDC (0xFC), HPE NC560SFP+ (déjà à 0xFD, a fonctionné avec un MikroTik S+RJ10) et un 82599 qui a continué de refuser un module Ubiquiti 10GbE RJ45.
- Matériel : 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
- Format : SFP+
Symptômes / messages :
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Lire l'octet 0x58, ne modifier que le bit de poids faible (par exemple 0xFC vers 0xFD) avec ethtool -E et le magic composé de l'ID PCI du périphérique et du fabricant ; ensuite la carte accepte les optiques actives tierces sur n'importe quel OS. Les DAC passifs et les simples modules SFP fonctionnent généralement même verrouillés.
Les cartes OEM de HPE, Dell ou Cisco peuvent être livrées déverrouillées, ce qui suggère que le verrou est un réglage de politique Intel ; si un module échoue encore après le déverrouillage, testez-le sous Linux avec allow_unsupported_sfp pour distinguer une véritable incompatibilité du verrou.