يتضمن هذا المصدر سلسلة قوية من خطوات استكشاف الأخطاء وإصلاحها الرسمية. ظل معالج N3350 في ZimaBlade قريبًا من 795-800 ميجاهرتز حتى أثناء رفع Jellyfin استخدام وحدة المعالجة المركزية إلى 100٪. وكانت درجات الحرارة نحو 34-45°م فقط، كما تكرر السلوك نفسه على ZimaBoard بعد تثبيت جديد وباستخدام المعالج نفسه. ثم فحصت IceWhale سياسة تردد وحدة المعالجة المركزية ووجدت scaling_governor تم تعيينه بشكل غير متوقع على userspace.
اقترح Zima-Jerry تبديل الحاكم إلى سياسة ديناميكية. فغيّره صاحب المنشور الأصلي إلى ondemand وأكد صراحةً أن وحدة المعالجة المركزية رفعت ترددها بعد ذلك إلى نحو 2.3 جيجاهرتز، وأن الاستجابة تحسنت بشكل كبير. وأفاد مستخدم ثانٍ بأن الحل البديل عاد إلى userspace بعد إعادة التشغيل، وردّ IceWhale بأن الإصدار التالي سيصلح المشكلة. لذلك ينبغي التعامل مع هذه الحالة باعتبارها تراجعًا تاريخيًا في حاكم ZimaOS، مع حل بديل وقت التشغيل أكدته المصادر، وليس تشخيصًا لعطل في العتاد.
لم تدعم الأدلة المصدرية فرضية الاختناق الحراري
كان المستخدم قد أضاف مشتتًا حراريًا ومروحة مخصصين، وأفاد بأن درجات حرارة وحدة المعالجة المركزية بقيت أقل من 45°م تحت الحمل. كما أشار إلى أن النظام كان أكثر سخونة سابقًا—حتى نحو 65°م—من دون مشكلة الاستجابة نفسها.
جعل ذلك تفسير «أن وحدة المعالجة المركزية ترتفع حرارتها وتخفض ترددها إلى 800 ميجاهرتز» غير متوافق بدرجة كبيرة مع الأدلة المرصودة.
تكرار السلوك نفسه على نظام ZimaOS آخر مُثبّت حديثًا
ثبّت صاحب المنشور الأصلي لاحقًا ZimaOS من جديد على ZimaBoard مزوّد بالمعالج نفسه، ولاحظ حدًا مماثلًا عند 800 ميجاهرتز وبطئًا مماثلًا في أداء Jellyfin. وقد قلّل ذلك من احتمال أن تكون إحدى لوحات ZimaBlade تالفة.
طلبت IceWhale سياسة تردد وحدة المعالجة المركزية الفعلية
فحصت أوامر التشخيص الرسمية ما يلي:
cat /sys/devices/system/cpu/intel_pstate/no_turbo
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governorهذه فحوصات للقراءة فقط، وهي أكثر أمانًا من فرض أعلى تردد فورًا أو تغيير إعدادات طاقة BIOS.
أن IceWhale عثر على scaling_governor=userspace
ذكر Zima-Jerry أن المخرجات المصدرية أظهرت userspace، في حين كان من المفترض ألا تترك سياسة ZimaOS المتوقعة في تلك المرحلة وحدة المعالجة المركزية عالقة عند ذلك.
تضمنت الخيارات المقترحة وقت التشغيل powersave أو ondemand، وذلك بحسب برنامج تشغيل cpufreq والحواكم المتاحة.
تم تأكيد أن ondemand يعيد تعزيز تردد وحدة المعالجة المركزية
كان أمر المصدر هو:
echo ondemand | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governorثم أبلغ صاحب المنشور عن ارتفاعات تصل إلى نحو 2.3 غيغاهرتز وتحسن كبير في الاستجابة.
جاء هذا الأمر مباشرةً من فريق IceWhale في النقاش التاريخي، لكن الأنظمة الحالية قد تعرض حواكم افتراضية مختلفة، مثل schedutil. تحقق من الحالة الحالية قبل كتابة أي شيء.
الحل البديل لم يستمر لدى مستخدم آخر
قال Khapra إن الأوامر أصلحت المشكلة خلال جلسة التشغيل، لكن بعد إعادة التشغيل عاد الحاكم إلى userspace. أجاب Zima-Jerry بأن الإصدار التالي سيحتوي على الإصلاح.
لا تنشئ خدمة مخصصة تعمل وقت الإقلاع على نظام ZimaOS حالي، ما لم يكن من الممكن إعادة إنتاج الخلل فعلًا على الإصدار الحالي ولم تكن IceWhale قد أصلحته بالفعل.
كان Jellyfin عبء العمل الذي كشف خلل سياسة وحدة المعالجة المركزية
أدى إنشاء الصور المصغرة/التحويل إلى تحميل وحدة المعالجة المركزية بما يكفي لجعل حد التردد واضحًا. لم يُثبت أن التطبيق هو السبب الجذري؛ بل كانت حالة حاكم وحدة المعالجة المركزية هي المشكلة على مستوى النظام، إذ منعت المعالج من الاستجابة للحمل.
أعد الاختبار أولًا على إصدار ZimaOS المستقر الحالي
كان المصدر ضمن سلسلة إصدارات 1.4.x. أما ZimaOS الحالي فأحدث بكثير. على نظام حالي، افحص الحاكم والتردد تحت الحمل قبل تطبيق الحل البديل لعام 2025.
تحدد وثائق عتاد ZimaBlade الحالية الطراز 3760 بمنصة Intel N3350 نفسها، لذا يظل التشخيص التاريخي مفيدًا عند تطابق الأعراض.
استخدم الخط الأساسي الحالي لعتاد ZimaBlade.
الأسئلة الشائعة حول ZimaBlade بتردد 800 ميغاهرتز
هل أثبت المصدر أن وحدة معالجة ZimaBlade المركزية معيبة؟
لا. تكررت المشكلة نفسها على نظام آخر، وتغيرت فورًا عند تغيير حاكم وحدة المعالجة المركزية.
ما الإعداد الذي اكتشفه IceWhale؟
scaling_governor تم ضبطه على userspace.
هل نجح وضع ondemand؟
نعم. أكد صاحب المنشور الأصلي أن تردد وحدة المعالجة المركزية ارتفع إلى نحو 2.3 غيغاهرتز، وأن استجابة Jellyfin والنظام تحسنت بشكل كبير.
