Dell M14MK SFP28, OpenWrt'te no common interface modes hatasıyla reddediliyor, bir QSFPTEK SFP+ ise bağlanıyor
Küçük bir ev lab'ı. Stok web arayüzünden kurtulmak için bir Linksys LGS328C'yi OpenWrt SNAPSHOT'a flashladım. Eskiden kusursuz çalışan bir SFP28 portu dışında her şey geçişi sorunsuz atlattı.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- modül: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM DELL M14MK rev A1 okuyor
- aynı cage'deki referans modül: QSFPTEK QT-SFP+-SR
- her iki testte de aynı fiber ve aynı karşı uç
Dell modülü algılanıyor ve hemen dışarı atılıyor:
sfp sfp-p49: module DELL M14MK rev A1
rtl83xx-switch ...: unsupported SFP module: no common interface modes
# ethtool lan28
Advertised link modes: 10000baseCR/Full
Link detected: noZaten kontrol ettiklerim:
- aynı cage'e QSFPTEK SFP+'ı taktım: log, portun inband/10gbase-r seçtiğini gösteriyor ve tertemiz bir 10 Gbps link alıyorum;
- aynı Dell modülü bu switch'te stok firmware altında sorunsuz çalışıyordu, yani optik ölü değil;
- yeniden oturttum ve konektörü temizledim, logda değişiklik yok.
Modül gerçekten yanlış programlanmış mı, yoksa switch driver'ı 25G destekli bir parça konusunda mı titiz davranıyor? Sadece başka bir optik almak yerine bunu anlamayı tercih ederim.
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
Bu dump her şeyi açıklıyor. Kernel'in sfp katmanı, bir modülün hangi arayüz modlarını çalıştırabileceğini çıkarırken tek bir girdiye bakıyor, o da compliance byte'ları. Hiçbiri set edilmemişse boş bir küme elde ediyor, bunu MAC'in sunduğuyla kesiştiriyor, ortak hiçbir şey bulamıyor ve tam olarak gördüğünüz mesajı basıyor. ethtool'daki 10000baseCR/Full, port tarafından kalan bir değer, modülün istediği bir şey değil. Stok vendor firmware'i bunu hiç umursamıyor, çünkü o image'lar genelde compliance byte'larını tamamen atlayıp bunun yerine vendor ve part string'lerini sabit kodlanmış bir listeyle eşleştiriyor - optiğin flashlamadan önce çalışmasının sebebi de bu.
Gerçekten işe yarayan düzeltme bir modül quirk'i. drivers/net/phy/sfp.c içine, vendor DELL ile part M14MK'yı eşleştiren ve ETHTOOL_LINK_MODE_10000baseSR_Full ile PHY_INTERFACE_MODE_10GBASER'ı zorla set eden bir SFP_QUIRK_S girdisi ekleyin, sonra image'ı yeniden derleyin. Port, 10000baseSR/Full raporlayan sıradan bir 10G link olarak geliyor ve unsupported-module satırı logdan kayboluyor.
İki uyarı. Yamayı, kendi ağacınızda oturtmak yerine netdev'e gönderebileceğiniz bir şekilde tutun: EEPROM kendi kendine düzelmeyecek ve aynı Dell parçasına başka insanlar da sahip. Ve bir kernel build'i hiç sürdürmek istemiyorsanız, sıkıcı alternatif zaten elinizdeki QSFPTEK SFP+ - bu port zaten size sadece 10G verecek.
Switch driver'ını suçlamadan önce EEPROM'u dump edin ve modülün ne beyan ettiğine bakın:
ethtool --module-info lan28. Hex dump'ın ilk satırlarını, artıethtool lan28çıktısının tamamını paylaşın. "no common interface modes", kernel'in modülden kullanılabilir tek bir mod çıkaramadığı anlamına geliyor, yani buradaki bütün hikaye bu byte'ların içeriği.Doğrulanması gereken bir şey daha: QSFPTEK komşu değil aynı cage'de mi oturuyor? Log satırınız p49 diyor, ethtool çıktısı ise lan28, ve bu tür bir testte portları karıştırmak çok zaman kaybettiriyor.
Dump ettim. Kısa versiyon: 10G compliance code hiç set edilmemiş - o byte'lar basitçe boş, vendor ve part string'leri ise tam olarak bir DELL M14MK rev A1'den beklediğiniz gibi dolu.
ethtool lan28hâlâAdvertised link modes: 10000baseCR/FullveLink detected: nogösteriyor,dmesg | grep lan25da ilk mesajımdaki iki satırın ötesinde hiçbir şey çıkarmıyor.Yani modül host'a gerçekte ne yapabildiği konusunda neredeyse hiçbir şey söylemiyor, aynı cage'deki QSFPTEK ise hâlâ 10 Gbps'te link kuruyor.
Not etmeye değer, çünkü tam bu eşleşme üzerine önceki bug raporu farklı bir tahmin yürütmüştü. Oradaki teori, dual-rate modülün 25gbase-r reklamı yaptığı, rtl930x driver'ının o modu implemente etmediği, kesişimin boş çıktığı ve modülün kendisinde hiçbir sorun olmadığı yönündeydi. Hex dump o açıklamayı çürütüyor: modül hiçbir şey reklam etmiyor, 25G bile değil. Aynı kernel mesajı, farklı sebep, ve ikisini birbirinden sadece dump ayırt ediyor.
Bu ayrıca vendor markalı bir optiğin otomatik olarak doğru kodlanmış olmadığının da bir hatırlatıcısı. Dell'in kendi OS10'u, gerçek bir Q28-128GFC-SW4'ü (part KP0VM) Qualified false ile QSFP28 100GBASE-SR4 olarak gösterebiliyor, çünkü bazı partiler, medya kalifikasyonunun tanımadığı bir EEPROM kodlaması taşıyor, ve FC linki, siz elle unsupported transceiver'lara izin verene kadar down kalıyor.
DELL / M14MK için SFP_QUIRK_S girdisiyle bir image derledim ve tam olarak tarif ettiğiniz gibi çalışıyor. Port 10 Gbps'te link kuruyor,
ethtool lan28artık link up ile 10000baseSR/Full raporluyor, ve log temiz - hiçbir yerde unsupported-module satırı yok. Kutudaki başka bir şeye dokunmadan önce birkaç gün gerçek trafikle çalışır bıraktım, hiç flap yok.Kendi ağacımda tutmak kimseye faydası olmadığı için şimdi yamayı netdev'e göndermek üzere temizliyorum. Beni önce module-info dump'ına yönlendirdiğiniz için teşekkürler, iki akşamdır driver mode tablolarını okuyordum.