Supermicro AOC-STGN-i1S (X520) op Proxmox 7.1: geen interface in ip link met een HP-DAC erin
Ik draai thuis een kleine Proxmox-doos en wilde een fatsoenlijk 10G-pad naar de storage-node, dus heb ik een gebruikte Supermicro AOC-STGN-i1S erin gezet. Het is het gewone Intel 82599-ontwerp, bordmarkering E157872, en ik ging ervan uit dat dit het saaie deel van de build zou zijn. Dat is het niet.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, bordmarkering E157872
- Proxmox 7.1, kernel 5.15.30-1-pve
- HP-merk passieve SFP+-DAC naar de tweede doos
- de kaart wordt gewoon herkend op de PCI-bus
De driver laadt nooit volledig. Het kernellog zegt dat hij is afgebroken omdat hij een SFP+/QSFP-moduletype detecteerde dat niet ondersteund wordt, en daarna is er simpelweg geen poort om te configureren:
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 typeWat ik al gedaan heb:
- /etc/modprobe.d/ixgbe.conf aangemaakt met
options ixgbe allow_unsupported_sfp=1, daarnaupdate-initramfs -uen een reboot: geen verandering - dezelfde optie in plaats daarvan als kernelparameter meegegeven: geen verandering
rmmod ixgbeenmodprobe ixgbemet de hand: nog steeds niets nieuws inip link
Is de kaart dood, of is er op een 5.15-kernel een manier langs deze check die ik mis?
Show original (English)
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
Wat je beschrijft is precies hoe een EEPROM-whitelist-treffer eruitziet op ixgbe. De driver leest de module-ID, besluit dat die niet op Intels geaccepteerde lijst staat en breekt af nog voordat hij ooit een netdev registreert, en dat is waarom
lspcide kaart ziet enip linkhelemaal niets toont. Niets daarvan is een hardwarefout, en het is ook waarom de poort terugkomt zodra de module uit de cage is.Het gedocumenteerde achterdeurtje is degene die je al gebruikt hebt:
Op 5.15 is die optie gewoon niet betrouwbaar. Ik kreeg hetzelfde nulresultaat op deze kernel, dus het heeft geen zin het over te doen of naar een typefout in het conf-bestand te zoeken.
Wat het bij mij besliste: met een lege cage kwam de interface op bij
modprobe ixgbe, de HP-kabel terugzetten liet hem weer verdwijnen, en diezelfde HP-kabel linkte zonder drama in een Mellanox ConnectX-2. De kabel is elektrisch prima, Intel vindt alleen niet leuk hoe hij gecodeerd is.De fix die werkte was in plaats daarvan een gewone ongebrande generieke SFP+-DAC plaatsen. Link meteen op, geen moduleopties, geen reboot-dansje. Wat support betreft: met een niet-Intel-gecodeerde kabel val je hoe dan ook buiten Intels matrix, dus als deze doos ooit supportable moet zijn, koop dan een Intel-gecodeerde DAC in plaats van een HP-exemplaar.
Voordat je de kaart afschrijft, doe eerst één test. Trek de DAC helemaal uit de cage, doe dan
rmmod ixgbe,modprobe ixgbeen kijk opnieuw naarip link. Verschijnt de interface met een lege cage, dan zijn de kaart en de driver allebei prima en is de kabel waar de check op stikt.Tweede ding dat de moeite waard is om te weten: linkt die HP-DAC ergens anders wel? Een niet-Intel-NIC neemt hem normaal zonder een woord van klacht aan. En is het zeker de HP-gecodeerde kabel, of heb je een generieke liggen om ter vergelijking te proberen?
Prijs jezelf gelukkig dat je op een X520 zit, waar je in elk geval een driverknop hebt, hoe wankel ook. Op X710 en XL710 is de modulecontrole naar de firmware verhuisd, dus
allow_unsupported_sfpdoet voor i40e helemaal niets. Zet een niet-Intel-module in een X710-DA2 en je krijgt:en daarmee is het gesprek voorbij. Vanaf daar zijn de opties: Intel-gecodeerde optiek, de community-route xl710-unlocker (met Intels eigen updater een verse NVM-image pushen, en daarna met tooling van derden gaan zitten peuteren aan elfbits-velden ergens rond 0x6800-0x7000 in de EEPROM, volledig op eigen risico), of meteen voor een OEM-variant kiezen: een HPE 562SFP+ is onder de motorkap een X710, en na firmware- en i40e-updates accepteerde die zonder enige hack 10G- en 1G-kopermodules van derden.
Wat de OEM-hoek betreft werkt het andersom voor Dell- en Lenovo-gebrande X710-DA2-kaarten: die weigeren niet-goedgekeurde SFP+ en DAC, en Intels eigen tools vermelden het board niet eens. Waar mensen op uitkwamen is er standaard Intel-NVM op flashen. Je hebt eerst de QV-driver uit Intels volledige BootUtil-pakket nodig, anders praten de utilities helemaal niet met het board; de option-ROM wordt als eerste vervangen, en pas dan inventariseer en flash je de kaart:
Trim tussen de inventarisatie en het flashen nvmupdate.cfg terug tot het ene X710-item dat bij de SPI-flashgrootte van de kaart past, 4 MB of 8 MB. Kies je de verkeerde grootte, dan heb je een baksteen die voor herstel een opgeslagen NVM-image en een hardwareflasher nodig heeft, dus lees eerst de ETrackID en wees zeker. Firmware in de reeks 9.30-9.40 werd achteraf gemeld als werkend, en mensen kregen SR-IOV op de Lenovo-boards als bijvangst. Ik zou het nog steeds alleen proberen op een kaart die ik me kan veroorloven kwijt te raken.
Wees voorzichtig met de crossflash- en EEPROM-patchroutes op dit topic richten, want geen van beide helpt bij de situatie zoals beschreven. Het OEM-vlagje in een X520-EEPROM bewerken vereist om te beginnen een werkende interface om de kaart via te bereiken, en hier is helemaal geen interface totdat de kabel uit de cage komt. Dat is een fix voor een poort die bestaat en één module weigert, niet voor een driver die bij het laden afbreekt.
Het andere waar ik niet te veel in zou lezen is de test in een andere NIC. Een module die in een andere host linkt bewijst de module, niet de host waar je hem daadwerkelijk in wilt. Ik heb Ubiquiti UACC-CM-RJ45-MG-kopermodules die vrolijk draaien in een CCR2004 en in een Intel X520-DA2 onder Debian, en in de SFP+-cages van een CRS309 en een CRS328 linken ze helemaal nooit, met autonegotiation aan of met de snelheid met de hand vastgezet. Hostafhankelijkheid is echt, dus verifieer in de exacte machine voordat je een stapel van wat dan ook koopt.