بطاقة AMD RX 9070 خارجية تنهار في وضع الخمول فقط؟ افحص ULPS أولاً

لا تزال Nvidia الخيار الآمن لأعمال الذكاء الاصطناعي. المشكلة في ثمن هذا الأمان: بطاقة RTX 5090 تقترب من ثلاثة آلاف دولار. وفي المقابل كان لديّ حاسوب مصغّر على الرف لا يفعل شيئاً سوى الخمول على رسومياته المدمجة، فغلبتني الرغبة في تحويله إلى منصة اختبار مخصصة لوكلاء الذكاء الاصطناعي. فبدلاً من تسليم المال إلى Nvidia، اشتريت بطاقة AMD Radeon RX 9070 بنحو ربع السعر، وعلّقتها خارج الجهاز عبر منصة بطاقة خارجية (eGPU dock)، وشغّلت المنظومة كلها على واجهة Vulkan المفتوحة من AMD بدلاً من CUDA. ثم خسرت الجزء الأكبر من شهر في التشخيص. هذا هو المقال الذي تمنيت لو كان بين يديّ قبل أن أبدأ.

إليك النسخة المختصرة، إن كنت في حالة هلع وعلى وشك إعادة قطعة ما إلى البائع. إن كنت قد وصلت بطاقة رسوميات منفصلة بحاسوب مصغّر أو حاسوب محمول عبر OCuLink أو USB4، وكانت تنهار أو تختفي بهدوء، لكن فقط بعد أن يبقى الجهاز خاملاً، ولا يحدث ذلك أبداً وهو يعمل فعلاً على شيء ما، فالكابل ليس مشكلتك. ولا المنصة، ولا البطاقة. لا تُعِد شيئاً بعد.

الخلاصة

• يأتي تعريف AMD بخاصية لتوفير الطاقة تُسمى ULPS (حالة الطاقة المنخفضة جداً، UltraLow Power State). حين يدخل النظام في الخمول، تُطفئ الخاصية أي بطاقة رسوميات قرر التعريف أنها "ثانوية". كُتبت هذه الخاصية للحواسيب المحمولة التي تتبدل بين رسوميات مدمجة وأخرى منفصلة، وعلى منصة بطاقة خارجية تخطئ الهدف، لأن بطاقتك الخارجية تبدو "ثانوية" بالمعنى الذي يهتم به التعريف تماماً.
• إيقاظ البطاقة من جديد هو موضع الانهيار. وما تحصل عليه يختلف من يوم إلى آخر: مهلة تعريف منتهية، أو جهاز يسقط من الناقل، أو عطل نظام كامل، أو تجمّد الجهاز بأكمله من دون أي ملف تفريغ.
• الحل قيمتان في السجل، EnableUlps وEnableUlps_NA، تُضبط كلتاهما على 0، مع إيقاف التعليق الانتقائي لمنافذ USB. لا حاجة إلى عتاد جديد.
• الدليل على أن المشكلة هنا وليست في التوصيلات: الأعطال تتجمع عند الخمول ولا تحدث أبداً في منتصف العمل. هذا الترابط وحده هو التشخيص كله تقريباً.

1. الإعداد

العتاد: حاسوب مصغّر بمعالج Ryzen مع رسومياته المدمجة، وبطاقة Radeon RX 9070 منفصلة (معمارية RDNA4) في حاوية خارجية عبر OCuLink، مع USB4 على المنصة نفسها كمسار احتياطي. للحوسبة تجاوزت ROCm واستخدمت واجهة Vulkan المفتوحة من AMD. مسار Vulkan في llama.cpp متين على RDNA4، وفيما كنت أفعله تفوّق بفارق كبير على البديل المعتمد على المعالج المركزي. لا شيء من هذا غريب. إنه الشكل المعتاد لأي تجميعة بطاقة خارجية على مضيف صغير الحجم أو من فئة الحواسيب المحمولة: بطاقة رسوميات ملحومة على اللوحة، وأخرى تعيش في صندوق على المكتب.

تبيّن أن هذا الشكل المعتاد مهم، لأنه بالضبط الشكل الذي يتوقع تعريف AMD أن يراه على حاسوب محمول. فيطبّق عليه قواعد الحواسيب المحمولة، ومن هنا تبدأ المتاعب.

2. الأعراض

عطل واحد ارتدى أربعة أقنعة مختلفة على مدى تلك الأسابيع. إن كنت تنقّب الآن في عارض الأحداث (Event Viewer)، فهذه هي الرموز التي ظللت أصطدم بها:

الرمز	الاسم	كيف بدا هنا
0x116	VIDEO_TDR_FAILURE	تجاوز التعريف نافذة اكتشاف المهلة والتعافي، فتخلى Windows عن البطاقة.
0x10E	VIDEO_SCHEDULER_INTERNAL_ERROR	مسجّل مع معامل STATUS_DEVICE_REMOVED. الترجمة: البطاقة غادرت الناقل في منتصف الجلسة.
0x7E	SYSTEM_THREAD_EXCEPTION_NOT_HANDLED	انتهاك وصول داخل خيط في التعريف. بصمة مختلفة، والسبب الكامن نفسه.
لا يوجد	تجمّد تام، بلا ملف تفريغ	الأسوأ على الإطلاق. يتوقف الجهاز ببساطة. لا عطل نظام، ولا ملف تفريغ مصغّر، ولا شيء في السجل سوى تلك العبارة الدامغة "كان إيقاف التشغيل السابق غير متوقع" عند الإقلاع التالي.

الخيط الذي يربط الأربعة معاً: لم يحدث أي منها أثناء اختبار إجهاد، أو تحميل نموذج، أو تصيير، أو أي شيء يُبقي البطاقة مشغولة. كل واحد منها ضرب بعد توقف العمل. أحياناً بعد دقيقة. ومرة بعد 21 ساعة من التشغيل المثالي.

3. ما استبعدناه أولاً (وكيف)

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

• ضبط مهلة TDR. رفعت TdrDelay وTdrDdiDelay إلى 60 ثانية. أوقف ذلك الشاشات الزرقاء أثناء نقل متوقف عمداً، وكان ذلك مفيداً، لكنه كان يخفي التوقف لا يزيله.
• إعادة تركيب كل شيء. أطفأت الجهاز، وسحبت البطاقة، وأعدت تركيبها، وأعدت توصيل كل كابل، ثم اشتريت كابلاً جديداً مصنفاً لكامل عرض نطاق الوصلة. لم يتزحزح النمط.
• تبديل الوصلة بالكامل. تعرض المنصة كلاً من OCuLink وUSB4 للمضيف، فجربت الاثنين. موصّل تالف في أحد المسارين لا ينبغي أن يُسقط الآخر، ومع ذلك فشل بالطريقة نفسها على كليهما. هذه نتيجة سلبية مفيدة: أعطال متطابقة عبر وصلتين ماديتين مستقلتين تبعد الشبهة عن كابل أو منفذ واحد تالف.
• إعادة بناء المنظومة كلها. على احتمال ضعيف أن يكون ملف ثنائي قديم هو السبب، أعدت بناء منظومة حوسبة البطاقة من المصدر على تعريف Vulkan الحالي. لم يتغير شيء.
• الضغط عليها. دورات كاملة متكررة لتحميل الذاكرة وتفريغها، ثم عشرون دقيقة من الطلبات الثقيلة المتواصلة، واحدة تلو الأخرى. نجحت بلا أخطاء. ثم انهارت بعد نحو ساعة وهي لا تفعل شيئاً على الإطلاق. كان ينبغي أن ينبهني ذلك مبكراً: بطاقة تتحمل الإجهاد الحقيقي ثم تموت في الراحة ليست لديها مشكلة عرض نطاق ولا مشكلة حرارة.

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

كل الأعطال تشاركت سمة واحدة: ضربت بعد أن دخلت البطاقة في الخمول، ولم تضرب أبداً وهي تعمل.

4. السبب الحقيقي: ULPS

ULPS، اختصار حالة الطاقة المنخفضة جداً (UltraLow Power State)، حيلة لتوفير الطاقة مدمجة في تعريف الرسوميات من AMD. على حاسوب محمول برسوميات قابلة للتبديل تستحق مكانها: حين يعمل الجهاز على البطارية ولا شيء متطلب يعمل، يكاد التعريف يطفئ البطاقة المنفصلة تماماً ويترك المدمجة تدير سطح المكتب. توفير حقيقي في البطارية.

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

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

5. الحل

قيمتان في السجل وإعداد طاقة واحد. كل ما هنا قابل للتراجع عنه، ولا شيء منه يكلفك قطعة.

1. تعطيل ULPS على البطاقة

افتح محرر السجل (أو PowerShell) بصلاحيات المسؤول وانتقل إلى مفتاح تعريف محوّل العرض:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\
{4d36e968-e325-11ce-bfc1-08002be10318}\0000, 0001, 0002 …

كل مفتاح فرعي من أربعة أرقام هو بطاقة رسوميات يعرفها Windows. افتحها واحداً تلو الآخر، واقرأ DriverDesc للتأكد من أنك على البطاقة المنفصلة لا المدمجة (اترك المدمجة كما هي)، واضبط:

EnableUlps     = 0  (DWORD)
EnableUlps_NA  = 0  (DWORD)

إن ظهرت البطاقة تحت أكثر من مفتاح فرعي، وهذا يحدث كثيراً، فطبّق ذلك عليها كلها.

حيث يصبح الأمر مثيراً للجنون. إن كانت خاصية سلامة الذاكرة (Memory Integrity، أو Core Isolation / HVCI) مفعّلة، يحمي Windows هذا المفتاح تحديداً من الكتابة. صلاحيات المسؤول المرتفعة لن تساعد. الاستحواذ على ملكية المفتاح لن يساعد. تحصل فقط على رسالة جافة "Requested registry access is not allowed" بلا أي تلميح إلى السبب.

الطريق للخروج: أوقف سلامة الذاكرة من أمان Windows ← أمان الجهاز ← عزل النواة، وأعد التشغيل، ونفّذ التعديل، ثم قرر إن كنت تريد إعادة تفعيل سلامة الذاكرة. القيمة تبقى في الحالتين. وإن كنت تفضّل ألا تقترب من هذا الإعداد إطلاقاً، فأداة Radeon ULPS Toggle من TechPowerUp تبدّل القيمتين نفسيهما عبر مساعد مرتفع الصلاحيات خاص بها، وتستحق نظرة.

2. إيقاف التعليق الانتقائي لمنافذ USB

كثيراً ما تتشارك متحكمات OCuLink وUSB4 السيليكون نفسه على هذه اللوحات، فأغلق هذا الباب أيضاً ما دمت هنا:

powercfg /setacvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setdcvalueindex SCHEME_CURRENT 2a737441-1930-4402-8d77-b2bebba308a3 48e6b7a6-50f5-4782-a5d4-53bb8f07e226 0
powercfg /setactive SCHEME_CURRENT

3. إعادة التشغيل

يُقرأ تغيير ULPS عند تهيئة التعريف، لا أثناء العمل. أعد التشغيل مرة واحدة. لا تتخطَّ هذه الخطوة، وإلا بدا اختبارك تماماً كحل فشل.

6. كيف تتحقق فعلاً من نجاح الحل

يتخطى الجميع تقريباً هذه الخطوة، وتخطيها هو بالضبط سبب أن نسختي استغرقت أسابيع بدلاً من أيام. الاختبار السريع لا يثبت شيئاً هنا. العطل كله يدور حول الخمول، وبعض أشكاله لا تترك حتى سجلاً؛ فالتجمد التام قد يبقى ساعات قبل أن تلاحظ أن الجهاز قد توقف. خمس دقائق لا تخبرك بشيء. وساعة من اختبار الإجهاد لا تخبرك بشيء أيضاً، لأن الحمل لم يكن السؤال قط.

ما ينجح هو الممل: نص برمجي صغير يكتب نبضة موقّتة في ملف كل بضع ثوانٍ ويستمر في العمل، لأطول مدة تطيق ترك الجهاز وحده. عدة ساعات على الأقل. وطوال الليل إن استطعت.

2026-07-23 21:22:11 IDLE SOAK START
2026-07-23 21:22:11 | GPU=OK | WHEA_total=0 (delta=0)
2026-07-23 21:22:16 | GPU=OK | WHEA_total=0 (delta=0)
2026-07-23 21:22:21 | GPU=OK | WHEA_total=0 (delta=0)
… 9,209 more lines, five seconds apart, zero gaps …
2026-07-24 10:46:57 | GPU=OK | WHEA_total=0 (delta=0)

أمران تبحث عنهما بعد ذلك:

• أي فجوة بين طابعين زمنيين متتاليين أطول بشكل ملحوظ من فاصل النوم الذي ضبطته. هذا توقف، حتى لو تعافى النظام منه بهدوء، ويعني أن الحل لم يكتمل بعد.
• أي أخطاء عتاد في تلك النافذة. على Windows، افحص المصدر Microsoft-Windows-WHEA-Logger بحثاً عن أخطاء PCIe مصحّحة، فهي تميل إلى الظهور قبل أن يسوء أي شيء آخر بشكل مرئي.

ولأن السجل على القرص، يُكتب سطراً سطراً، فإنه ينجو حتى من التجمد التام. عُد إلى جهاز ميت، والسطر الأخير يخبرك بالضبط متى مات.

قائمة تحقق، إن كنت تحفظ هذه الصفحة للرجوع إليها

• أعطال بعد الخمول فقط، لا تحت الحمل أبداً ← انظر إلى إدارة الطاقة، لا إلى الوصلة.
• ابحث في عارض الأحداث عن 0x116 و0x10E و0x7E، وافحص Microsoft-Windows-WHEA-Logger بحثاً عن أخطاء PCIe مصحّحة.
• قبل أن تستبدل أي شيء، اضبط EnableUlps وEnableUlps_NA على 0 في مفاتيح البطاقة المنفصلة وأوقف التعليق الانتقائي لمنافذ USB.
• إن رُفضت الكتابة في السجل، فاشتبه في سلامة الذاكرة (HVCI)، لا في صلاحياتك.
• أعد التشغيل قبل الاختبار. الإعداد لا يسري حتى تفعل.
• تحقق باختبار خمول يمتد عدة ساعات، لا باختبار حمل. الحمل لم يكن المشكلة قط.

---

كُتب هذا المقال من سجل تشخيص حقيقي امتد عدة أسابيع على حاسوب مصغّر بمعالج AMD Ryzen مع بطاقة RDNA4 عبر حاوية OCuLink/USB4. تعديل السجل وإيقاف خصائص أمان نظام التشغيل ينطويان على مخاطر حقيقية، فاعرف ما تغيّره وأعده إلى حاله إن لم تكن بحاجة إليه بشكل دائم. قد تختلف المفاتيح والمسارات بين إصدارات التعريف؛ تأكد من DriverDesc قبل أن تلمس أي شيء.