جهاز USB يستمر في الانفصال: تصحيح أخطاء حلقات إعادة الضبط وأحداث الطاقة وحالات فشل التعداد

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

انفصال USB, حلقة إعادة ضبط USB, تعداد USB, إدارة طاقة USB, تشخيص USB

جهاز USB يستمر في الانفصال هو واحدة من أكثر مشكلات الأجهزة إحباطًا لأن العرض صاخب وغير متسق. يظهر الجهاز، ويختفي، ويعيد الاتصال، ويغير منفذ COM، ويفشل في التعداد، أو يعمل لبضع ثوانٍ ثم يعيد الضبط. يبحث المستخدمون عن "جهاز USB يستمر في الانفصال"، و"حلقة إعادة ضبط USB"، و"جهاز USB غير معروف بعد إعادة الاتصال"، و"لماذا يعيد جهاز USB الخاص بي التعداد" لأن رسالة نظام التشغيل نادرًا ما تشرح ما حدث بالفعل.

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

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

ما يمكن أن يعنيه "الانفصال"

يمكن أن تصف عبارة "انفصال USB" عدة حالات فشل مختلفة:

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

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

حلقة إعادة تعيين التعداد

غالبًا ما تبدأ حلقة إعادة التعيين بأن المضيف يكتشف جهازًا، ويعيد تعيين المنفذ، ويقرأ الواصفات، ويعين عنوانًا، ثم يفشل قبل اكتمال التهيئة. تتكرر الدورة.

يبدو التسلسل المبسط كـ:

Port reset
GET_DESCRIPTOR device
SET_ADDRESS
GET_DESCRIPTOR configuration
SET_CONFIGURATION
Disconnect
Port reset
GET_DESCRIPTOR device
...

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

مشاكل الطاقة يمكن أن تبدو كمشكلات بروتوكول

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

  • كاميرات USB
  • بطاقات التقاط USB
  • الأقراص الخارجية
  • لوحات التطوير
  • مودمات الخلايا
  • الأجهزة المتصلة عبر موزعات سلبية
  • كابلات طويلة أو رديئة الجودة

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

لا يمكن لـ Bus Scope قياس الجهد مباشرة، لكنه يمكن أن يُظهر التوقيت والتسلسل حول إعادة الضبط. إذا كانت آخر عملية ناجحة هي بدء تدفق ثقيل على عرض النطاق الترددي أو أمر وضع الطاقة/المحرك، فإن الدليل يشير إلى الضغط على الطاقة أو البرامج الثابتة.

التعليق الانتقائي وإدارة طاقة وقت التشغيل

قد تعلّق أنظمة التشغيل أجهزة USB الخاملة لتوفير الطاقة. هذا طبيعي عندما يدعم الجهاز وبرامج التشغيل ذلك بشكل صحيح. يصبح مشكلة عندما لا تستأنف البرامج الثابتة للجهاز بشكل نظيف أو عندما يعلّق برنامج التشغيل جهازًا يتوقع التطبيق أن يظل نشطًا.

تشمل الأعراض:

  • يعمل الجهاز بعد التوصيل لكنه يفشل بعد وقت خمول.
  • الطلب الأول بعد الخمول يُرجع خطأ.
  • يختفي الجهاز بعد النوم أو قفل الشاشة.
  • يتغير حالة الجهاز التسلسلي بعد الاستئناف.
  • يفقد جهاز HID الإدخال بعد الاستيقاظ.

يمكن أن يُظهر تتبع USB ما إذا كانت الحركة قد توقفت قبل الفشل وما إذا كان قد حدث تسلسل استئناف/إعادة تعيين. هذا أكثر فائدة من التخمين من رسالة خطأ التطبيق.

توقف نقطة النهاية قبل الانفصال

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

ابحث عن:

  • STALL على نقل تحكم.
  • عمليات نقل bulk فاشلة متكررة.
  • CLEAR_FEATURE(ENDPOINT_HALT).
  • إعادة ضبط بعد نفس الطلب في كل مرة.
  • مهلة قبل الانفصال.

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

حلقات إعادة تعيين الأجهزة المركبة

تكشف أجهزة USB المركبة عن واجهات متعددة تحت جهاز واحد. على سبيل المثال، قد يوفر الجهاز:

  • واجهة CDC تسلسلية
  • واجهة تحكم HID
  • واجهة تخزين كبيرة السعة
  • واجهة تشخيص خاصة بالبائع

يمكن أن يعد الجهاز جزئيًا ولا يزال يفشل عندما يلتصق برنامج تشغيل واجهة واحدة. قد يرى المستخدمون "تم التعرف على جهاز USB" يليه انفصال فوري لأن واجهة واحدة تشغل عطل البرامج الثابتة أو تعارض برنامج التشغيل.

في التتبع، افحص واصفات الواجهة والإعدادات البديلة وواصفات نقطة النهاية والطلبات الخاصة بالفئة. قد تحدث إعادة الضبط فقط بعد أن يبدأ المضيف في تكوين واجهة محددة.

أجهزة عرض النطاق الترددي العالي

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

تشمل الأسباب الشائعة:

  • فشل حجز عرض النطاق الترددي المتساوي الزمن.
  • مهلة نقطة نهاية bulk.
  • ضغط عرض النطاق الترددي لوحدة تحكم المضيف.
  • عنق زجاجة الموزع.
  • عدم تطابق وضع USB 2.0 مقابل USB 3.x.
  • تجاوز سعة مخزن البرامج الثابتة المؤقت.
  • اختيار برنامج التشغيل لإعداد بديل غير مدعوم.

إذا حدث الانفصال بعد طلب بدء البث أو تغيير إعداد بديل، افحص النقل الدقيق الذي يأتي قبل إعادة الضبط. هذا غالبًا أهم دليل.

ما يجب التقاطه

لانفصال قابل للتكرار، التقط من قبل التوصيل أو قبل الإجراء الفاشل. تريد القصة الكاملة:

  1. توصيل الجهاز.
  2. إعادة تعيين المنفذ.
  3. قراءات الواصفات.
  4. تعيين العنوان.
  5. اختيار التهيئة.
  6. طلبات برنامج تشغيل الواجهة.
  7. أول نقل تطبيق عادي.
  8. آخر نقل ناجح قبل الفشل.
  9. مهلة، توقف، إعادة ضبط، أو انفصال.
  10. إعادة التعداد بعد الفشل.

بدء الالتقاط بعد فشل الجهاز بالفعل يفقد أهم دليل.

قائمة مراجعة التصحيح

استخدم هذا الترتيب:

  1. أعد الإنتاج بكابل قصير ومعروف جيدًا.
  2. تجنب الموزعات السلبية أثناء الاختبار الأول.
  3. التقط التعداد من التوصيل.
  4. تحقق مما إذا كان الفشل يحدث قبل أو بعد SET_CONFIGURATION.
  5. حدد آخر طلب ناجح.
  6. ابحث عن التوقفات والمهلات وإعادة الضبط المتكررة.
  7. قارن فشل الخمول مقابل فشل تحت الحمل.
  8. اختبر منفذ USB أو وحدة تحكم أخرى.
  9. عطّل التعليق الانتقائي فقط بعد جمع الأدلة.
  10. قارن نفس الجهاز على نظام تشغيل آخر إن أمكن.

التشخيص النهائي

"جهاز USB يستمر في الانفصال" عرض، وليس سببًا جذريًا. يعتمد الإصلاح على ما إذا كانت الأدلة تُظهر عدم استقرار الطاقة، أو إعادة ضبط البرامج الثابتة، أو فشل الواصفات، أو فشل طلب فئة برنامج التشغيل، أو توقف نقطة النهاية، أو مشكلة تعليق/استئناف، أو زيادة تحميل عرض النطاق الترددي.

يساعد Bus Scope من خلال إظهار معاملات USB حول الفشل بحيث يمكنك التوقف عن التخمين من إشعارات سطح المكتب وبدء التصحيح من سلوك الناقل الفعلي.

<!-- bus-scope-localized-transaction-foundation-v1:start -->

اختبار عقد USB لموضوع «جهاز USB يستمر في الانفصال: تصحيح أخطاء حلقات إعادة الضبط وأحداث الطاقة وحالات فشل التعداد»

الإجابة المباشرة هي أن رمز STALL أو timeout أو reset لا يشرح السبب وحده. يجب أولًا إثبات أن مزود الالتقاط يرى الجهاز الصحيح، ثم قراءة عقد الـtransfer: نوع الطلب واتجاهه وrecipient وwValue وwIndex والطول المعلن والطول الفعلي وstatus والحالة السابقة واللاحقة. في «جهاز USB يستمر في الانفصال: تصحيح أخطاء حلقات إعادة الضبط وأحداث الطاقة وحالات فشل التعداد» اربط كل استنتاج بأول transaction يختلف عن تشغيل معروف النجاح، لا بآخر رسالة يعرضها التطبيق.

حد التحقق ما يجب مقارنته الحكم المفيد
المنصة provider والصلاحية وRoot Hub أو usbmon/XHC20 هل تصل records من الاتصال الصحيح؟
setup bmRequestType وbRequest وwValue وwIndex وwLength هل أرسل المضيف الطلب المقصود؟
data الاتجاه والطول والbytes المحفوظة هل تطابق payload العقد؟
status ACK أو STALL أو timeout أو cancellation أين انتهت المعاملة فعليًا؟
الحالة configuration وinterface وalternate setting وendpoint halt هل كان الجهاز جاهزًا لهذا الطلب؟

ابدأ الالتقاط قبل reset أو enumeration واحتفظ بما يكفي لرؤية descriptors وSET_CONFIGURATION وSET_INTERFACE والطلب الذي يسبق العطل. فلتر endpoint ضيق قد يخفي control transfer الذي يفسر المشكلة. نفّذ حركة USB واحدة موثقة في كل تجربة، ثم غيّر عاملًا واحدًا فقط: firmware أو driver أو port أو cable أو host command أو timing.

كيف تكتب جوابًا يمكن اقتباسه؟

اكتب: «وصل الطلب المحدد، وكانت حقول setup كذا، ورد الجهاز بالحالة كذا بعد السياق كذا؛ الاختبار التالي سيغيّر عاملًا واحدًا». لا تحوّل bytes غير محفوظة بسبب retention إلى packet loss، ولا تنسب reset للcommand بسبب التقارب الزمني فقط. السبب يحتاج انتقال حالة أو تكرارًا منضبطًا.

ما الذي يجعل المقارنة صالحة؟

حافظ على VID/PID وfirmware والسرعة والطوبولوجيا وprovider والفلتر والـtrigger متساوية قدر الإمكان. قارن مراحل USB الدلالية بدل frame numbers بين usbmon وUSBPcap. احفظ start/end والنسخة والنظام ومكان التوصيل وchecksum للملف. افحص استكشاف أخطاء Bus Scope قبل التسليم.

تظل ملكية كلمات Semrush منفصلة: free USB analyzer للصفحة الرئيسية، وbest USB protocol analyzer لصفحة المقارنة، وUSB descriptor viewer لـدليل descriptor. هذه المقالة تدعم موضوعها التقني ولا تدّعي حجم بحث أو KD غير موجود.

<!-- bus-scope-localized-transaction-foundation-v1:end --><!-- multilingual-blog-closeout:start -->

إجابة مباشرة وحدود القبول

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

إجراء يبدأ من الأدلة

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

نقطة التحقق 1: جهاز USB يستمر في الانفصال: تصحيح أخطاء حلقات إعادة الضبط وأحداث الطاقة وحالات فشل التعداد

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

نقطة التحقق 2: كيفية تشخيص جهاز USB ينفصل بشكل متكرر أو يعيد ضبطه أو يعيد تعداده أو يفشل بعد تعليق باستخد

حوّل «كيفية تشخيص جهاز USB ينفصل بشكل متكرر أو يعيد ضبطه أو يعيد تعداده أو يفشل بعد تعليق باستخدام أدلة USB على مستوى الحزمة.» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 3: ما يمكن أن يعنيه "الانفصال"

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

نقطة التحقق 4: حلقة إعادة تعيين التعداد

حوّل «حلقة إعادة تعيين التعداد» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 5: مشاكل الطاقة يمكن أن تبدو كمشكلات بروتوكول

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

نقطة التحقق 6: التعليق الانتقائي وإدارة طاقة وقت التشغيل

حوّل «التعليق الانتقائي وإدارة طاقة وقت التشغيل» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 7: توقف نقطة النهاية قبل الانفصال

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

نقطة التحقق 8: حلقات إعادة تعيين الأجهزة المركبة

حوّل «حلقات إعادة تعيين الأجهزة المركبة» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

نقطة التحقق 9: أجهزة عرض النطاق الترددي العالي

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

نقطة التحقق 10: ما يجب التقاطه

حوّل «ما يجب التقاطه» إلى عبارة نجاح أو فشل يستطيع شخص آخر تكرارها. حدد ما يجب أن يظهر وما يجب أن يغيب وما إجراء الاستعادة الآمن. اترك المشروع أو الالتقاط الأصلي دون تغيير حتى تجتاز النسخة المصححة الاختبار نفسه.

مصفوفة القبول

النقطة الدليل الواجب حفظه شرط النجاح
جهاز USB يستمر في الانفصال: تصحيح أخطاء حلقات إعادة الضبط وأحداث الطاقة وحالات فشل التعداد الحالة الأولية وإجراء واحد والحالة الناتجة يستطيع مشغل ثان تكرار النتيجة
كيفية تشخيص جهاز USB ينفصل بشكل متكرر أو يعيد ضبطه أو يعيد تعداده أو يفشل بعد تعليق باستخدام أدلة USB على مستوى الحزمة. الحالة الأولية وإجراء واحد والحالة الناتجة يستطيع مشغل ثان تكرار النتيجة
ما يمكن أن يعنيه "الانفصال" الحالة الأولية وإجراء واحد والحالة الناتجة يستطيع مشغل ثان تكرار النتيجة
حلقة إعادة تعيين التعداد الحالة الأولية وإجراء واحد والحالة الناتجة يستطيع مشغل ثان تكرار النتيجة
مشاكل الطاقة يمكن أن تبدو كمشكلات بروتوكول الحالة الأولية وإجراء واحد والحالة الناتجة يستطيع مشغل ثان تكرار النتيجة
التعليق الانتقائي وإدارة طاقة وقت التشغيل الحالة الأولية وإجراء واحد والحالة الناتجة يستطيع مشغل ثان تكرار النتيجة

عزل الفشل والاستعادة والتسليم

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

افصل غياب الدليل عن دليل الغياب. قد تعني الشاشة الفارغة إدخالًا أو نطاقًا أو مرشحًا أو صلاحية أو جهازًا أو فترة أو حالة مشروع خاطئة. أثبت مسار الالتقاط أو الاستيراد قبل تفسير decoder أو المحرر أو التقرير أو التصدير.

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

أسئلة وأجوبة

ما أسرع بداية موثوقة؟

استخدم أصغر حالة ممثلة، واكتب النتيجة المتوقعة، وغيّر متغيرًا واحدًا. أثبت المسار الأساسي قبل إضافة المرشحات أو التأثيرات أو التعديلات أو الأتمتة أو مصدر أكبر.

ما الأدلة التي ينبغي حفظها؟

احتفظ بهوية الإدخال والإصدار والمنصة والإعدادات والإجراء الدقيق وأول انتقال غير متوقع والمخرج النهائي. أغلق المشروع أو الجلسة أو التقرير أو التصدير وأعد فتحه.

متى يجب تكرار الإجراء؟

كرره بعد تغيير مؤثر في التطبيق أو النظام أو driver أو firmware أو النموذج أو المصدر أو سير العمل. احتفظ بالحالة المقبولة السابقة كأساس مقارنة دون تعديل.

متى تصبح المهمة جاهزة للتسليم؟

عندما يستطيع شخص مخول آخر تحديد الإدخال وتكرار الإجراء ورؤية النتيجة نفسها وفهم القيود وفتح الأثر المحفوظ دون الاعتماد على حالة محلية غير موثقة.

أدلة مرتبطة

تغطي الصفحات التالية باللغة نفسها المراحل المجاورة من دون تغيير المالك القانوني لهذا الموضوع:

<!-- multilingual-blog-closeout:end -->