SP/FPGA arayüzü bir FIFO'ya taşındıktan sonra AFBR-89BDDZ QSFP28 vendor alanı 0905000000000000 okuyor
Kendi donanımımızdaki switch yönetim firmware'ine bakıyoruz, ve SP/FPGA arayüzü memory mapped buffer'lardan bir FIFO'ya değiştirildiğinden beri, transceiver envanteri bazı portlarda çöp olarak geri geliyor.
- QSFP28 optikler, hepsi aynı partiden AFBR-89BDDZ
- okumalar service processor ve FPGA yolu üzerinden modül EEPROM'una gidiyor
- host tarafındaki yardımcı fonksiyon get_i2c_status_and_read_buffer: durumu kontrol et, tüm buffer'ı oku, durumu tekrar kontrol et
Vendor verisi yerine aldığımız:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersŞimdiye kadar denediklerimiz:
- aynı portu art arda birkaç kez yeniden okuduk, ve çöp rastgele gürültü yerine port başına kararlı
- modülleri güç döngüsünden geçirdik, fark yok
- şasideki her modülün aynı parça numarası olduğunu doğruladık, yani bu bizim egzotik bir vendor bloğunu yanlış decode etmemiz değil
Optikleri production'dan çekmeye başlamadan önce, bunun modüller mi, I2C yolu mu, yoksa kendi okuma yardımcımız mı olma ihtimali daha yüksek?
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 7
Bu doğrudan okuma yoluna işaret ediyor, ve FIFO değişikliği de nedeni. Memory mapped bir buffer, ne kadar sık sorarsanız sorun aynı içeriği döndürür; bir FIFO ise her byte'ı tam olarak bir kez verir ve sonra gider. get_i2c_status_and_read_buffer'ın devraldığı sıra, durum kontrolü, tam buffer okuması, tekrar durum kontrolü, arkasında memory varken mantıklıydı ve bir FIFO ile değil: modülün EEPROM okuması hâlâ hat üzerindeyken kuyruğu boşaltıyor. O anda orada oturan her ne ise onu alırsınız, ve geç varan byte'lar geride kalıp bir sonraki okumada ortaya çıkar.
Bu tam olarak tarif ettiğiniz parmak izi. Port başına kararlı çöp, sıra ile birlikte yürüyen bozulma, zamanlamanın nasıl düştüğüne bağlı olarak bir makinede hepsi sıfır ve başka birinde tekrarlayan rakam desenleri. Bunların hiçbiri kötü bir modül gerektirmiyor, ve zaten değişim sonucunuz optikleri eliyor.
Çözüm, tamamlama kontrolünden çağıranı sorumlu tutmayı bırakmak. Bu sorumluluğu transceiver sürücüsünün okuma rutininin içine taşıyın: I2C işlemi tamamlandı raporlayana kadar bekler ve ancak o zaman buffer'a dokunur, yani hiçbir çağıran yapı gereği onu erken boşaltamaz. Tek bir çağrı noktasını yamamak, yarışı sadece başka bir yere iter.
Dürüst uyarı: bu, arkasında yıllar olan bir şey değil, çözümün önerilen şekli, yani envantere tekrar güvenmeden önce kendi platformunuzda doğrulayın. Yine de çıkarılacak ucuz ders şu: bozuk vendor string'leri önce bir modül-porta karşı test hak ediyor, çünkü okuma sırası optiklerden çok daha sık suçlu çıkıyor.
Bunu ikiye bölen tek ölçüm: bozulma modülle mi yoksa portla mı kalıyor?
0905000000000000döndüren porttan modülü çıkarın, doğru okuyan bir porttaki bir modülle değiştirin, ve ikisini yeniden okuyun. Kötü string fiziksel modülü takip ediyorsa, gidip optiklere bakın. Port numarasında kalıyorsa, ya da daha kötüsü, sırada okunacak her hangi modüle geçiyorsa, modüller masum ve sizde bir host okuma sorunu var.Oradayken, decode edilmiş alanların yanında ham EEPROM byte'larını da dump edin. Altında sağlam byte'lar olan decode edilmiş bir vendor string'indeki çöp, byte'ların kendisindeki çöpten tamamen farklı bir bug.
Bu değişimi bir port çiftinde çalıştırdık. Kötü veri modülle birlikte hareket etmedi:
0905000000000000döndüren port, farklı bir modül oturtulmuşken de onu döndürmeye devam etti, ve çıkardığımız modül yeni yuvasında kusursuz okundu.Bundan daha iyisi, portların okunma sırasını değiştirdiğimizde, bozulma da sırayla birlikte hareket etti. Çöp, kötü davranan modülden sonra okunan her hangi modüle iniyor. Yani fiziksel parçayı değil okuma sırasını takip ediyor. Ham byte'lar da yanlış, yani bizim tarafımızda bir decode sorunu değil.
Farklı kök neden, aynı tuzak, sürücü tarafından. Out of tree ice 1.15.4'lü bir Intel E810-C'de QSFP28 optiklerde
ethtool -m'den yanlış ve eksik sayfalar aldım: sayfa 1 ve sayfa 3 verisi, threshold'lar ve lane başına monitörler, modülün gerçekte tuttuğuyla eşleşmiyordu. Bundan hiçbir zaman düzgün bir kök neden ifadesi alamadım, konu fazla detay olmadan çözüldü diye kapatıldı, yani bunu kesin bilgi değil anekdot olarak ele alın.Sonunda yaptığım şey, ice sürücüsünü ve E810 NVM'ini
nvmupdate64eile güncellemek, başka bir host'taki kernel içi ice sürücüsünden bir okumaya karşı çapraz kontrol etmek, ve decode edilmiş çıktıya güvenmek yerineartı açık offset ve length ile belirli sayfaları çekmekti. Platformunuz ham bir dump yapabiliyorsa, ikisine de inanmadan önce ham olanı decode edilmişle karşılaştırın.
Katmanlanmayı açıklamaya değer, çünkü bu tür bir avı çok kısaltıyor. Linux'ta
ethtool -mmodül EEPROM'unu decode eder (vendor adı, OUI, parça numarası, seri, tarih kodu, ve modülde varsa DDM değerleri),ethtool -eham byte'ları dump eder, ve I2C bus'ının açıkta olduğu yerdei2cdump -y 1 0x50A0h'ı okurkeni2cdump -y 1 0x51A2h'ı okur.A0h'de vendor adı byte 20-35'te, PN, rev ve SN ise 40-59'da yaşıyor. Yani vendor alanı bozuksa ve birkaç düzine byte ileride duran parça numarası sağlamsa, bu tek başına EEPROM'un kötü olması yerine okumanın zamanlamaya bağlı olduğunu söyler, ki gördüğünüzle örtüşüyor.
Bununla karıştırılmaması gereken bir arıza:
ethtool -m'in Input/output error döndürmesi genelde sadece DDM'i olmayan bir modüldür. A0h'nin 92. byte'ının 6. biti, A2h'nin orada olup olmadığının bayrağı, ve bu test uzun zaman önce kernel içi ixgbe ve bnx2x sürücülerine konmuştu ki var olmayan başka 256 byte'a uzanmayı bıraksınlar.O taraftan gelen herkes için, SONiC kutularında aynı türden bir sorun.
sfputil show eeprom, belirli modüller için Cannot get Module EEPROM data: Invalid argument diyor, ya da aynı porttashow interfaces transceiver eepromile sessizce çelişiyor.Benim başıma gelenlerden anladığım kadarıyla bu çoğunlukla optik değil platform ve sürücü boşlukları: iki komut 202012 branch'inde tutarsız key adları kullandı ve bu 202205'te düzeltildi, bazı platformlar bir sürücü düzeltmesi gelene kadar güç döngüsünden sonra sfputil'den QSFP modüllerini kaybediyor, ve diğerlerinde get_transceiver_info basitçe implemente edilmemiş. Scripting için güvenebileceğim bir şeye ihtiyacım olduğunda optoe kernel sürücüsüne gidip SFP, QSFP veya CMIS EEPROM'unun ham okumalarını kendim yapıyorum. Yine de kendi platformunuzda kontrol edin, davranış aralarında epey değişiyor.
Bizim tarafımızdan güncelleme. Önerildiği gibi tamamlama kontrolünü sürücü okuma fonksiyonunun içine taşıdık, ve vendor string'leri, aralarında çöp alışverişi yapan iki port dahil, birkaç yüz envanter geçişi boyunca her portta doğru oldu. Ham byte'lar artık decode edilmiş alanlarla eşleşiyor.
Şimdilik bunu kapalı değil kısmi olarak adlandırıyorum: bunu ağacımıza henüz inmemiş bir patch olarak taşıyoruz, ve her yerde güvenmeden önce doğrulanacak farklı bir FPGA build'li bir platform daha var. Ama optikler baştan beri sağlamdı, kendi başıma yanlış anlayacağım kısım da buydu.