Intel X520 in een R630 weigert een 10GBASE-T koperen SFP+ met comp_codes_10g=0x00 ondanks allow_unsupported_sfp=1
We consolideren een paar R630's naar 10G en de bekabeling naar de bovenkant van het rack is koper, dus in plaats van vezel te trekken heb ik 10GBASE-T SFP+-modules in de X520-kaarten gezet. De switchkant neemt ze zonder morren aan. De servers weigeren.
- Dell PowerEdge R630, Intel X520 (82599), dual port
- FS SFP-10GM-T-30, Dell-gecodeerd, één module per server
- out-of-tree ixgbe van Intel, gebouwd via DKMS
- /etc/modprobe.d/ixgbe.conf met de override ingesteld voor beide poorten
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00Wat ik al geprobeerd heb:
modprobe ixgbe allow_unsupported_sfp=1handmatig gedraaid, en ook de modprobe.d-entry- de initramfs herbouwd en de machine koud opgestart, niet alleen een module reload
- de module naar de tweede poort verplaatst en dan naar de tweede server, zelfde resultaat
Het interessante deel is die compliance-byte: de module meldt voor 10G helemaal niets. Test de driver dat voordat hij ooit naar de override kijkt, en valt er iets aan te doen zonder optiek met de juiste codering te kopen?
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 6
Je vecht niet tegen een whitelist, je vecht tegen de volgorde van de controles.
SFF-8472 heeft geen compliance-bit voor 10GBASE-T. Er is simpelweg geen codepunt voor, dus een eerlijke koperen SFP+ meldt volledig-nul 10G-compliancecodes, precies jouw
comp_codes_10g=0x00. ixgbe leest die byte, herkent er niets in als 10G-module en geeft daar meteen op, ver voordat hij ook maar in de buurt komt van deallow_unsupported_sfp-override. Daarom werkt de flag prima voor een niet-gekwalificeerde optische module of een DAC, en doet hij voor jouw koperen exemplaren helemaal niets.Er is een community-patch tegen Intels out-of-tree ixgbe die de compliancetest verplaatst: als de beheerder expliciet
allow_unsupported_sfp=1heeft gezet, wordt een module die volledig-nul 10G-compliancecodes meldt als SR geclassificeerd in plaats van er meteen uitgegooid te worden. Hij is upstream ingediend en nog steeds niet gemerged, dus pas hem handmatig toe op de DKMS-bron en houd hem bij je build. Wie hem geschreven heeft, meldde daarna 10 Gb/s full duplex op een paar servers, en iemand anders bevestigde dat dezelfde patch HLX-SFPX-koperen modules laat werken in een X520.Twee kanttekeningen voordat je dit doet. Optiek die Intel niet gekwalificeerd heeft, valt buiten hun compatibiliteitsgarantie, dus dit wordt jouw probleem, niet het hunne. En de 10GBASE-T-PHY is een heet onderdeel - in een serverslot zonder eigen luchtstroom zal hij ruim boven alles aan optiek in het naburige slot uitkomen, dus houd de moduletemperatuur in de gaten zodra de link staat.
Twee dingen om vast te stellen voordat je ergens in gaat patchen.
Ten eerste, print de parameter zoals de kernel hem echt ziet,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, op een machine die een cold boot heeft gehad en geen module reload. Komt dat niet exact overeen met wat in je conf-bestand staat, dan laadt iets de driver voordat jouw configuratie meespeelt, en is de rest van het debuggen verspilde moeite.Ten tweede, welke ixgbe is geladen?
ethtool -iheeft geen zin zolang de driver nooit klaar is met laden en de interfaces afwezig zijn, dus post watmodinfo ixgbemeldt en de versie van het DKMS-pakket dat je gebouwd hebt.En waar komt die
comp_codes_10g=0x00vandaan - is dat de driver die het je vertelt, of heb je de module-EEPROM zelf uitgelezen?Parameter is
1,1in het bestand en/sys/module/ixgbe/parameters/allow_unsupported_sfpgeeft na een cold boot ook1,1terug, dus het wordt toegepast, niet stilletjes genegeerd. Initramfs is herbouwd voor de boot. Dezelfde regel in dmesg, beide keren.De compliancecodes heb ik zelf uit de module gelezen, uit de SFF-8472-data, niet van de driver - de 10G-compliancebyte is nul, al het andere in de ID-velden ziet er normaal uit. Dezelfde module in de switchpoort linkt op 10G, dus het is geen dode module.
Praktisch gezien nog dit: met DKMS herbouwt elke kernelupdate vanaf de bronnen op de schijf, dus de patch moet in die sourcetree staan, niet in een buildmap die je daarna hebt opgeruimd. Controleer of de poort na de eerste kernelbump terugkomt in plaats van dat pas tijdens een reboot-venster te ontdekken.
De bredere les uit dit soort problemen is dat de leeftijd van de driver meer bepaalt dan de codering van de module. Zelfde verhaal op een X710 met een passieve DAC: één kabel, één poort, prima onder Ubuntu 24.04 en dood onder TrueNAS SCALE met
Link detected: noenSpeed: Unknown, omdat die build de i40e uit de 6.6.44-production-kernel meedroeg. Op 25.04-BETA.1, waar i40e uit 6.12.9-production komt, kwam de twinax vanzelf omhoog - verder niets aangeraakt, kaart nog steeds op firmware 9.20. Optiek deed het op die poort prima onder beide systemen, wat de fout vastpinde op hoe de oudere driver passief koper afhandelt.ethtool -iaan beide kanten van de vergelijking had een hoop kabels verwisselen bespaard.Ander moduletype, zelfde driver, en een valkuil die het uitsluiten waard is nu je toch bezig bent. Dell R720 met een X520-daughtercard, Cisco 10G-multimode-LC-modules geweigerd, interfaces gewoon afwezig. De optie stond in modprobe.d, stond ook in GRUB, en er veranderde niets - omdat de host via EFI boot en die GRUB command line nooit gebruikt werd.
Op een EFI-geboote Proxmox hoort de parameter in
/etc/kernel/cmdlinealsixgbe.allow_unsupported_sfp=1, gevolgd doorpve-efiboot-tool refresh. In dat geval loste zelfs dat het niet op en zijn ze uiteindelijk Intel-merk modules gaan kopen, dus behandel het als iets om uit te sluiten, niet als een remedie.Het andere ding uit die rompslomp: beide kanten moeten onafhankelijk van elkaar tevreden zijn met de optiek. Een module die de switch accepteert, kan nog steeds door de host geweigerd worden, en daar zit jij nu al.
De patch toegepast op de DKMS-bron en herbouwd. Beide poorten komen op 10 Gb/s full duplex omhoog en zijn sindsdien onder belasting blijven staan.
Het werkt, maar ik zou het geen opgelost probleem noemen. Het is een niet-gemergede patch die ik nu bij elke kernelupdate meesleep, en de driver presenteert de poort als SR, wat iedereen die na mij naar deze doos kijkt in verwarring zal brengen. De module draait ook merkbaar heter dan de optiek in het slot ernaast, en dat slot heeft geen luchtstroom die de naam waard is. Voor de volgende lichting servers trek ik vezel en stop ik met discussiëren met de driver.