Dell M14MK SFP28 bị từ chối trên OpenWrt với no common interface modes trong khi một QSFPTEK SFP+ vẫn lên link
Home lab nhỏ. Tôi flash một Linksys LGS328C sang OpenWrt SNAPSHOT để thoát khỏi web interface gốc. Mọi thứ sống sót qua cú chuyển này trừ một port SFP28 trước đây vẫn chạy hoàn hảo.
- switch: Linksys LGS328C (Realtek rtl930x), OpenWrt SNAPSHOT
- module: Dell S28-10G-25G-SR-85C, dual-rate 10G/25G, EEPROM đọc ra DELL M14MK rev A1
- module đối chiếu trong cùng cage: QSFPTEK QT-SFP+-SR
- cùng sợi quang và cùng đầu xa trong cả hai lần test
Module Dell được nhận diện rồi bị đá thẳng ra ngoài:
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: noNhững thứ tôi đã kiểm tra:
- đổi sang QSFPTEK SFP+ trong cùng cage: log cho thấy port chọn inband/10gbase-r, và tôi có một link 10 Gbps sạch sẽ;
- cùng module Dell đó chạy tốt trên switch này dưới firmware gốc, nên optic không chết;
- cắm lại và vệ sinh connector, log không đổi gì cả.
Module đó có thực sự bị lập trình sai, hay driver switch đang khó tính với một part hỗ trợ 25G? Tôi thà hiểu được cái này còn hơn chỉ đi mua optic khác.
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
Cái dump đó giải thích được toàn bộ chuyện này. Lớp sfp của kernel chỉ có đúng một đầu vào khi nó tính xem module chạy được interface mode nào, và đó là mấy compliance byte kia. Khi không cái nào được set, nó kết thúc với một tập rỗng, giao tập đó với những gì MAC cung cấp, chẳng có gì chung, rồi in ra đúng cái message bạn đang thấy. 10000baseCR/Full trong ethtool là thứ còn sót lại từ phía port, không phải thứ module yêu cầu. Firmware gốc của vendor không quan tâm, vì mấy image đó nhìn chung bỏ qua hoàn toàn các compliance byte và thay vào đó so khớp chuỗi vendor với part theo một danh sách hardcode - đó là lý do vì sao optic chạy tốt trước khi bạn flash.
Cách sửa thực sự trụ được là một module quirk. Trong drivers/net/phy/sfp.c thêm một entry SFP_QUIRK_S khớp vendor DELL với part M14MK và force-set ETHTOOL_LINK_MODE_10000baseSR_Full cùng PHY_INTERFACE_MODE_10GBASER, rồi build lại image. Port lên như một link 10G bình thường, báo 10000baseSR/Full và dòng unsupported-module biến mất khỏi log.
Hai lưu ý. Giữ cái patch ở dạng có thể gửi cho netdev thay vì ngồi ôm nó riêng: EEPROM sẽ không tự sửa nó đâu và người khác cũng đang dùng đúng part Dell đó. Và nếu bạn thà không maintain một bản kernel build nào cả, phương án nhàm chán là cái QSFPTEK SFP+ bạn đã có sẵn rồi - 10G là tất cả những gì cái port này cho bạn được thôi.
Trước khi đổ lỗi cho driver switch, dump EEPROM và xem module khai báo gì:
ethtool --module-info lan28. Đăng mấy dòng đầu của hex dump cộng đầy đủethtool lan28. "no common interface modes" nghĩa là kernel không suy ra được một mode khả dụng nào từ module, nên nội dung mấy byte đó chính là toàn bộ câu chuyện ở đây.Một thứ nữa cần xác nhận: QSFPTEK có đang nằm trong cùng cage không, chứ không phải một cage bên cạnh? Dòng log của bạn ghi p49 trong khi output ethtool lại là lan28, và nhầm lẫn port trong kiểu test này tốn khá nhiều thời gian.
Dump rồi. Bản ngắn gọn: chẳng có compliance code 10G nào được set cả - mấy byte đó đơn giản là trống, trong khi chuỗi vendor và part lại được điền đúng như bạn mong đợi cho một DELL M14MK rev A1.
ethtool lan28vẫn hiệnAdvertised link modes: 10000baseCR/FullvàLink detected: no, vàdmesg | grep lan25chẳng ra thêm gì ngoài hai dòng từ bài đầu tiên của tôi.Vậy nên module gần như chẳng nói gì cho host biết nó thực sự làm được gì, còn QSFPTEK trong cùng cage vẫn đang lên link ở 10 Gbps.
Đáng ghi lại, vì bug report trước đó về đúng cặp thiết bị này đoán khác. Giả thuyết ở đó là module dual-rate advertise 25gbase-r, driver rtl930x không implement mode đó, phần giao ra rỗng và bản thân module chẳng có gì sai. Hex dump giết chết giả thuyết đó: module này advertise không gì cả, không phải 25G. Cùng một kernel message, nguyên nhân khác nhau, và chỉ có dump mới tách được hai cái đó ra.
Đây cũng là một lời nhắc rằng một optic mang nhãn vendor không tự động được code đúng. OS10 của chính Dell sẽ hiện một Q28-128GFC-SW4 (part KP0VM) chính hãng là QSFP28 100GBASE-SR4 với Qualified false, vì một số lô hàng mang coding EEPROM mà phần media qualification của nó không nhận ra, và link FC cứ nằm ở down cho tới khi bạn tự tay allow unsupported transceiver.
Đã build một image với entry SFP_QUIRK_S cho DELL / M14MK và nó làm đúng như bạn mô tả. Port lên link ở 10 Gbps,
ethtool lan28giờ báo 10000baseSR/Full với link up, và log sạch sẽ - không có dòng unsupported-module nào cả. Để nó chạy với traffic thật vài ngày trước khi đụng vào thứ gì khác trên hộp đó, không hề flap.Giờ đang dọn lại patch để gửi cho netdev, vì giữ nó trong tree riêng của mình chẳng giúp được ai. Cảm ơn vì đã đẩy tôi đi dump module-info trước, tôi đã ngồi đọc bảng mode của driver suốt hai buổi tối.