Intel X520 di R630 menolak SFP+ tembaga 10GBASE-T dengan comp_codes_10g=0x00 walau allow_unsupported_sfp=1
Kami sedang mengonsolidasikan sepasang R630 ke 10G dan pengkabelan ke atas rack pakai tembaga, jadi daripada tarik fiber saya pasang modul SFP+ 10GBASE-T ke kartu X520. Sisi switch menerimanya tanpa protes. Server-nya menolak.
- Dell PowerEdge R630, Intel X520 (82599), dual port
- FS SFP-10GM-T-30, coded Dell, satu modul per server
- ixgbe out-of-tree dari Intel, dibuild lewat DKMS
- /etc/modprobe.d/ixgbe.conf dengan override diset untuk kedua port
# cat /etc/modprobe.d/ixgbe.conf
options ixgbe allow_unsupported_sfp=1,1
# dmesg
ixgbe: failed to load because an unsupported SFP+ module type was detected
# 10G compliance codes read back from the module
comp_codes_10g=0x00Yang sudah dicoba:
modprobe ixgbe allow_unsupported_sfp=1secara manual, juga lewat entry modprobe.d- rebuild initramfs dan cold boot mesinnya, bukan cuma reload modul
- pindahkan modul ke port kedua lalu ke server kedua, hasilnya sama
Bagian yang menarik adalah byte compliance itu: modulnya sama sekali tidak melaporkan apa-apa untuk 10G. Apakah driver mengecek itu sebelum sempat melihat override-nya, dan apakah ada yang bisa dilakukan selain beli optik dengan coding yang benar?
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 6
Kamu tidak sedang melawan whitelist, kamu sedang melawan urutan pengecekannya.
SFF-8472 tidak punya bit compliance untuk 10GBASE-T. Memang tidak ada code point untuk itu, jadi SFP+ tembaga yang jujur melaporkan compliance code 10G semuanya nol, dan itu persis
comp_codes_10g=0x00punyamu. ixgbe membaca byte itu, tidak menemukan apa pun yang dikenalinya sebagai modul 10G, dan langsung menyerah di situ, sebelum sempat mendekati overrideallow_unsupported_sfp. Makanya flag itu jalan normal untuk modul optik unqualified atau DAC dan sama sekali tidak berbuat apa-apa untuk modul tembagamu.Ada patch komunitas untuk ixgbe out-of-tree Intel yang memindahkan tes compliance ini: kalau administrator sudah secara eksplisit mengeset
allow_unsupported_sfp=1, modul yang melaporkan compliance code 10G semuanya nol diklasifikasikan sebagai SR alih-alih dibuang lebih dulu. Ini sudah diajukan ke upstream dan masih belum di-merge, jadi kamu terapkan sendiri ke source DKMS dan simpan bersama build-mu. Yang menulis patch ini melaporkan 10 Gb/s full duplex di sepasang server setelahnya, dan orang lain mengonfirmasi patch yang sama bikin modul tembaga HLX-SFPX jalan di X520.Dua catatan sebelum kamu coba. Optik yang belum dikualifikasi Intel ada di luar garansi kompatibilitas mereka, jadi ini jadi masalahmu, bukan masalah mereka. Dan PHY 10GBASE-T itu komponen yang panas - di cage server tanpa airflow sendiri, suhunya akan jauh di atas apa pun yang optik di slot sebelah, jadi pantau suhu modulnya begitu link-nya up.
Dua hal yang perlu dipastikan dulu sebelum mulai nge-patch apa pun.
Pertama, cetak parameter itu persis seperti yang dilihat kernel,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, di mesin yang sudah lewat cold boot, bukan cuma reload modul. Kalau itu tidak terbaca persis sama dengan yang ada di conf file-mu, berarti ada sesuatu yang memuat driver sebelum config-mu berlaku, dan sisa debugging-nya sia-sia.Kedua, ixgbe mana yang termuat?
ethtool -itidak berguna buatmu selama driver-nya tidak pernah selesai loading dan interface-nya tidak ada, jadi post apa yang dilaporkanmodinfo ixgbedan versi paket DKMS yang kamu build.Dan dari mana asal
comp_codes_10g=0x00itu - itu driver yang bilang begitu, atau kamu dump sendiri EEPROM modulnya?Parameternya
1,1di file-nya dan/sys/module/ixgbe/parameters/allow_unsupported_sfpterbaca1,1setelah cold boot, jadi memang diterapkan, bukan diam-diam diabaikan. Initramfs sudah di-rebuild sebelum boot. Baris yang sama di dmesg, dua-duanya.Compliance code-nya saya baca sendiri dari data SFF-8472 di modulnya, bukan dari driver - byte compliance 10G-nya nol, semua field ID lainnya kelihatan wajar. Modul yang sama di port switch link normal di 10G, jadi bukan modul mati.
Perlu ditambahkan di sisi praktisnya: dengan DKMS, setiap update kernel rebuild dari source yang ada di disk, jadi patch-nya harus ada di source tree itu, bukan di build directory yang sudah kamu bersihkan belakangan. Cek port-nya balik lagi setelah kernel bump pertama, jangan sampai baru ketahuan waktu window reboot.
Pelajaran yang lebih luas dari kelas masalah ini: umur driver menentukan lebih banyak daripada coding modulnya. Cerita yang sama di X710 dengan DAC pasif: satu kabel, satu port, lancar di Ubuntu 24.04 dan mati di TrueNAS SCALE dengan
Link detected: nodanSpeed: Unknown, karena build itu membawa i40e dari kernel 6.6.44-production. Di 25.04-BETA.1, di mana i40e diambil dari 6.12.9-production, twinax-nya langsung up sendiri - tidak ada yang lain disentuh, kartunya masih di firmware 9.20. Optik baik-baik saja di port itu di kedua sistem, dan itulah yang menunjuk masalahnya ke cara driver lama menangani tembaga pasif.ethtool -idi kedua sisi perbandingan itu akan menghemat banyak acara tukar-tukar kabel.Tipe modul beda, driver sama, dan ada jebakan yang layak disingkirkan selagi kamu di situ. Dell R720 dengan daughter card X520, modul LC multimode 10G Cisco ditolak, interface-nya sama sekali hilang. Opsinya ada di modprobe.d, ada juga di GRUB, dan tidak ada yang berubah - karena host-nya boot lewat EFI dan command line GRUB itu tidak pernah dipakai.
Di Proxmox yang boot EFI, parameternya harus ada di
/etc/kernel/cmdlinesebagaiixgbe.allow_unsupported_sfp=1, diikutipve-efiboot-tool refresh. Di kasus itu bahkan itu pun tidak memperbaikinya dan mereka akhirnya beli modul bermerek Intel, jadi anggap ini sebagai sesuatu yang perlu disingkirkan, bukan obatnya.Hal lain dari kekacauan itu: kedua ujung harus sama-sama cocok dengan optiknya secara independen. Modul yang diterima switch masih bisa ditolak oleh host, dan itu persis posisimu sekarang.
Patch-nya sudah diterapkan ke source DKMS dan di-rebuild. Kedua port up di 10 Gb/s full duplex dan tetap up di bawah beban sejak itu.
Jalan, tapi saya tidak akan bilang ini sudah selesai. Ini patch yang belum di-merge yang sekarang harus saya bawa di setiap update kernel, dan driver-nya menampilkan port itu sebagai SR, yang bakal membingungkan siapa pun yang melihat box ini setelah saya. Modulnya juga jelas lebih panas dibanding optik di cage sebelah dan slot itu nyaris tidak ada airflow. Untuk batch server berikutnya saya akan tarik fiber saja dan berhenti berdebat dengan driver.