Field vendor AFBR-89BDDZ QSFP28 kebaca 0905000000000000 setelah interface SP/FPGA pindah ke FIFO
Kami yang pegang firmware management switch di hardware kami sendiri, dan sejak interface SP/FPGA diubah dari memory mapped buffer ke FIFO, inventory transceiver-nya jadi balik sebagai sampah di beberapa port.
- optik QSFP28, semuanya AFBR-89BDDZ dari batch yang sama
- pembacaan lewat jalur service processor dan FPGA ke EEPROM modulnya
- helper di sisi host itu get_i2c_status_and_read_buffer: cek status, baca seluruh buffer, cek status lagi
Yang kami dapat, bukannya data vendor:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersYang udah kami coba:
- baca ulang port yang sama berkali-kali berturut-turut, dan sampahnya stabil per port, bukan noise acak
- power cycle modulnya, nggak ada bedanya
- udah dikonfirmasi semua modul di chassis punya part number yang sama, jadi ini bukan kami salah decode blok vendor yang eksotis
Sebelum kami mulai narik optik keluar dari production, ini lebih mungkin gara-gara modulnya, jalur I2C-nya, atau read helper kami sendiri?
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
Itu nunjuk langsung ke jalur baca, dan perubahan FIFO-nya itu penyebabnya. Memory mapped buffer ngebalikin isi yang sama berapa kali pun kamu tanya; FIFO ngasih tiap byte cuma sekali terus hilang. Urutan yang diwarisin get_i2c_status_and_read_buffer, cek status, baca seluruh buffer, cek status lagi, masuk akal kalau di belakangnya ada memory dan nggak masuk akal kalau FIFO: dia ngosongin queue-nya selagi pembacaan EEPROM modulnya masih di jalur. Kamu dapat apa pun yang lagi ada di situ pada saat itu, dan byte yang datang telat ketinggalan terus muncul di pembacaan berikutnya.
Itu persis fingerprint yang kamu gambarin. Sampah yang stabil per port, korupsi yang jalan bareng urutannya, semua nol di satu mesin dan pola digit berulang di mesin lain tergantung gimana timing-nya jatuh. Nggak ada satu pun dari itu yang butuh modul rusak, dan hasil tukar-tukar kamu juga udah nyingkirin optik dari daftar tersangka.
Fix-nya itu berhenti bikin caller yang tanggung jawab atas completion check-nya. Pindahin tanggung jawab itu ke dalam read routine driver transceiver-nya sendiri: dia nunggu sampai transaksi I2C-nya lapor selesai dan baru abis itu nyentuh buffer-nya, jadi nggak ada caller yang bisa ngosongin itu lebih awal secara konstruksi. Nge-patch satu call site doang cuma bakal dorong race condition-nya ke tempat lain.
Peringatan jujur, ini bentuk fix yang diusulkan, bukan sesuatu yang udah teruji bertahun-tahun, jadi validasi dulu di platform kamu sendiri sebelum percaya lagi sama inventory-nya. Tapi ada pelajaran murah yang bisa dibawa pulang: vendor string yang berantakan itu layak dapat test module-versus-port dulu, soalnya urutan baca ternyata jadi biang keladinya jauh lebih sering daripada optiknya.
Satu pengukuran yang bisa misahin ini jadi dua: korupsinya nempel di modulnya atau di port-nya? Ambil modul dari port yang ngebalikin
0905000000000000, tukar sama modul dari port yang bacanya benar, terus baca ulang dua-duanya. Kalau string yang jelek ikut modul fisiknya, cek deh optiknya. Kalau dia tetap di nomor port-nya, atau lebih parah, ikut pindah ke modul apa pun yang dibaca berikutnya, modulnya nggak bersalah dan kamu punya masalah host read.Selagi kamu di situ, dump raw byte EEPROM-nya bareng field yang udah didecode. Sampah di vendor string yang udah didecode tapi byte di baliknya waras itu bug yang sama sekali beda dari sampah di byte-nya sendiri.
Udah dijalanin tukar-tukarnya di sepasang port. Data yang jelek nggak ikut pindah sama modulnya: port yang ngebalikin
0905000000000000tetap ngebalikin itu walaupun modul yang beda terpasang, dan modul yang kami cabut kebaca sempurna di slot barunya.Lebih dari itu, waktu kami ubah urutan port yang dibaca, korupsinya ikut pindah bareng urutannya. Sampahnya jatuh ke modul apa pun yang dibaca setelah modul yang berkelakuan buruk itu. Jadi dia ngikutin urutan baca, bukan part fisiknya. Raw byte-nya juga salah, jadi ini bukan masalah decode di sisi kami.
Root cause beda, jebakan yang sama, dari sisi driver. Di Intel E810-C dengan ice out of tree 1.15.4, saya dapat page yang salah dan nggak lengkap dari
ethtool -mdi optik QSFP28: data page 1 dan page 3, threshold dan monitor per lane, nggak cocok sama yang beneran ada di modulnya. Saya nggak pernah dapat pernyataan root cause yang proper soal itu, thread-nya ditutup sebagai solved tanpa detail yang banyak, jadi anggap ini anekdot aja, bukan kitab suci.Yang akhirnya saya lakuin itu update driver ice dan NVM E810 pakai
nvmupdate64e, cross check lawan pembacaan dari driver ice in-kernel di host lain, dan narik page tertentu pakaiplus offset dan length yang eksplisit, daripada percaya output yang udah didecode. Kalau platform kamu bisa raw dump, bandingin raw lawan decoded sebelum percaya salah satunya.
Perlu dirincikan layering-nya, soalnya itu bikin pencarian kayak gini jauh lebih pendek. Di Linux,
ethtool -mmen-decode EEPROM modulnya (nama vendor, OUI, part number, serial, date code, dan nilai DDM kalau modulnya punya),ethtool -edump raw byte-nya, dan di mana bus I2C-nya kebuka,i2cdump -y 1 0x50baca A0h sementarai2cdump -y 1 0x51baca A2h.Di A0h, nama vendor ada di byte 20-35 dan PN, rev, serta SN di 40-59. Jadi kalau field vendor-nya berantakan tapi part number-nya dua puluhan byte lebih jauh masih utuh, itu sendiri udah bilang pembacaannya timing dependent, bukan EEPROM-nya yang rusak, dan itu cocok sama yang kamu lihat.
Satu failure yang jangan sampai ketuker sama ini:
ethtool -myang ngebalikin Input/output error biasanya cuma modul tanpa DDM. Byte 92 bit 6 di A0h itu flag buat nunjukin apa A2h-nya ada sama sekali, dan test itu udah dipasang di driver in-kernel ixgbe dan bnx2x dari dulu biar mereka berhenti nyari 256 byte lagi yang nggak ada.Masalah genre yang sama di box SONiC, buat siapa pun yang datang dari sisi itu.
sfputil show eeprombilang Cannot get Module EEPROM data: Invalid argument buat modul tertentu, atau diam-diam beda hasil samashow interfaces transceiver eepromdi port yang sama.Dari yang saya alamin, ini kebanyakan celah platform dan driver, bukan optik: dua command itu pakai key name yang nggak konsisten di branch 202012 dan itu udah dibenerin di 202205, beberapa platform kehilangan modul QSFP dari sfputil setelah power cycle sampai driver fix-nya landing, dan di platform lain get_transceiver_info itu simply belum diimplementasi. Kalau saya butuh sesuatu yang bisa dipercaya buat scripting, saya pergi ke driver kernel optoe dan baca raw EEPROM SFP, QSFP, atau CMIS sendiri. Tapi cek dulu di platform kamu sendiri, perilakunya beda-beda jauh antar platform.
Update dari sisi kami. Kami pindahin completion check-nya ke dalam fungsi read driver-nya seperti yang disaranin, dan vendor string-nya udah benar di semua port di beberapa ratus kali inventory pass, termasuk dua port yang dulu saling tuker sampah. Raw byte-nya sekarang cocok sama field yang udah didecode.
Saya sebut ini partial dulu buat sementara, bukan closed: kami masih bawa ini sebagai patch yang belum landing di tree kami, dan masih ada satu platform lagi dengan FPGA build yang beda buat diverifikasi sebelum kami percaya di mana-mana. Tapi optiknya emang nggak masalah dari awal, dan itu bagian yang bakal saya salah sangka kalau sendirian.