Supermicro AOC-STGN-i1S (X520) on Proxmox 7.1: no interface in ip link with an HP DAC seated
I run a small Proxmox box at home and wanted a proper 10G path to the storage node, so I dropped in a used Supermicro AOC-STGN-i1S. It is the plain Intel 82599 design, board marked E157872, and I assumed this would be the boring part of the build. It is not.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, board marking E157872
- Proxmox 7.1, kernel 5.15.30-1-pve
- HP branded passive SFP+ DAC to the second box
- the card enumerates fine on the PCI bus
The driver never finishes loading. The kernel log says it aborted because it detected an SFP+/QSFP module type it does not support, and after that there is simply no port to configure:
lspci -> the X520 is listed, no complaints
ip link -> lo and the onboard 1G only, no 10G interface at all
dmesg -> ixgbe aborts loading, unsupported SFP+/QSFP module typeWhat I have done already:
- creeated /etc/modprobe.d/ixgbe.conf holding
options ixgbe allow_unsupported_sfp=1, thenupdate-initramfs -uand a reboot: no change - passed the same option as a kernel parameter instead: no change
rmmod ixgbeandmodprobe ixgbeby hand: still nothing new inip link
Is the card dead, or is there a way past this check on a 5.15 kernel that I am missing?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
What you describe is exactly what an EEPROM whitelist hit looks like on ixgbe. The driver reads the module ID, decides it is not on Intel's accepted list and aborts before it ever registers a netdev, which is why
lspcisees the card andip linkshows nothing at all. None of that is a hardware fault, and it is also why the port comes bacck the moment the module is out of the cage.The documented escape hatch is the one you already used:
On 5.15 that option is simply not reliable. I got the same non-result on this kernel, so there is no point redoing it or hunting for a typo in the conf file.
What settled it on my side: with the cage empty the interface came up on
modprobe ixgbe, putting the HP cable back made it vanish again, and that same HP cable linked without drama in a Mellanox ConnectX-2. The cable is electrically fine, Intel just does not like how it is coded.The fix that worked was fitting a plain unbranded generic SFP+ DAC instead. Link up immediately, no module options, no reboot dance. On support: with any non-Intel coded cable you are outside Intel's matrix regardless, so if this box ever has to be supportable, buy an Intel coded DAC rather than an HP one.
Before you write the card off, run one test. Pull the DAC out of the cage completely, then
rmmod ixgbe,modprobe ixgbeand look atip linkagain. If the interface appears with an empty cage, the card and the driver are both fine and the cable is what the check is choking on.Second thing worth knowing: does that HP DAC link anywhere else? A non-Intel NIC will normally take it without a word of complaint. And is it definitely the HP coded cable, or do you have a generic one lying around to compare against?
Count yourself lucky to be on an X520, where you at least have a driver knob, flaky as it is. On X710 and XL710 the module check moved into firmware, so
allow_unsupported_sfpdoes nothing whatsoever for i40e. Put a non-Intel module in an X710-DA2 and you get:and that is the end of the conversation. From there the options are Intel coded optics, the community xl710-unlocker route (push a fresh NVM image with Intel's own updater, then go poking at eleven-bit fields somewhere around 0x6800-0x7000 in the EEPROM with third party tooling, entirely at your own risk), or choosing an OEM variant in the first place: an HPE 562SFP+ is an X710 underneath, and after firmware and i40e updates it accepted thhird party 10G and 1G copper modules with no hacks at all.
On the OEM angle, it cuts the other way for Dell and Lenovo branded X710-DA2 cards: they reject non-approved SFP+ and DAC, and Intel's own tools do not even list the board. What people settled on is flashing stock Intel NVM onto them. You need the QV driver out of Intel's full BootUtil package first, otherwise the utilities will not talk to the board at all; the option ROM gets replaced before anything else, and only then do you inventory the card and flash it:
Between the inventory and the flash, trim nvmupdate.cfg down to the single X710 entry matching the card's SPI flahs size, 4 MB or 8 MB. Pick the wrong size and you have a brick that needs a saved NVM image and a hardware flasher to recover, so read the ETrackID first and be certain. Firmware in the 9.30-9.40 range was reported working afterwards, and people picked up SR-IOV on the Lenovo boards as a side effect. I would still only try it on a card I could afford to lose.
Careful about aiming the crossflash and EEPROM patching routes at this thread, because neither helps the situation as described. Editing the OEM flag in an X520 EEPROM needs a working interface to reach the card through in the first place, and here there is no interface at all until the cable comes out of the cage. That is a fix for a port that exists and rejects one module, not for a driver that aborts on load.
The other thing I would not over-read is the test in another NIC. A module linking in a different host proves the module, not the host you actually want it in. I have Ubiquiti UACC-CM-RJ45-MG copper modules that run happily in a CCR2004 and in an Intel X520-DA2 under Debian, and in the SFP+ cages of a CRS309 and a CRS328 they never link at all, with autonegotiation on or with the speed pinned by hand. Host dependence is real, so verify in the exact machine before buying a stack of anything.