Dell M14MK SFP28 ditolak di OpenWrt dengan no common interface modes sementara QSFPTEK SFP+ tetap link
Home lab kecil. Saya flash Linksys LGS328C ke OpenWrt SNAPSHOT untuk kabur dari web interface stock-nya. Semuanya selamat dari perpindahan itu kecuali satu port SFP28 yang dulunya jalan sempurna.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- modul: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM terbaca DELL M14MK rev A1
- modul pembanding di cage yang sama: QSFPTEK QT-SFP+-SR
- fiber dan ujung seberang yang sama di kedua tes
Modul Dell-nya terdeteksi lalu langsung dibuang:
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: noYang sudah saya cek:
- ganti dengan SFP+ QSFPTEK di cage yang sama: log-nya menunjukkan port memilih inband/10gbase-r, dan saya dapat link 10 Gbps yang bersih;
- modul Dell yang sama jalan normal di switch ini di bawah firmware stock, jadi optiknya tidak mati;
- cabut pasang lagi dan bersihkan konektornya, tidak ada perubahan di log.
Apakah modulnya memang salah program, atau driver switch-nya yang rewel soal part yang 25G-capable? Saya lebih mau paham soal ini daripada cuma beli optik lain.
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
Dump itu menjelaskan semuanya. Layer sfp di kernel cuma punya satu input waktu dia menentukan interface mode mana yang bisa dijalankan modul, dan itu adalah compliance byte tersebut. Dengan tidak satu pun yang di-set, hasilnya jadi himpunan kosong, diintersect dengan apa yang ditawarkan MAC-nya, tidak dapat kecocokan sama sekali, dan mencetak persis pesan yang kamu lihat. 10000baseCR/Full di ethtool itu sisa dari sisi port, bukan sesuatu yang diminta modulnya. Firmware vendor stock tidak peduli soal ini, karena image-image itu umumnya melewati compliance byte sama sekali dan mencocokkan string vendor dan part terhadap daftar hardcoded sebagai gantinya - itu kenapa optiknya jalan sebelum kamu flash.
Fix yang benar-benar bertahan itu module quirk. Di drivers/net/phy/sfp.c, tambahkan entry SFP_QUIRK_S yang mencocokkan vendor DELL dengan part M14MK dan force-set ETHTOOL_LINK_MODE_10000baseSR_Full dan PHY_INTERFACE_MODE_10GBASER, lalu rebuild image-nya. Port-nya naik sebagai link 10G biasa yang melaporkan 10000baseSR/Full dan baris unsupported-module hilang dari log.
Dua catatan. Jaga patch-nya tetap dalam bentuk yang bisa kamu kirim ke netdev, jangan cuma disimpan sendiri di downstream: EEPROM-nya tidak akan membetulkan diri sendiri dan orang lain juga punya part Dell yang sama. Dan kalau kamu lebih tidak mau maintain kernel build sama sekali, alternatif yang membosankan adalah SFP+ QSFPTEK yang sudah kamu punya - 10G itu memang batas yang bisa diberikan port ini bagaimanapun juga.
Sebelum kamu menyalahkan switch driver-nya, dump EEPROM-nya dan lihat apa yang dideklarasikan modulnya:
ethtool --module-info lan28. Post baris-baris awal dari hex dump-nya plusethtool lan28lengkap. "no common interface modes" artinya kernel-nya tidak bisa menurunkan satu mode pun yang bisa dipakai dari modulnya, jadi isi byte-byte itu cerita lengkapnya di sini.Satu hal lagi yang perlu dipastikan: QSFPTEK-nya duduk di cage yang sama, bukan yang bersebelahan? Baris log kamu bilang p49 sementara output ethtool-nya lan28, dan salah pasang port di tes semacam ini membuang banyak waktu.
Sudah di-dump. Versi singkatnya: sama sekali tidak ada compliance code 10G yang di-set - byte-byte itu memang kosong, sementara string vendor dan part-nya terisi persis seperti yang diharapkan untuk DELL M14MK rev A1.
ethtool lan28masih menunjukkanAdvertised link modes: 10000baseCR/FulldanLink detected: no, dandmesg | grep lan25tidak menghasilkan apa-apa selain dua baris dari post pertama saya.Jadi modulnya hampir tidak memberi tahu apa-apa ke host soal apa yang sebenarnya bisa dia lakukan, dan QSFPTEK di cage yang sama tetap link di 10 Gbps.
Layak dicatat, karena laporan bug sebelumnya soal pasangan modul-switch yang persis sama ini menebak secara berbeda. Teorinya waktu itu modul dual-rate-nya advertise 25gbase-r, driver rtl930x-nya tidak mengimplementasikan mode itu, intersection-nya jadi kosong dan tidak ada yang salah dengan modulnya sendiri. Hex dump-nya membunuh penjelasan itu: modulnya tidak advertise apa-apa, bukan 25G. Pesan kernel yang sama, penyebab yang berbeda, dan cuma dump-nya yang bisa membedakan keduanya.
Ini juga pengingat bahwa optik bermerek vendor tidak otomatis dikode dengan benar. OS10 milik Dell sendiri akan menunjukkan Q28-128GFC-SW4 asli (part KP0VM) sebagai QSFP28 100GBASE-SR4 dengan Qualified false, karena sebagian batch membawa EEPROM coding yang tidak dikenali media qualification-nya, dan link FC-nya tetap down sampai kamu izinkan unsupported transceiver secara manual.
Sudah build image dengan entry SFP_QUIRK_S untuk DELL / M14MK dan hasilnya persis seperti yang kamu jelaskan. Port-nya link di 10 Gbps,
ethtool lan28sekarang melaporkan 10000baseSR/Full dengan link up, dan log-nya bersih - tidak ada baris unsupported-module di mana pun. Dibiarkan jalan dengan traffic asli selama beberapa hari sebelum menyentuh apa pun lagi di kotak ini, tidak ada flap.Sedang membersihkan patch-nya sekarang untuk dikirim ke netdev, karena menyimpannya sendiri di tree saya tidak membantu siapa pun. Makasih sudah mendorong saya ke module-info dump duluan, saya sudah habiskan dua malam membaca tabel mode driver-nya.