حقل المورّد لوحدة AFBR-89BDDZ من نوع QSFP28 يقرأ 0905000000000000 بعد نقل واجهة SP/FPGA إلى FIFO
نحن نشرف على البرنامج الثابت لإدارة المحوّل على عتادنا الخاص، ومنذ أن تغيّرت واجهة SP/FPGA من نُسخ (buffers) مربوطة بالذاكرة إلى FIFO، أصبح جرد وحدات الإرسال والاستقبال يعود بقيم غير صالحة على بعض المنافذ.
- بصريات QSFP28، جميعها AFBR-89BDDZ من نفس الدفعة
- القراءات تمر عبر مسار معالج الخدمة (service processor) وFPGA إلى EEPROM الوحدة
- المُساعد في جانب المضيف هو get_i2c_status_and_read_buffer: يتحقق من الحالة، يقرأ النُسخة بأكملها، يتحقق من الحالة مجدداً
ما نحصل عليه بدلاً من بيانات المورّد:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersما جربناه حتى الآن:
- أعدنا قراءة نفس المنفذ عدة مرات متتالية، والقيم غير الصالحة ثابتة لكل منفذ وليست ضوضاء عشوائية
- أعدنا تدوير طاقة الوحدات، دون فرق
- تأكدنا من أن كل وحدة في الهيكل هي نفس رقم القطعة، إذن هذا ليس سوء فك تشفير من جانبنا لكتلة مورّد غريبة ما
قبل أن نبدأ بسحب البصريات من الإنتاج، هل من المرجح أن يكون هذا سببه الوحدات، أم مسار I2C، أم مساعد القراءة الخاص بنا؟
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 7
هذا يشير مباشرة إلى مسار القراءة، وتغيير FIFO هو السبب. النُسخة المربوطة بالذاكرة تُعيد نفس المحتوى مهما سألت مرات؛ أما FIFO فتُسلّم كل بايت مرة واحدة بالضبط ثم يختفي. التسلسل الموروث في get_i2c_status_and_read_buffer، فحص الحالة، قراءة النُسخة كاملة، فحص الحالة مجدداً، كان منطقياً مع ذاكرة خلفه ولا يكون كذلك مع FIFO: يُفرغ الطابور بينما قراءة EEPROM الوحدة لا تزال على الخط. تحصل على أياً كان الموجود هناك في تلك اللحظة، والبايتات التي تصل متأخرة تبقى خلفاً وتظهر في القراءة التالية.
هذا بالضبط البصمة التي تصفها. قيم غير صالحة ثابتة لكل منفذ، فساد يسير مع التسلسل، أصفار كاملة على جهاز وأنماط أرقام مكررة على آخر حسب كيفية سقوط التوقيت. لا شيء هناك يتطلب وحدة معطوبة، ونتيجة استبدالك تستبعد البصريات على أي حال.
الحل هو التوقف عن جعل المستدعي (caller) مسؤولاً عن فحص الاكتمال. انقل تلك المسؤولية داخل روتين القراءة الخاص بتعريف وحدة الإرسال والاستقبال نفسه: ينتظر حتى تُبلغ معاملة I2C بالانتهاء وعندها فقط يلمس النُسخة، بحيث لا يستطيع أي مستدعٍ تفريغها مبكراً بحكم البنية. ترقيع موضع استدعاء واحد كان سيدفع السباق (race) إلى مكان آخر فحسب.
تحذير عادل بأن هذا هو الشكل المقترح للإصلاح وليس شيئاً خلفه سنوات، لذا تحقق منه على منصتك الخاصة قبل أن تثق بالجرد مجدداً. درس رخيص يستحق أخذه رغم ذلك: سلاسل المورّد المشوّهة تستحق اختبار وحدة مقابل منفذ أولاً، لأن ترتيب القراءة يتبيّن أنه المذنب أكثر بكثير من البصريات.
القياس الواحد الذي يفصل هذا إلى نصفين: هل يبقى الفساد مع الوحدة أم مع المنفذ؟ أخرج الوحدة من المنفذ الذي يعيد
0905000000000000، بدّلها بوحدة من منفذ يقرأ بشكل صحيح، وأعد قراءة كليهما. إن تبعت السلسلة السيئة الوحدة الفيزيائية، فاذهب وانظر إلى البصريات. إن بقيت مع رقم المنفذ، أو الأسوأ، انتقلت إلى أي وحدة تُقرأ بعد ذلك، فالوحدات بريئة ولديك مشكلة قراءة في المضيف.بينما أنت هناك، فرّغ بايتات EEPROM الخام إلى جانب الحقول المفكوكة الشيفرة. قيم غير صالحة في سلسلة مورّد مفكوكة الشيفرة مع بايتات سليمة تحتها خلل مختلف تماماً عن قيم غير صالحة في البايتات نفسها.
أجريت ذلك الاستبدال على زوج من المنافذ. البيانات السيئة لم تنتقل مع الوحدة: المنفذ الذي كان يعيد
0905000000000000استمر في إعادتها مع وحدة مختلفة موصولة، والوحدة التي سحبناها قرأت بشكل مثالي في فتحتها الجديدة.أفضل من ذلك، عندما غيّرنا ترتيب قراءة المنافذ، انتقل الفساد مع التسلسل. القيم غير الصالحة تحط على أي وحدة تُقرأ بعد الوحدة التي تسيء التصرف. إذن هي تتبع ترتيب القراءة، لا القطعة الفيزيائية. البايتات الخام خاطئة أيضاً، إذن ليست مشكلة فك تشفير من جانبنا.
سبب جذري مختلف، نفس الفخ، من جانب التعريف. على Intel E810-C مع ice 1.15.4 خارج الشجرة (out of tree) حصلت على صفحات خاطئة وغير مكتملة من
ethtool -mعلى بصريات QSFP28: بيانات الصفحة 1 والصفحة 3، والعتبات ومراقبات كل ممر (lane)، لم تطابق ما تحمله الوحدة فعلياً. لم أحصل أبداً على بيان سبب جذري مناسب لذلك، أُغلق الموضوع كـ'محلول' دون تفاصيل كثيرة، لذا تعامل مع هذا كحكاية وليس كحقيقة مؤكدة.ما انتهى بي فعله كان تحديث تعريف ice وبرنامج E810 الثابت (NVM) باستخدام
nvmupdate64e، ومقارنة النتائج مع قراءة من تعريف ice داخل النواة على مضيف آخر، وسحب صفحات محددة بواسطةمع إزاحة (offset) وطول محددين، بدلاً من الثقة بالمخرجات المفكوكة الشيفرة. إن كانت منصتك تستطيع إجراء تفريغ خام، قارن الخام بالمفكوك الشيفرة قبل تصديق أي منهما.
يستحق توضيح الطبقات، لأن ذلك يُقصّر هذا النوع من البحث كثيراً. على Linux يفكّ
ethtool -mتشفير EEPROM الوحدة (اسم المورّد، وOUI، ورقم القطعة، والرقم التسلسلي، ورمز التاريخ، وقيم DDM عندما تحمله الوحدة)، ويُفرّغethtool -eالبايتات الخام، وحيثما يكون ناقل I2C مكشوفاً يقرأi2cdump -y 1 0x50عنوان A0h بينما يقرأi2cdump -y 1 0x51عنوان A2h.في A0h يعيش اسم المورّد في البايتات 20-35 ورقم القطعة والمراجعة والرقم التسلسلي في 40-59. لذا إن كان حقل المورّد مشوَّهاً بينما رقم القطعة بعده بعشرات البايتات سليم، فذلك وحده يقول إن القراءة معتمدة على التوقيت وليست بسبب EEPROM معطوب، وهذا يتوافق مع ما تراه.
عطل واحد لا يجدر الخلط بينه وبين هذا: عودة
ethtool -mبخطأ Input/output error هي عادة مجرد وحدة بلا DDM. البت 6 من البايت 92 في A0h هو العلَم الذي يحدد ما إذا كان A2h موجوداً أصلاً، وذلك الفحص أُدرج في تعريفي ixgbe وbnx2x داخل النواة منذ زمن طويل حتى يتوقفا عن محاولة الوصول إلى 256 بايت إضافية غير موجودة.نفس فئة المشكلة على أجهزة SONiC، لمن يصل من ذلك الجانب. يقول
sfputil show eepromCannot get Module EEPROM data: Invalid argument لوحدات معينة، أو يختلف بصمت معshow interfaces transceiver eepromعلى نفس المنفذ.مما واجهته، الأمر في الغالب فجوات في المنصة والتعريف وليس البصريات: استخدم الأمران أسماء مفاتيح غير متسقة في فرع 202012 وأُصلح ذلك في 202205، بعض المنصات تفقد وحدات QSFP من sfputil بعد إعادة تدوير الطاقة حتى يصل إصلاح للتعريف، وعلى بعضها الآخر get_transceiver_info ببساطة غير مُنفّذ. عندما أحتاج شيئاً أثق به للبرمجة النصية، أذهب إلى تعريف النواة optoe وأجري قراءات خام لـEEPROM الخاص بـSFP أو QSFP أو CMIS بنفسي. تحقق منها على منصتك الخاصة رغم ذلك، السلوك يتفاوت كثيراً بينها.
تحديث من جانبنا. نقلنا فحص الاكتمال إلى دالة القراءة في التعريف كما اقتُرح، وسلاسل المورّد صحيحة الآن على كل منفذ عبر بضع مئات من عمليات الجرد، بما في ذلك المنفذان اللذان كانا يتبادلان قيماً غير صالحة بينهما. البايتات الخام تطابق الحقول المفكوكة الشيفرة الآن.
أصنّف هذا جزئياً وليس مُغلقاً في الوقت الحالي: نحمله كترقيعة لم تصل بعد إلى شجرتنا، وهناك منصة إضافية ببناء FPGA مختلف يجب التحقق منها قبل أن نثق به في كل مكان. لكن البصريات كانت سليمة طوال الوقت، وهذا ما كنت سأُخطئ فيه بمفردي.