De Intel X520-EEPROM patchen (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP-bit) om alle SFP+-transceivers te ontgrendelen
De topicstarter documenteerde dat op 82599 gebaseerde X520-kaarten een ongedocumenteerd EEPROM-bit dragen (IXGBE_DEVICE_CAPS_ALLOW_ANY_SFP, laagste bit van het capability-woord op byte-offset 0x58, doorgaans 0xFC vergrendeld / 0xFD ontgrendeld) dat bepaalt of niet-Intel actieve SFP+-modules geaccepteerd worden op ESXi en Windows, waar de Linux-driveroptie niet beschikbaar is. Het schrijfstuk geeft de lspci -nn-opzoeking van de device-ID, ethtool -e enp1s0 offset 0x58 length 1 om te lezen, en ethtool -E enp1s0 magic 0x10fb8086 offset 0x58 value 0xfd om te schrijven, met waarschuwingen om alleen dat bit om te zetten. Volgers rapporteerden resultaten op X520-DA2, eBay-kaarten gebruikt met ESXi en Finisar-modules, Dell-gebrande X520/i350 rNDC (0xFC), HPE NC560SFP+ (al 0xFD, werkte met een MikroTik S+RJ10) en een 82599 die een Ubiquiti 10GbE RJ45-module nog steeds weigerde.
- 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
- Vormfactor: SFP+
Symptomen / meldingen:
non-Intel active SFP+ rejected on ESXi/Windows
EEPROM byte 0x58 = 0xFC
Comments 2
Lees byte 0x58, zet alleen het laagste bit (bijvoorbeeld 0xFC naar 0xFD) met ethtool -E en de magic opgebouwd uit PCI device- en vendor-ID; daarna accepteert de kaart actieve optiek van derden op elk OS. Passieve DAC's en gewone SFP-modules werken meestal ook als de kaart vergrendeld is.
OEM-kaarten van HPE, Dell of Cisco worden mogelijk al ontgrendeld uitgeleverd, wat suggereert dat de vergrendeling een beleidsinstelling van Intel is; faalt een module ook na het ontgrendelen, test hem dan onder Linux met allow_unsupported_sfp om een echte incompatibiliteit van de vergrendeling te onderscheiden.