Proxmox 7.1'de Supermicro AOC-STGN-i1S (X520): bir HP DAC takılıyken ip link'te arayüz yok
Evde küçük bir Proxmox kutusu çalıştırıyorum ve storage node'a düzgün bir 10G yol istedim, o yüzden kullanılmış bir Supermicro AOC-STGN-i1S taktım. Sıradan bir Intel 82599 tasarımı, kart üzerinde E157872 yazıyor, kurulumun sıkıcı kısmı bu olur sanmıştım. Öyle değilmiş.
- Supermicro AOC-STGN-i1S, Intel X520-DA1, kart işareti E157872
- Proxmox 7.1, kernel 5.15.30-1-pve
- ikinci kutuya HP markalı pasif SFP+ DAC
- kart PCI bus'ta sorunsuz enumerate oluyor
Sürücü yüklemeyi hiç bitirmiyor. Kernel log'u desteklemediği bir SFP+/QSFP modül tipi tespit ettiği için iptal ettiğini söylüyor, ondan sonra yapılandıracak bir port da kalmıyor:
lspci -> the X520 is listed, no complaints
ip link -> lo and the onboard 1G only, no 10G interface at all
dmesg -> ixgbe aborts loading, unsupported SFP+/QSFP module typeŞimdiye kadar yaptıklarım:
options ixgbe allow_unsupported_sfp=1içeren /etc/modprobe.d/ixgbe.conf oluşturdum, sonraupdate-initramfs -uve reboot: değişiklik yok- aynı seçeneği bunun yerine bir kernel parametresi olarak geçtim: değişiklik yok
- elle
rmmod ixgbevemodprobe ixgbe:ip link'te yine yeni bir şey yok
Kart ölü mü, yoksa 5.15 kernelinde bu kontrolü aşmanın gözden kaçırdığım bir yolu mu var?
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
Anlattığınız şey ixgbe'de tam olarak bir EEPROM whitelist çarpmasının göründüğü gibi. Sürücü modül ID'sini okuyor, Intel'in kabul edilen listesinde olmadığına karar veriyor ve bir netdev kaydetmeden önce iptal ediyor,
lspci'ın kartı görüpip link'in hiçbir şey göstermemesinin sebebi de bu. Bunların hiçbiri donanım arızası değil, modül kafesten çıkar çıkmaz portun geri gelmesinin sebebi de bu.Belgelenmiş kaçış yolu zaten kullandığınız yol:
5.15'te bu seçenek basitçe güvenilir değil. Bu kernelde ben de aynı sonuçsuzluğu aldım, yani onu tekrarlamanın ya da conf dosyasında bir yazım hatası aramanın bir anlamı yok.
Bende işi çözen şuydu: kafes boşken arayüz
modprobe ixgbeile geldi, HP kabloyu geri takınca yine kayboldu, aynı HP kablo da bir Mellanox ConnectX-2'de sorunsuzca linkledi. Kablo elektriksel olarak sağlam, Intel sadece nasıl kodlandığını beğenmiyor.İşe yarayan çözüm, onun yerine sade, markasız, generic bir SFP+ DAC takmak oldu. Link anında up oldu, modül seçeneği yok, reboot dansı yok. Destek konusunda: Intel kodlu olmayan herhangi bir kabloyla zaten Intel'in matrisinin dışındasınız, yani bu kutunun bir gün destekli olması gerekiyorsa, HP yerine Intel kodlu bir DAC alın.
Kartı hatalı ilan etmeden önce bir test yapın. DAC'ı kafesten tamamen çıkarın, sonra
rmmod ixgbe,modprobe ixgbeyapıpip link'e tekrar bakın. Arayüz boş kafesle görünüyorsa kart da sürücü de sorunsuz demektir, kontrolün takıldığı şey kablodur.Bilinmesi gereken ikinci şey: o HP DAC başka bir yerde linkliyor mu? Intel olmayan bir NIC bunu genelde tek bir şikayet etmeden kabul eder. Ve kesinlikle HP kodlu kablo mu, yoksa karşılaştırmak için elinizde generic bir tane var mı?
X520'de olduğunuz için kendinizi şanslı sayın, ne kadar güvenilmez olsa da en azından bir sürücü düğmeniz var. X710 ve XL710'da modül kontrolü firmware'e taşındı, yani i40e için
allow_unsupported_sfphiçbir işe yaramıyor. Bir X710-DA2'ye Intel olmayan bir modül takın, şunu alırsınız:ve konuşma orada biter. Oradan sonraki seçenekler Intel kodlu optikler, topluluğun xl710-unlocker yolu (Intel'in kendi updater'ıyla yeni bir NVM imajı basıp sonra üçüncü parti araçlarla EEPROM'da 0x6800-0x7000 civarındaki on bir bitlik alanları eşelemek, tamamen kendi riskinizle) ya da baştan bir OEM varyantı seçmek: bir HPE 562SFP+ altında bir X710'dur, firmware ve i40e güncellemelerinden sonra hiçbir hack olmadan üçüncü parti 10G ve 1G bakır modülleri kabul etti.
OEM açısından bakınca, Dell ve Lenovo markalı X710-DA2 kartlarında iş tersine dönüyor: onaylanmamış SFP+ ve DAC'ı reddediyorlar, Intel'in kendi araçları da kartı listede bile göstermiyor. İnsanların yerleştiği çözüm, üzerlerine stok Intel NVM'i flaşlamak. Önce Intel'in tam BootUtil paketinden QV sürücüsüne ihtiyacınız var, yoksa araçlar kartla hiç konuşmuyor; her şeyden önce option ROM değiştiriliyor, ancak ondan sonra kartı envanterleyip flaşlıyorsunuz:
Envanter ile flaşlama arasında, nvmupdate.cfg'yi kartın SPI flash boyutuna (4 MB ya da 8 MB) uyan tek X710 girdisine indirin. Yanlış boyutu seçerseniz kurtarmak için kayıtlı bir NVM imajı ve donanımsal bir flasher gereken bir tuğlanız olur, o yüzden önce ETrackID'yi okuyup emin olun. 9.30-9.40 aralığındaki firmware'lerin sonrasında çalıştığı bildirildi, insanlar Lenovo kartlarında yan etki olarak SR-IOV da kazandı. Ben yine de bunu sadece kaybetmeyi göze alabileceğim bir kartta denerim.
Crossflash ve EEPROM yamalama yollarını bu konuya yöneltirken dikkatli olun, çünkü hiçbiri tarif edilen durumda işe yaramaz. Bir X520 EEPROM'unda OEM bayrağını düzenlemek öncelikle karta ulaşmak için çalışan bir arayüz gerektirir, burada ise kablo kafesten çıkana kadar hiç arayüz yok. Bu, var olan ve tek bir modülü reddeden bir port için bir çözüm, yüklenirken iptal eden bir sürücü için değil.
Fazla okumamam gereken diğer şey de başka bir NIC'teki test. Farklı bir host'ta linkleyen bir modül, modülü kanıtlar, gerçekten içinde istediğiniz host'u değil. Bende bir CCR2004'te ve Debian altında bir Intel X520-DA2'de sorunsuzca çalışan Ubiquiti UACC-CM-RJ45-MG bakır modülleri var, bir CRS309 ile bir CRS328'in SFP+ kafeslerinde ise, autonegotiation açık ya da hız elle sabitlenmiş, hiç linklemiyorlar. Host bağımlılığı gerçek, o yüzden herhangi bir şeyden yığınla almadan önce tam olarak o makinede doğrulayın.