لا ينبغي تلخيص هذا المصدر بعبارة «عطّل Wake-on-LAN لإصلاح انقطاعات Intel I211». بدا العَرَض الأولي كأنه عطل في الشبكة، لكن التحقيق أظهر لاحقًا أن الوحدة الطرفية المحلية تجمدت أيضًا وأن النظام أصدر أخطاء متكررة مرتبطة بالبرامج الثابتة ووحدة المعالجة المركزية. أصبحت المشكلة مشكلة استقرار على مستوى المنصة بأكملها.
جاء أقوى تحقق من المستخدم بعد إجراء تغييرات على مستوى BIOS. عطّل المستخدم Global C-State Control وACPI Sleep/Suspend-to-RAM وSVM، ثم أبلغ عن مدة تشغيل مستقرة بلغت 3 أيام و15 ساعة و38 دقيقة، واعتبر المشكلة محلولة ظاهريًا. وكان يخطط لإعادة تفعيل الإعدادات واحدًا تلو الآخر، لذا لم يعزل النقاش أي إعداد فردي باعتباره المسؤول.
بدا العَرَض الأصلي كأنه انقطاع في شبكة Intel I211
فقد ZimaOS 1.5.3 الاتصال كل بضع ساعات وكان يتطلب إعادة التشغيل. وكان الجهاز نفسه مستقرًا عند تشغيل Windows Server، بينما ظل نظام ZimaOS آخر أحدث على الشبكة نفسها مستقرًا.
كان تعطيل ميزة الإيقاظ عبر الشبكة في بطاقة الشبكة اختبارًا مبكرًا من المجتمع
استخدم المجتمع استكشاف الأخطاء وإصلاحها ethtool لتعطيل WOL، واقترح تجنب إعداد عنوان IP ثابت مزدوج. كانت هذه اختبارات معقولة، لكن الجهاز تعطل مجددًا لاحقًا.
لذلك لا يمكن تقديم WOL باعتباره مصدر الحل النهائي المؤكد.
حسّن تحديث BIOS للوحة الأم مدة التشغيل، لكنه لم يحل المشكلة بالكامل
ذكر المستخدم أن تحديث BIOS زاد مدة التشغيل من نحو ثلاث ساعات إلى أكثر من عشر ساعات. ثم عادت المشكلة لاحقًا، ما يوضح أن التحسن والحل النهائي كانا مرحلتين مختلفتين.
تسبب العطل في النهاية في تجميد الوحدة الطرفية المحلية أيضًا
عند عودة المشكلة، لم تعد وحدة طرفية متصلة محليًا تقبل الأوامر. وكانت وحدة التحكم تكرر الأخطاء كل نحو 15 ثانية. أدى ذلك إلى تحويل التشخيص بعيدًا عن كونه مشكلة إعدادات إيثرنت بحتة.
أصبحت أخطاء حالات الطاقة في البرامج الثابتة وACPI أكثر صلة
احتوت السجلات على تحذيرات متكررة من البرامج الثابتة لـ ACPI بشأن حالات MWAIT الخاصة بوحدة المعالجة المركزية. كما اكتشف المستخدم أن تحديث BIOS قد غيّر سلوك السكون في ACPI. ثم عطّل عدة ميزات للطاقة والافتراضية لاختبار الاستقرار.
استقر المصدر بعد ثلاثة تغييرات في BIOS
- التحكم العام في حالات C: معطّل
- السكون عبر ACPI / التعليق إلى ذاكرة الوصول العشوائي: معطّل
- SVM: معطّل
بعد ذلك، أبلغ المستخدم عن أكثر من ثلاثة أيام من التشغيل المستقر.
لا تنسخ هذه الإعدادات بشكل عام. يؤدي تعطيل SVM أيضًا إلى تعطيل المحاكاة الافتراضية العتادية من AMD، وقد يمنع تشغيل ZVM أو الأجهزة الافتراضية الأخرى.
كان المصدر يحتوي أيضًا على فرع برنامج تشغيل NVIDIA GT 710 غير مدعوم
أوضحت السجلات أن برنامج تشغيل NVIDIA 580 المثبّت تجاهل GT 710 لأن وحدة معالجة الرسومات هذه تنتمي إلى فرع 470.xx القديم. كانت هذه مشكلة توافق حقيقية، لكن الموضوع لم يثبت أنها تسببت في حالات التجمّد.
يشمل توافق x86 الخارجي البرنامج الثابت، وليس برامج التشغيل فقط
يدعم ZimaOS حاليًا x86-64 العام، لكن IceWhale تحذّر صراحةً من أن كل لوحة أم أو وحدة تحكم أو جهاز رسومات أو واجهة شبكة ليست بالضرورة مُختبرة.
استخدم إطار استكشاف أخطاء الأجهزة الخارجية الحالي قبل تطبيق إعدادات BIOS الخاصة بـ AB350 على منصات أخرى.
التشخيص الحالي الأكثر أمانًا
- التقط سجلات الإقلاع السابق/النواة بعد العطل.
- حدّد ما إذا كانت الشبكة فقط هي التي تعطلت أم أن المضيف بأكمله تجمّد.
- حدّث البرنامج الثابت ضمن حدود دعم المعالج التي تحددها الشركة المصنّعة للوحة الأم.
- اختبر تغييرًا واحدًا فقط من تغييرات حالات الطاقة في BIOS كلما أمكن.
- أزل أجهزة التوسعة غير المتوافقة أو عطّلها إذا كان النظام يستطيع الإقلاع دونها.
- أعد اختبار المحاكاة الافتراضية فقط بعد التأكد من استقرار النظام الأساسي.
جمود وحدة التحكم المحلية غيّر التشخيص
عندما بدت المشكلة في البداية انقطاعًا في اتصال Intel I211، كانت اختبارات توفير طاقة بطاقة الشبكة وميزة التنبيه عبر الشبكة (Wake-on-LAN) منطقية. ولكن بمجرد أن توقفت وحدة التحكم المحلية عن الاستجابة أيضًا، أصبح تفسير المشكلة بأنها محض مشكلة في برنامج تشغيل Ethernet أقل إقناعًا بكثير.
هذا مبدأ تشخيصي عام: وسّع نطاق العطل عندما تتجاوز الأعطال أنظمة فرعية مستقلة.
تم تطبيق تغييرات BIOS الثلاثة الأخيرة معًا
عطّل المستخدم التحكم في حالات C العامة، والسكون/التعليق إلى ذاكرة الوصول العشوائي (ACPI Sleep/Suspend-to-RAM)، وSVM، ثم أبلغ عن استقرار لعدة أيام. ونظرًا إلى تغيير عدة متغيرات في الوقت نفسه، لا يستطيع المصدر تحديد الإعداد الفردي الذي أصلح الجهاز.
SVM هي ميزة دعم الافتراضية من AMD. وقد يؤدي تعطيلها إلى منع أحمال عمل الأجهزة الافتراضية، لذا لا ينبغي التوصية بتعطيلها بشكل عام لمجرد أنها كانت جزءًا من الاختبار الناجح في هذا المصدر.
كان تحديث BIOS دليلًا مفيدًا، رغم أنه لم يكن الحل النهائي
أدى تحديث البرامج الثابتة للوحة الأم إلى زيادة فترة الاستقرار من نحو ثلاث ساعات إلى أكثر من عشر ساعات. يشير ذلك إلى أن سلوك البرامج الثابتة/إدارة الطاقة كان مؤثرًا، لكن عودة المشكلة لاحقًا تُظهر أن التحديث وحده لم يكن كافيًا.
كان عدم توافق برنامج تشغيل GT 710 حقيقيًا، لكن لم يثبت أنه سبب التجمّد
أشارت السجلات إلى أن فرع NVIDIA 580 المثبّت لا يدعم GT 710 القديمة، التي تنتمي إلى فرع برامج التشغيل الأقدم. قد يؤدي ذلك إلى تعطيل وظائف وحدة معالجة الرسومات وإنتاج أخطاء، لكن المصدر لم يثبت أن إزالة برنامج تشغيل وحدة معالجة الرسومات أو تصحيحه وحده أصلح تجمّد الشبكة/المضيف.
ينبغي أن يبدأ تشخيص الأجهزة التابعة لجهات خارجية حاليًا من الإعدادات الافتراضية للبرامج الثابتة
على لوحة AM4 أقدم، حدّث BIOS، وسجّل الإعدادات الأصلية، وعطّل ميزات السكون المكثّف فقط كاختبار مضبوط، واجمع سجلات التشغيل السابق. ضع متطلبات Ethernet والافتراضية في الحسبان قبل تعطيل الميزات نهائيًا.
بعد استقرار النظام، أعد تفعيل ميزة واحدة من الميزات التي غيّرتها في كل مرة إذا كنت بحاجة إلى عزل الحد الأدنى من الحل البديل.
فترة التشغيل لعدة أيام التي حققها المصدر هي تحقق قوي من المستخدم، وليست اعتمادًا للمنتج
إنقضاء ثلاثة أيام وخمس عشرة ساعة دون الانهيار السابق دليل مهم على أن تغييرات البرامج الثابتة حسّنت أداء ذلك الجهاز. لكنه لا يثبت توافق كل منصات AB350/I211، ولا يثبت وجود عدم توافق عام بين ZimaOS ومجموعة الشرائح تلك.
الأسئلة الشائعة حول انقطاع الشبكة
هل كانت المشكلة النهائية من المصدر ناتجة حصريًا عن بطاقة الشبكة Intel I211؟
لا. تجمّد النظام المحلي أيضًا، ما جعل المشكلة أوسع وتتعلق باستقرار المنصة.
هل أدى تعطيل WOL وحده إلى حل المشكلة؟
لا. عاد العطل لاحقًا.
أي تغيير تزامن مع فترة الاستقرار النهائية؟
عطّل المستخدم حالات C العامة، وتعليق ACPI إلى ذاكرة الوصول العشوائي (Suspend-to-RAM)، وSVM، ثم أبلغ عن فترة تشغيل تجاوزت ثلاثة أيام.
