SONiC decode QSFP-DD CMIS 4.0 jadi field vendor yang berantakan, padahal modul SFF ke-parse normal

Kamu di branch yang mana? Ada known inconsistency nama key antara show interfaces transceiver eeprom dan sfputil di 202012 yang udah dibereskan di 202205, dan itu layak disingkirkan dulu sebelum gali lebih dalam.

Post output dari sudo sfputil show eeprom -d buat port yang sama. Kalau sfputil ngasih string berantakan yang sama, faultnya ada di decode path yang shared. Kalau malah error, kamu di wilayah yang beda - kami punya platform yang cuma jawab Cannot get Module EEPROM data: Invalid argument dan tidak pernah sampai ke tahap decode apa pun.

Sudah jalanin dua-duanya: sudo sfputil show eeprom -d dan show interfaces transceiver eeprom -d di port yang sama. Berantakannya identik, field-nya sama, sampah yang sama di tempat serial harusnya ada. Tidak ada Invalid argument di mana pun, pembacaannya sendiri jalan tanpa komplain.

Jadi kedua command itu sepakat satu sama lain, cuma sepakatnya di jawaban yang salah. Port QSFP28 di sebelahnya tetap bersih lewat keduanya, yang bikin ini kelihatan spesifik ke part CMIS ini, bukan ke platform-nya.

Pola itu tanda tangan dari parser yang diterapkan ke memory map yang tidak dia mengerti: part number nongkrong di field vendor name, serial tidak terbaca, connector dan encoding geser. Modul rusak atau I2C read yang rusak ngasih kamu error atau blok nol semua, bukan string yang salah tapi rapi begini.

Decode path-nya ada di sonic_platform_base/sonic_sfp/sfputilbase.py, dan di situ tiga string identity-nya diambil dari offset yang di-hardcode terhadap SFF map lama, apa pun yang sebenarnya kepasang. QSFP-DD CMIS 4.0 tidak nyimpen identity block-nya di alamat-alamat itu - spec CMIS 4.0 jelasin itu di section 8.3 - jadi kode-nya beneran baca byte asli dari modul yang benar, cuma bukan byte yang dia kira lagi dia baca, dan dia nge-print apa pun yang nempatin range itu. Itu juga kenapa tidak pernah ada yang gagal dengan bersih: tidak ada step yang lihat byte identifier dan pindah ke layout CMIS.

Kesimpulan praktisnya, tidak ada yang bakal bereskan ini selain parser yang ngerti memory map CMIS, dan sampai itu masuk ke branch kamu, output CLI buat part ini bukan level inventory. Buat asset database, baca page-nya mentah-mentah dan decode sendiri, jangan cuma scraping CLI-nya.

Buat raw read, driver optoe itu yang kamu mau: dia expose EEPROM SFP, QSFP, dan CMIS buat direct read and write, jadi kamu bisa ambil byte-nya dan decode sendiri di script kamu. Itu satu-satunya yang bakal saya kasih makan ke asset database buat part CMIS saat ini.

Satu peringatan kalau kamu nyari-nyari offset. Tabel yang semua orang kutip itu tabel SFF - A0h byte 20-35 buat vendor name, 40-59 buat PN, rev, dan SN. Itu persis offset yang ngehasilin sampah kamu di modul CMIS, jadi jangan dipakai ulang di situ. Kehati-hatian yang sama di host Linux sebagai bench tool: ethtool -m buat decoded view dan ethtool -e buat raw byte itu oke buat part SFP, tapi cek dulu apa yang beneran dimengerti build kamu sebelum percaya field yang di-print buat CMIS.

Penanganan CMIS-nya tipis di lebih banyak tempat daripada cuma EEPROM decoder. Kami masukin satu tray optik InnoLight 800G QSFP-DD ke layanan, T-DP8CNH-NNO dan T-DP8CNT-NNO, dan kira-kira tiap insersi kedua bikin kami dapat port yang mati: datapath melaporkan DataPathDeactivated, log-nya bawa timeout buat 'ConfigSuccess', dan dari situ port-nya down permanen - tidak ada retry, tidak ada apa pun yang balikin dia sendiri.

Biang keroknya ternyata decommission_all_datapaths() di cmis.py. Dia jalanin seluruh urutan beruntun - DEINIT, application ID di-clear ke 0, terus INIT - dan tidak pernah cek apa satu step beneran kejadian sebelum mulai step berikutnya. Part kami butuh persis konfirmasi itu, jadi datapath-nya ketinggalan setengah ke-configure dan state machine-nya cuma nunggu timer-nya habis. Fix yang beneran harus nunggu secara asynchronous, soalnya kamu tidak bisa block di dalam state machine CMIS inline punya xcvrd, dan terakhir saya cek belum ada yang landing-in itu. Bug beda, tema sama: jalur CMIS yang ditempel ke kode yang ditulis buat part SFF.

Satu koreksi buat arah diskusi ini, soalnya dua failure mode ini terus-terusan ketuker. Cannot get Module EEPROM data: Invalid argument, atau QSFP yang ilang dari sfputil setelah power cycle sampai driver-nya dibetulin, atau platform yang emang tidak implement get_transceiver_info sama sekali - itu semua celah platform dan driver, dan itu nyetop kamu sebelum decoding apa pun kejadian.

Yang dijelasin di sini kebalikannya: pembacaan yang lengkap dan sukses, terus diinterpretasi pakai field layout yang salah. Jangan tukar modul atau kejar-kejar versi driver buat ini. Byte di dalam modul itu baik-baik saja, dan tool apa pun yang decode itu sebagai CMIS bakal nunjukin serial yang ada di label.