يتضمن هذا الموضوع الأصلي تجربة استقرار مفيدة تحققت منها حواسيب المجتمع، لكنها لا تثبت السبب الجذري في النواة. كان جهاز Aoostar R1 المزود بمعالج Intel N150 يشغّل ZimaOS لمدة يوم تقريبًا ثم يتوقف تمامًا: تصبح الشاشة فارغة، ويتوقف اختبار الاتصال، ولا تعود واجهة الويب قابلة للوصول حتى يتم فصل الطاقة وإعادة توصيلها.
أضاف صاحب الموضوع في النهاية عدة معاملات لإدارة الطاقة في Intel i915، بالإضافة إلى معامل لحالة طاقة NVMe، إلى سطر أوامر الإقلاع في ZimaOS. وبعد أربعة أيام، أفاد بأن الجهاز يعمل باستمرار واعتبر التغيير ناجحًا. يُعد ذلك تحققًا مهمًا من جانب المستخدم، لكنه لا يحدد من خلال سجل تفريغ الأعطال ما إذا كان الفشل مرتبطًا بميزة معينة في i915 أو بوحدة تحكم NVMe أو بهما معًا.
كان هذا توقفًا كاملًا للمضيف، وليس تعطلًا لتطبيق واحد
تمثلت الأعراض الواردة في المصدر في شاشة فارغة، وفشل اختبار الاتصال، وتعذر الوصول إلى واجهة الويب، والحاجة إلى فصل الطاقة فعليًا. وتُعد فئة الأعطال هذه أوسع من تعطل حاوية Docker أو جلسة متصفح قديمة، وينبغي التحقيق فيها على مستوى المضيف أو النواة أو العتاد.
كان الحاسوب المصغر نفسه مستقرًا تحت Unraid
ذكر المستخدم أن جهاز Aoostar R1 ظل مستقرًا لعدة أيام تحت Unraid أثناء تهيئة الأقراص مسبقًا، ثم بدأ بالتجمد يوميًا بعد تثبيت ZimaOS. وهذا يجعل وجود تفاعل بين البرمجيات وبرنامج التشغيل أمرًا محتملًا، لكن أنظمة التشغيل المختلفة تستخدم نوى وبرامج تشغيل وسياسات طاقة مختلفة على العتاد نفسه.
أصبحت إدارة طاقة i915 وNVMe الفرضية الرئيسية لدى المجتمع
عثر المستخدم على سطر أوامر إقلاع ZimaOS في /mnt/boot/cmdline.txt وأضاف:
nvme_core.default_ps_max_latency_us=0
i915.enable_psr=0
i915.enable_fbc=0
i915.enable_dc=0
i915.enable_guc=0كانت هذه معاملات استكشاف أعطال اختارها المستخدم، وليست إعدادات قياسية موصى بها من IceWhale لأنظمة Intel N100/N150.
أفاد المستخدم بأن الجهاز عمل أربعة أيام بعد التغيير
في 21 نوفمبر، عاد صاحب الموضوع الأصلي وذكر أن النظام وصل إلى أربعة أيام من وقت التشغيل وما زال يعمل. ويدعم ذلك الاستنتاج القائل إن التغييرات حسّنت استقرار ذلك الجهاز، لكنه لا يحدد أي معامل كان مؤثرًا.
اقترحت IceWhale بشكل منفصل إجراء اختبار مع تعطيل البحث
أشار Zima-Giorgio إلى تقارير أخرى تحسن فيها الاستقرار على بعض الأجهزة بعد تعطيل بحث ZimaOS. وتُعد هذه إرشادات منفصلة لاستكشاف الأعطال من IceWhale، ولا ينبغي دمجها مع نظرية i915/NVMe كما لو أن IceWhale أكدت السبب نفسه.
أدلة الأعطال أهم من تعديل كل إعدادات الطاقة المحتملة
حذّر مشارك آخر من أنه من دون سجلات التفريغ أو سجلات الإقلاع السابق، قد ينتهي الأمر بالمستخدمين إلى تغيير إعدادات طاقة وحدة معالجة الرسومات، وطاقة NVMe، وASPM، وحالات C، والشبكات، والبحث، من دون معرفة الطبقة التي فشلت فعليًا. في حالة حالية، اجمع سجلات النواة والخدمات من الإقلاع السابق بعد الاستعادة، وقارن الطوابع الزمنية المحيطة بآخر نشاط ناجح.
لا يعني الدعم العام لـ x86 أن كل سياسات الطاقة في الحواسيب المصغرة قد خضعت للتحقق مسبقًا
يدعم ZimaOS حاليًا رسميًا العتاد العام المتوافق مع x86-64، لكن اللوحات الأم ووحدات تحكم التخزين ومحوّلات الرسومات وبطاقات الشبكة من جهات خارجية قد تحتاج إلى فحوصات توافق إضافية.
استخدم حدود استكشاف أعطال x86 الحالية من جهات خارجية قبل افتراض أن توقف N150 له حل عام واحد.
ترتيب حالي أكثر أمانًا لاستكشاف الأعطال
- حدّث إلى أحدث إصدار مستقر من ZimaOS.
- سجّل إصدار BIOS واستعد الإعدادات الافتراضية المحافظة للبرامج الثابتة.
- اجمع سجلات النواة والخدمات من الإقلاع السابق بعد حدوث عطل.
- تحقق من صحة SSD/NVMe ودرجة الحرارة وذاكرة RAM والطاقة.
- اختبر ما إذا كان البحث أو حمل عمل آخر قابل لإعادة الإنتاج يتزامن مع التوقف.
- غيّر معامل إقلاع واحدًا في كل مرة متى كان ذلك عمليًا.
- احتفظ بنسخة من سطر أوامر الإقلاع الأصلي حتى يمكن التراجع عن التغيير.
الأسئلة الشائعة حول تجمّد Aoostar N150
هل أفاد المستخدم في المصدر بتحسن الاستقرار؟
نعم. أفاد بأنه حصل على أربعة أيام من وقت التشغيل بعد تغيير معاملات إقلاع مرتبطة بطاقة i915 وNVMe.
هل أكدت IceWhale أن i915 هو السبب الجذري؟
لا. اقترحت IceWhale بشكل منفصل إجراء اختبار مع تعطيل البحث؛ ولم يؤكد أي سجل تفريغ مصدر الفشل الدقيق.
هل ينبغي لكل مستخدم لـ ZimaOS على Intel N150 تعطيل PSR وFBC وDC وGuC؟
لا. كانت هذه الإعدادات تجربة لاستكشاف الأعطال خاصة بالمصدر، وليست تهيئة موصى بها عالميًا.
