Supermicro AOC-STGN-i1S (X520) auf Proxmox 7.1: kein Interface in ip link bei gestecktem HP-DAC

Bevor du die Karte abschreibst, mach einen Test. Zieh den DAC komplett aus dem Käfig, dann rmmod ixgbe, modprobe ixgbe und schau dir ip link erneut an. Erscheint das Interface bei leerem Käfig, sind Karte und Treiber beide in Ordnung, und das Kabel ist das, woran die Prüfung würgt.

Zweite Sache, die man wissen sollte: Linkt dieser HP-DAC irgendwo anders? Eine Nicht-Intel-NIC nimmt ihn normalerweise klaglos. Und ist es definitiv das HP-codierte Kabel, oder liegt noch ein generisches zum Vergleich herum?

Schätz dich glücklich, auf einem X520 zu sein, wo du wenigstens einen Treiber-Schalter hast, so wackelig er auch ist. Bei X710 und XL710 ist die Modulprüfung in die Firmware gewandert, allow_unsupported_sfp tut für i40e also rein gar nichts. Steck ein Nicht-Intel-Modul in ein X710-DA2, und du bekommst:

Rx/Tx is disabled on this device because an unsupported SFP module type was detected

und damit ist die Unterhaltung beendet. Von dort aus bleiben Intel-codierte Optik, der Community-Weg xl710-unlocker (ein frisches NVM-Image mit Intels eigenem Updater aufspielen, dann mit Drittanbieter-Tools an elf-Bit-Feldern irgendwo um 0x6800-0x7000 im EEPROM herumstochern, komplett auf eigenes Risiko), oder gleich eine OEM-Variante wählen: Ein HPE 562SFP+ ist darunter ein X710, und nach Firmware- und i40e-Updates akzeptierte es 10G- und 1G-Kupfermodule von Drittanbietern völlig ohne Hacks.

Beim OEM-Aspekt läuft es bei Dell- und Lenovo-markierten X710-DA2-Karten andersherum: Sie lehnen nicht freigegebene SFP+ und DAC ab, und Intels eigene Tools listen das Board nicht einmal auf. Worauf sich Leute eingependelt haben, ist das Aufspielen von Standard-Intel-NVM. Zuerst braucht man den QV-Treiber aus Intels vollständigem BootUtil-Paket, sonst reden die Tools überhaupt nicht mit dem Board; das Option-ROM wird vor allem anderen ersetzt, und erst danach inventarisiert man die Karte und flasht sie:

./bootutil64e -NIC=1 -up=combo
./nvmupdate64e -i -l
ethtool -i enp1s0f0
./nvmupdate64e -rd

Zwischen Inventarisierung und Flash die nvmupdate.cfg auf den einen X710-Eintrag zurechtstutzen, der zur SPI-Flash-Größe der Karte passt, 4 MB oder 8 MB. Wählt man die falsche Größe, hat man einen Brick, den man nur mit einem gesicherten NVM-Image und einem Hardware-Flasher zurückholt, also vorher die ETrackID lesen und sich sicher sein. Firmware im Bereich 9.30-9.40 wurde danach als funktionierend gemeldet, und die Leute haben auf den Lenovo-Boards SR-IOV als Nebeneffekt mitgenommen. Ich würde das trotzdem nur an einer Karte probieren, deren Verlust ich verschmerzen könnte.

Vorsicht, die Crossflash- und EEPROM-Patching-Wege auf diesen Thread anzuwenden, denn keiner hilft bei der beschriebenen Situation. Das OEM-Flag in einem X520-EEPROM zu ändern braucht überhaupt erst ein funktionierendes Interface, über das man die Karte erreicht, und hier gibt es kein Interface, solange das Kabel nicht aus dem Käfig ist. Das ist eine Lösung für einen Port, der existiert und ein Modul ablehnt, nicht für einen Treiber, der beim Laden abbricht.

Das andere, was ich nicht überbewerten würde, ist der Test in einer anderen NIC. Ein Modul, das in einem anderen Host linkt, beweist das Modul, nicht den Host, in dem man es eigentlich haben will. Ich habe Ubiquiti-UACC-CM-RJ45-MG-Kupfermodule, die in einer CCR2004 und in einem Intel X520-DA2 unter Debian problemlos laufen, und in den SFP+-Käfigen einer CRS309 und einer CRS328 linken sie überhaupt nie, weder mit Autonegotiation noch mit von Hand festgenagelter Geschwindigkeit. Host-Abhängigkeit ist real, also in genau der Maschine verifizieren, bevor man einen ganzen Stapel von irgendetwas kauft.