Intel X520 in einem R630 lehnt ein 10GBASE-T-Kupfer-SFP+ mit comp_codes_10g=0x00 trotz allow_unsupported_sfp=1 ab
Ein Paar R630 wird auf 10G konsolidiert, und die Verkabelung zum Top of Rack ist Kupfer, also wurden statt Faser zu ziehen 10GBASE-T-SFP+-Module in die X520-Karten gesteckt. Die Switch-Seite nimmt sie ohne ein Wort. Die Server verweigern.
- Dell PowerEdge R630, Intel X520 (82599), Dual-Port
- FS SFP-10GM-T-30, Dell-codiert, ein Modul pro Server
- Out-of-Tree-ixgbe von Intel, über DKMS gebaut
- /etc/modprobe.d/ixgbe.conf mit dem Override für beide Ports gesetzt
# 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=0x00Schon versucht:
modprobe ixgbe allow_unsupported_sfp=1von Hand ebenso wie der modprobe.d-Eintrag- Initramfs neu gebaut und die Maschine kalt gebootet, nicht nur ein Modul-Reload
- das Modul in den zweiten Port und dann in den zweiten Server gesteckt, gleiches Ergebnis
Der interessante Teil ist dieses Compliance-Byte: Das Modul meldet für 10G rein gar nichts. Prüft der Treiber das, bevor er überhaupt zum Override schaut, und lässt sich da etwas machen, außer Optik mit der richtigen Codierung zu kaufen?
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
Hier kämpft niemand gegen eine Whitelist, sondern gegen die Reihenfolge der Prüfungen.
SFF-8472 hat kein Compliance-Bit für 10GBASE-T. Dafür gibt es schlicht keinen Codepunkt, ein ehrliches Kupfer-SFP+ meldet also durchweg Null bei den 10G-Compliance-Codes, genau das gezeigte
comp_codes_10g=0x00. ixgbe liest dieses Byte, findet nichts, was es als 10G-Modul erkennt, und gibt genau dort auf, lange bevor derallow_unsupported_sfp-Override überhaupt in Reichweite kommt. Deshalb funktioniert das Flag bei einem nicht qualifizierten optischen Modul oder einem DAC einwandfrei und tut bei Kupfermodulen rein gar nichts.Es gibt einen Community-Patch gegen Intels Out-of-Tree-ixgbe, der die Compliance-Prüfung verschiebt: Wenn der Administrator explizit
allow_unsupported_sfp=1gesetzt hat, wird ein Modul mit durchweg Null bei den 10G-Compliance-Codes als SR eingestuft, statt vorzeitig verworfen zu werden. Er wurde upstream eingereicht und ist weiterhin nicht gemerged, also von Hand auf die DKMS-Quelle anwenden und mit dem Build synchron halten. Wer ihn geschrieben hat, berichtete danach von 10 Gb/s Vollduplex auf einem Serverpaar, und jemand anders bestätigte, dass derselbe Patch HLX-SFPX-Kupfermodule in einem X520 zum Laufen bringt.Zwei Einschränkungen vorher. Eine Optik, die Intel nicht qualifiziert hat, liegt außerhalb ihrer Kompatibilitätsgarantie, das wird also zum eigenen Problem, nicht zu ihrem. Und die 10GBASE-T-PHY ist ein heißer Teil - in einer Server-Cage ohne eigenen Airflow liegt sie deutlich über allem Optischen im Nachbarslot, also die Modultemperatur im Blick behalten, sobald der Link steht.
Zwei Dinge klären, bevor irgendwas gepatcht wird.
Erstens den Parameter so ausgeben, wie der Kernel ihn tatsächlich sieht,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, auf einer Maschine, die einen Kaltstart hinter sich hat und nicht nur einen Modul-Reload. Steht dort nicht exakt das, was in der Conf-Datei steht, lädt irgendwas den Treiber, bevor die Config greift, und der Rest des Debuggings ist verschwendet.Zweitens, welches ixgbe ist geladen?
ethtool -ibringt nichts, solange der Treiber nie fertig lädt und die Interfaces fehlen, also posten, wasmodinfo ixgbemeldet und welche Version des DKMS-Pakets gebaut wurde.Und woher kommt dieses
comp_codes_10g=0x00- sagt das der Treiber, oder wurde das EEPROM des Moduls selbst gedumpt?Der Parameter steht in der Datei auf
1,1, und/sys/module/ixgbe/parameters/allow_unsupported_sfpliest nach dem Kaltstart auch1,1zurück, wird also angewendet und nicht still ignoriert. Initramfs wurde vor dem Boot neu gebaut. In dmesg steht so oder so dieselbe Zeile.Die Compliance-Codes wurden selbst aus den SFF-8472-Daten des Moduls ausgelesen, nicht vom Treiber - das 10G-Compliance-Byte ist null, alles andere in den ID-Feldern sieht vernünftig aus. Dasselbe Modul verlinkt im Switch-Port mit 10G, es ist also kein totes Modul.
Praktisch noch wichtig: Mit DKMS baut jedes Kernel-Update aus den Quellen auf der Platte neu, der Patch muss also in diesem Source-Tree liegen, nicht in einem Build-Verzeichnis, das danach aufgeräumt wurde. Lieber nach dem ersten Kernel-Sprung prüfen, ob der Port zurückkommt, statt es während eines Reboot-Fensters herauszufinden.
Die umfassendere Lehre aus dieser Klasse von Problem: Das Treiberalter entscheidet mehr als die Modul-Codierung. Dieselbe Geschichte an einem X710 mit passivem DAC: ein Kabel, ein Port, zufrieden unter Ubuntu 24.04 und tot unter TrueNAS SCALE mit
Link detected: noundSpeed: Unknown, weil dieser Build das i40e aus dem 6.6.44-production-Kernel mitbrachte. Auf 25.04-BETA.1, wo i40e aus 6.12.9-production stammt, kam das Twinax von selbst hoch - sonst nichts angefasst, die Karte weiter auf Firmware 9.20. Optik lief an diesem Port unter beiden Systemen problemlos, und genau das hat den Fehler darauf festgenagelt, wie der ältere Treiber passives Kupfer behandelt.ethtool -iauf beiden Seiten des Vergleichs hätte eine Menge Kabeltausch gespart.Anderer Modultyp, gleicher Treiber, und eine Falle, die man dabei gleich mit ausschließen sollte. Dell R720 mit einer X520-Tochterkarte, Cisco-10G-Multimode-LC-Module abgelehnt, Interfaces schlicht nicht vorhanden. Die Option stand in modprobe.d, sie stand auch in GRUB, und nichts änderte sich - weil der Host per EFI bootet und diese GRUB-Kommandozeile nie zum Einsatz kam.
Bei einem EFI-gebooteten Proxmox gehört der Parameter nach
/etc/kernel/cmdlinealsixgbe.allow_unsupported_sfp=1, gefolgt vonpve-efiboot-tool refresh. In diesem Fall hat selbst das nichts gebracht, am Ende wurden Intel-gebrandete Module gekauft - also eher als Ausschlusskriterium behandeln, nicht als Heilmittel.Das andere aus diesem Schlamassel: Beide Enden müssen unabhängig voneinander mit der Optik zufrieden sein. Ein Modul, das der Switch akzeptiert, kann vom Host trotzdem abgelehnt werden, und genau da steht man in diesem Fall schon.
Patch auf die DKMS-Quelle angewendet und neu gebaut. Beide Ports kommen mit 10 Gb/s Vollduplex hoch und sind seitdem unter Last oben geblieben.
Funktioniert, aber gelöst würde ich es nicht nennen. Es ist ein nicht gemergter Patch, der jetzt über jedes Kernel-Update mitgeschleppt wird, und der Treiber zeigt den Port als SR an, was jeden verwirren wird, der später auf diese Box schaut. Das Modul läuft außerdem spürbar heißer als die Optik in der Cage nebenan, und dieser Slot hat keinen nennenswerten Airflow. Für den nächsten Schwung Server wird Faser gezogen, und die Diskussion mit dem Treiber ist dann vorbei.