Intel X520 trong R630 từ chối SFP+ đồng 10GBASE-T với comp_codes_10g=0x00 dù đã bật allow_unsupported_sfp=1
Bọn mình đang gộp một cặp R630 lên 10G và dây đi lên đầu rack là đồng, nên thay vì kéo quang mình cắm module SFP+ 10GBASE-T vào các card X520. Đầu switch nhận chúng không một lời phàn nàn. Server thì từ chối.
- Dell PowerEdge R630, Intel X520 (82599), dual port
- FS SFP-10GM-T-30, coded theo Dell, mỗi server một module
- ixgbe out-of-tree từ Intel, build qua DKMS
- /etc/modprobe.d/ixgbe.conf với override đặt cho cả hai 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=0x00Những gì đã thử:
modprobe ixgbe allow_unsupported_sfp=1bằng tay cũng như qua modprobe.d- rebuild initramfs và cold boot cả máy, không chỉ reload module
- chuyển module sang port thứ hai rồi sang server thứ hai, kết quả như nhau
Phần thú vị là cái byte compliance đó: module báo không có gì cho 10G cả. Driver có test cái đó trước khi nó kịp nhìn tới override không, và có cách nào làm được ngoài việc mua quang có coding đúng không?
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
Bạn không đang chiến đấu với một whitelist, bạn đang chiến đấu với thứ tự các bước kiểm tra.
SFF-8472 không có bit compliance cho 10GBASE-T. Đơn giản là không có code point nào cho nó, nên một SFP+ đồng trung thực sẽ báo compliance code 10G toàn số 0, đúng y như
comp_codes_10g=0x00của bạn. ixgbe đọc byte đó, không thấy gì nó nhận ra là module 10G và bỏ cuộc ngay tại đó, trước khi nó kịp tới gần overrideallow_unsupported_sfp. Đó là lý do cờ đó chạy tốt với một module quang không đạt chuẩn hay một DAC, và chẳng làm được gì với mấy module đồng của bạn cả.Có một patch cộng đồng cho ixgbe out-of-tree của Intel, dời lại vị trí của bài test compliance: khi administrator đã tự tay đặt
allow_unsupported_sfp=1, một module báo compliance code 10G toàn số 0 sẽ được phân loại là SR thay vì bị loại sớm. Patch đó đã được gửi lên upstream và vẫn chưa được merge, nên bạn phải tự tay áp nó vào source DKMS và giữ nó theo mỗi lần build. Người viết patch đó báo cáo 10 Gb/s full duplex trên một cặp server sau đó, và một người khác xác nhận cùng patch đó làm module đồng HLX-SFPX chạy được trên một X520.Hai điều cần lưu ý trước khi làm. Một loại quang Intel chưa qualify thì nằm ngoài bảo hành tương thích của họ, nên nó trở thành vấn đề của bạn, không phải của họ. Và PHY 10GBASE-T là một linh kiện nóng - trong một khe server không có luồng gió riêng, nó sẽ nóng hơn hẳn bất cứ thứ gì quang học ở khe bên cạnh, nên theo dõi nhiệt độ module một khi link đã lên.
Hai điều cần chốt trước khi bạn đi patch bất cứ thứ gì.
Đầu tiên, in ra tham số đúng như kernel đang thấy nó,
/sys/module/ixgbe/parameters/allow_unsupported_sfp, trên một máy vừa trải qua cold boot chứ không phải chỉ reload module. Nếu cái đó không đọc lại đúng y như những gì trong file conf của bạn, thì có gì đó đang load driver trước khi config của bạn kịp có tác dụng, và phần debug còn lại coi như phí công.Thứ hai, ixgbe nào đang được load?
ethtool -ichẳng ích gì cho bạn trong khi driver chưa bao giờ load xong và interface thì vắng mặt, nên đăng ramodinfo ixgbebáo gì và phiên bản gói DKMS bạn đã build.Và cái
comp_codes_10g=0x00đó tới từ đâu - đó là driver báo cho bạn biết, hay bạn tự dump EEPROM của module ra?Parameter là
1,1trong file và/sys/module/ixgbe/parameters/allow_unsupported_sfpđọc lại ra1,1sau cold boot, nên nó đã được áp dụng, không bị lặng lẽ bỏ qua. Initramfs đã được rebuild trước khi boot. Cùng một dòng trong dmesg dù thế nào đi nữa.Compliance code thì mình tự đọc ra từ dữ liệu SFF-8472 của module, không phải từ driver - byte compliance 10G là zero, mọi thứ khác trong các trường ID trông đều bình thường. Cùng module đó cắm vào port switch thì lên link ở 10G, nên nó không phải module chết.
Đáng bổ sung về mặt thực tế: với DKMS thì mỗi lần update kernel đều rebuild lại từ source trên đĩa, nên patch phải sống trong chính cái source tree đó, không phải trong một thư mục build mà bạn đã dọn sạch sau đó. Kiểm tra xem port có trở lại sau lần bump kernel đầu tiên hay không, thay vì để phát hiện ra giữa một lần reboot.
Bài học rộng hơn từ loại vấn đề này là đời driver quyết định nhiều hơn coding của module. Chuyện tương tự trên một X710 với một DAC passive: một cáp, một port, chạy tốt dưới Ubuntu 24.04 và chết dưới TrueNAS SCALE với
Link detected: novàSpeed: Unknown, vì bản đó mang i40e từ kernel 6.6.44-production. Trên 25.04-BETA.1, nơi i40e lấy từ 6.12.9-production, twinax tự lên link - không đụng gì khác, card vẫn ở firmware 9.20. Quang trên port đó vẫn ổn dưới cả hai hệ thống, đó chính là cái ghim lỗi vào cách driver cũ xử lý đồng passive.ethtool -iở cả hai phía của phép so sánh hẳn đã tiết kiệm được rất nhiều lần đổi cáp.Loại module khác, cùng driver, và một cái bẫy đáng loại trừ trong lúc bạn đang ở đó. Dell R720 với một card con X520, module Cisco 10G multimode LC bị từ chối, interface đơn giản là biến mất. Option đó có trong modprobe.d, cũng có trong GRUB, và chẳng gì đổi cả - vì host boot qua EFI và dòng lệnh GRUB đó chưa bao giờ được dùng tới.
Trên một Proxmox boot bằng EFI, tham số đó thuộc về
/etc/kernel/cmdlinedưới dạngixgbe.allow_unsupported_sfp=1, theo sau bởipve-efiboot-tool refresh. Trong trường hợp đó thậm chí vậy cũng không fix được, và cuối cùng họ phải mua module chính hãng Intel, nên cứ coi đó là thứ cần loại trừ chứ không phải thuốc chữa.Điều khác rút ra từ mớ hỗn độn đó: cả hai đầu đều phải hài lòng với quang một cách độc lập với nhau. Một module mà switch chấp nhận vẫn có thể bị host từ chối, và đó chính xác là chỗ bạn đang đứng.
Áp patch vào source DKMS rồi rebuild. Cả hai port lên 10 Gb/s full duplex và đứng vững dưới tải từ đó tới giờ.
Chạy được, nhưng mình sẽ không gọi đó là đã giải quyết xong. Đó là một patch chưa được merge mà giờ mình phải mang theo qua mỗi lần update kernel, và driver hiển thị port đó là SR, thứ sẽ làm bối rối bất cứ ai nhìn vào máy này sau mình. Module cũng chạy nóng hơn hẳn so với quang ở khe bên cạnh, mà khe đó lại chẳng có luồng gió đáng kể nào. Với lô server tiếp theo mình sẽ kéo quang và thôi tranh cãi với driver.