SONiC يُفكّك وحدة QSFP-DD من نوع CMIS 4.0 إلى حقول مورّد مشوّشة بينما تُفسَّر وحدات SFF بشكل سليم

على أي فرع أنت؟ هناك تناقضات معروفة في أسماء المفاتيح بين show interfaces transceiver eeprom وsfputil في 202012 تم حلها في 202205، ويستحق استبعاد ذلك قبل الحفر أعمق.

انشر ناتج sudo sfputil show eeprom -d لنفس المنفذ. إذا أعطتك sfputil نفس السلاسل المشوّشة، فالعطل في مسار التفكيك المشترك. إذا أعطت خطأ بدلاً من ذلك، فأنت في منطقة مختلفة - لدينا منصات تجيب فقط Cannot get Module EEPROM data: Invalid argument ولا تصل أبدًا إلى مرحلة تفكيك أي شيء.

شغّلت كلا الأمرين: sudo sfputil show eeprom -d وshow interfaces transceiver eeprom -d على نفس المنفذ. نفس التشويه بالضبط، نفس الحقول، نفس البيانات العشوائية في مكان الرقم التسلسلي. لا يظهر Invalid argument في أي مكان، وعملية القراءة نفسها تمر دون أي اعتراض.

إذن الأمران متفقان مع بعضهما، لكنهما متفقان على إجابة خاطئة. منافذ QSFP28 المجاورة تبقى نظيفة في كلا الأمرين، ما يجعل الأمر يبدو خاصًا بهذا الجزء CMIS وليس بالمنصّة.

هذا النمط هو توقيع مُحلّل يُطبَّق على خريطة ذاكرة لا يفهمها: رقم قطعة يجلس في حقل اسم المورّد، رقم تسلسلي غير قابل للقراءة، الموصل والترميز منزاحان. وحدة معطوبة أو قراءة I2C معطوبة تعطيك خطأً أو كتلة من الأصفار، وليس سلاسل خاطئة بترتيب أنيق.

مسار التفكيك يعيش في sonic_platform_base/sonic_sfp/sfputilbase.py، وهناك تُنتزع السلاسل الثلاث الخاصة بالهوية من إزاحات مُثبَّتة في الكود مقابل خريطة SFF القديمة، أيًا كان الموصول فعليًا. وحدة QSFP-DD من نوع CMIS 4.0 لا تحتفظ بكتلة هويتها في تلك العناوين - مواصفة CMIS 4.0 تصفها في القسم 8.3 - لذا الكود يقرأ بايتات حقيقية من الوحدة الصحيحة، فقط ليست تلك التي يعتقد أنه يقرأها، ويطبع أيًا كان يشغل ذلك النطاق. وهذا أيضًا سبب عدم فشل أي شيء بشكل نظيف أبدًا: لا توجد خطوة تنظر إلى بايت المُعرّف وتتحول إلى تخطيط CMIS.

الاستنتاج العملي هو أن لا شيء أقل من مُحلّل يفهم خريطة CMIS سيصحح هذا، وحتى يصل ذلك إلى فرعك، ناتج CLI لهذه القطعة ليس بمستوى الجرد. لقاعدة بيانات الأصول، اقرأ الصفحات الخام وفكّكها بنفسك بدلاً من كشط CLI.

للقراءة الخام، برنامج التشغيل optoe هو ما تحتاجه: يعرض EEPROM الخاصة بـ SFP وQSFP وCMIS للقراءة والكتابة المباشرة، حتى تستطيع سحب البايتات وتفكيكها في سكريبت خاص بك. هذا هو الشيء الوحيد الذي سأُطعمه لقاعدة بيانات الأصول بخصوص قطع CMIS في الوقت الحالي.

تحذير واحد إذا بحثت عن الإزاحات. الجدول الذي يقتبسه الجميع هو جدول SFF - A0h البايتات 20-35 لاسم المورّد، 40-59 لرقم القطعة والمراجعة والرقم التسلسلي. هذه بالضبط الإزاحات التي تُنتج القمامة لديك على وحدة CMIS، فلا تُعِد استخدامها هناك. نفس الحذر على مضيف لينكس كأداة اختبار: ethtool -m للعرض المُفكَّك وethtool -e للبايتات الخام جيدان لقطع SFP، لكن تحقق مما يفهمه بناؤك فعليًا قبل الوثوق بالحقول التي يطبعها لقطع CMIS.

معالجة CMIS ضعيفة في أماكن أكثر من مُفكِّك EEPROM. وضعنا صينية من وصلات InnoLight 800G QSFP-DD الضوئية في الخدمة، T-DP8CNH-NNO وT-DP8CNT-NNO، وحوالي كل إدخال ثانٍ تركنا بمنفذ ميت: أبلغت مسارات البيانات DataPathDeactivated، وحمل السجل مهلة انتظار لـ 'ConfigSuccess'، ومن هناك بقي المنفذ معطلاً بشكل دائم - لا إعادة محاولة، لا شيء يعيده من تلقاء نفسه.

تبيّن أن الجاني هو decommission_all_datapaths() في cmis.py. يمر عبر التسلسل الكامل تباعًا - DEINIT، مسح معرّف التطبيق إلى 0، ثم INIT - ولا يتحقق أبدًا من أن خطوة ما أخذت مفعولها فعلاً قبل بدء التالية. قطعنا تحتاج بالضبط ذلك التأكيد، لذا يُترك مسار البيانات نصف مُهيّأ وتجلس آلة الحالة ببساطة حتى ينتهي مؤقتها. الإصلاح الحقيقي يجب أن ينتظر بشكل غير متزامن، بما أنه لا يمكنك الحظر داخل آلة حالة CMIS المضمّنة في xcvrd، وآخر ما تحققت منه لم يكن أحد قد أنجز واحدًا. خلل مختلف، نفس الموضوع: مسار CMIS مُركَّب على كود كُتب لقطع SFF.

تصحيح واحد للاتجاه الذي ينجرف إليه هذا، لأن نمطي الفشل يُخلطان باستمرار. Cannot get Module EEPROM data: Invalid argument، أو اختفاء QSFP من sfputil بعد دورة تشغيل حتى يُصلَح برنامج التشغيل، أو منصة لا تُنفّذ get_transceiver_info أصلاً - هذه ثغرات منصة وبرنامج تشغيل، وتوقفك قبل أن يحدث أي تفكيك أصلاً.

ما هو موصوف هنا هو العكس: قراءة كاملة وناجحة تُفسَّر بعد ذلك بتخطيط حقول خاطئ. لا تُبدّل الوحدات أو تُطارد إصدارات برنامج التشغيل بسبب هذا. البايتات داخل تلك الوحدة سليمة، وأي أداة تفكّكها كـ CMIS ستُظهر لك الرقم التسلسلي الموجود على الملصق.