R630'daki Intel X520, allow_unsupported_sfp=1'e rağmen comp_codes_10g=0x00 ile bir 10GBASE-T bakır SFP+'ı reddediyor
Bir çift R630'u 10G'ye konsolide ediyoruz, rack'in üstüne giden kablolama da bakır, o yüzden fiber çekmek yerine X520 kartlarına 10GBASE-T SFP+ modülleri taktım. Switch tarafı onları hiç itiraz etmeden alıyor. Sunucular reddediyor.
- Dell PowerEdge R630, Intel X520 (82599), çift port
- FS SFP-10GM-T-30, Dell kodlu, sunucu başına bir modül
- Intel'in out-of-tree ixgbe'si, DKMS üzerinden build edildi
- her iki port için override ayarlı /etc/modprobe.d/ixgbe.conf
# 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=0x00Şimdiye kadar denediklerim:
modprobe ixgbe allow_unsupported_sfp=1'i hem elle hem de modprobe.d girdisiyle- initramfs'i yeniden build ettim ve makineyi sadece modül reload'u değil, soğuk boot ettim
- modülü ikinci porta, sonra ikinci sunucuya taşıdım, aynı sonuç
İlginç kısım şu compliance byte'ı: modül 10G için hiçbir şey raporlamıyor. Driver override'a bakmadan önce bunu test ediyor mu, doğru kodlamaya sahip optik almak dışında yapılacak bir şey var mı?
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
Bir whitelist'le değil, kontrollerin sırasıyla savaşıyorsun.
SFF-8472'de 10GBASE-T için bir compliance biti yok. Onun için basitçe bir kod noktası yok, o yüzden dürüst bir bakır SFP+ tamamen sıfır 10G compliance kodu raporluyor, ki bu tam olarak senin
comp_codes_10g=0x00'ın. ixgbe o byte'ı okuyor, 10G modül olarak tanıdığı hiçbir şey bulamıyor veallow_unsupported_sfpoverride'ına yaklaşmadan tam orada pes ediyor. Bayrağın nitelendirilmemiş bir optik modül ya da bir DAC için sorunsuz çalışıp bakır olanlarında hiçbir işe yaramamasının sebebi bu.Intel'in out-of-tree ixgbe'sine karşı compliance testini yer değiştiren bir community patch'i var: yönetici açıkça
allow_unsupported_sfp=1ayarladığında, tamamen sıfır 10G compliance kodu raporlayan bir modül erkenden atılmak yerine SR olarak sınıflandırılıyor. Upstream'e gönderildi ve hâlâ merge edilmedi, o yüzden onu DKMS kaynağına elle uygulayıp build'inle birlikte tutuyorsun. Onu yazan kişi sonrasında bir çift sunucuda 10 Gb/s full duplex raporladı, başka biri de aynı patch'in HLX-SFPX bakır modüllerini bir X520'de çalıştırdığını doğruladı.Bunu yapmadan önce iki uyarı. Intel'in nitelendirmediği bir optik onların uyumluluk garantisinin dışında, yani bu senin sorunun olur, onların değil. Bir de 10GBASE-T PHY'si sıcak bir parça - kendi hava akışı olmayan bir server yuvasında, komşu slottaki herhangi bir optiğin epey üstünde oturur, o yüzden link ayağa kalktıktan sonra modül sıcaklığını izle.
Herhangi bir şeyi yamalamaya girmeden önce netleştirilecek iki şey var.
Önce, parametreyi kernel'ın gerçekte gördüğü haliyle yazdır:
/sys/module/ixgbe/parameters/allow_unsupported_sfp, bir modül reload'u değil bir soğuk boot'tan geçmiş bir makinede. Bu, conf dosyanda yazanı birebir geri okumuyorsa, bir şey driver'ı senin config'in devreye girmeden önce yüklüyor demektir ve debug'ın geri kalanı boşa gidiyor.İkincisi, hangi ixgbe yüklü? Driver hiç yüklemeyi bitirmezken ve arayüzler yokken
ethtool -isana bir işe yaramaz, o yüzdenmodinfo ixgbe'nin ne raporladığını ve build ettiğin DKMS paketinin sürümünü paylaş.Bir de o
comp_codes_10g=0x00nereden geliyor: driver mı söylüyor, yoksa modül EEPROM'unu kendin mi dump ettin?Dosyada parametre
1,1ve/sys/module/ixgbe/parameters/allow_unsupported_sfpsoğuk boot'tan sonra1,1olarak geri okunuyor, yani uygulanıyor, sessizce yok sayılmıyor değil. Initramfs boot'tan önce yeniden build edildi. dmesg'de her iki durumda da aynı satır.Compliance kodlarını modülden SFF-8472 verisinden kendim okudum, driver'dan değil - 10G compliance byte'ı sıfır, ID alanlarındaki her şeyin geri kalanı normal görünüyor. Aynı modül switch portunda 10G'de link veriyor, yani ölü bir modül değil.
Pratik tarafa eklemekte fayda var: DKMS'te her kernel güncellemesi diskteki kaynaklardan yeniden build ediyor, o yüzden patch'in o kaynak ağacında yaşaması gerekiyor, sonradan temizlediğin bir build dizininde değil. Portun geri gelip gelmediğini bir reboot penceresinde öğrenmek yerine ilk kernel yükseltmesinden sonra kontrol et.
Bu sınıf sorundan çıkan daha geniş ders, driver yaşının modül kodlamasından daha belirleyici olduğu. Pasif bir DAC'lı bir X710'da da aynı hikaye: tek kablo, tek port, Ubuntu 24.04 altında sorunsuz, TrueNAS SCALE altında
Link detected: noveSpeed: Unknownile ölü, çünkü o build i40e'yi 6.6.44-production kernel'inden taşıyordu. i40e'nin 6.12.9-production'dan alındığı 25.04-BETA.1'de twinax kendi kendine ayağa kalktı - başka hiçbir şeye dokunulmadı, kart hâlâ firmware 9.20'deydi. O portta optikler her iki sistemde de sorunsuzdu, hatayı eski driver'ın pasif bakırı nasıl ele aldığına sabitleyen de bu oldu. Karşılaştırmanın iki tarafında daethtool -içalıştırmak bir sürü kablo değiştirmeden kurtarırdı.Farklı bir modül tipi, aynı driver, işin içindeyken elenmeye değer bir tuzak daha. X520 daughter card'lı bir Dell R720, Cisco 10G multimode LC modülleri reddedildi, arayüzler basitçe yoktu. Seçenek modprobe.d'deydi, GRUB'da da vardı, hiçbir şey değişmedi - çünkü host EFI üzerinden boot ediyordu ve o GRUB komut satırı hiç kullanılmadı.
EFI ile boot eden bir Proxmox'ta parametre
/etc/kernel/cmdline'aixgbe.allow_unsupported_sfp=1olarak girer, ardındanpve-efiboot-tool refreshgelir. O durumda bu bile sorunu çözmedi, sonunda Intel markalı modüller satın aldılar, o yüzden bunu bir çözüm değil elenecek bir şey olarak ele al.O karmaşadan çıkan başka bir şey: her iki uç da optikten bağımsız olarak memnun kalmalı. Switch'in kabul ettiği bir modül host tarafından yine de reddedilebilir, senin şu an bulunduğun yer de tam olarak burası.
Patch'i DKMS kaynağına uyguladım ve yeniden build ettim. İki port da 10 Gb/s full duplex'te ayağa kalkıyor ve o zamandan beri yük altında ayakta kaldı.
Çalışıyor, ama çözüldü demem. Şimdi her kernel güncellemesinde taşıdığım merge edilmemiş bir patch, driver da portu SR olarak sunuyor, bu da benden sonra bu kutuya bakacak kişiyi şaşırtacak. Modül ayrıca yan yuvadaki optiklerden belirgin şekilde daha sıcak çalışıyor, o slotta da adından bahsedilecek bir hava akışı yok. Bir sonraki sunucu partisinde fiber çekip driver'la tartışmayı bırakacağım.