مشكلة في برنامج تشغيل إيثرنت مخصص

Question

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

لقد ذكرت أدناه الإعداد - نظام Linux للكمبيوتر المكتبي.يتم توصيل لوحة تطوير FPGA مخصصة واحدة بهذا. يوجد في FPGA هذا عنوان IP لبطاقة شبكة Ethernet تم تحقيقه وتنفيذه.يتم توصيل هذه اللوحة بلوحة تطوير FPGA باستخدام منافذ USB وكابل USB والكابل التسلسلي.بشكل أساسي، يختبر هذا الإعداد بالكامل بطاقة الشبكة المستندة إلى FPGA وبرامج تشغيل الإيثرنت المرتبطة بها.

هناك العديد من التطبيقات التي تعمل على كمبيوتر Linux المضيف وترسل البيانات إلى بطاقة Ethernet n/w المستندة إلى FPGA، والتي تقبلها وتقوم بالمعالجة اللازمة وترسلها إلى الطبقة المادية المحققة على FPGA والتي ترسلها بعد ذلك عبر شبكة إيثرنت إلى عقدة/جهاز آخر على الشبكة.

يعمل هذا الإعداد بشكل جيد، حتى عندما تقوم تطبيقات متعددة من الكمبيوتر المضيف بإرسال البيانات إلى بطاقة شبكة FPGA.كأحد التطبيقات، أستخدم مشغل VLC يعتمد على Linux (وهو مشغل وسائط متعددة) لتشغيل بعض تدفقات الوسائط المتعددة من مضيف Linux ويتم إرسال تلك البيانات إلى بطاقة شبكة FPGA.في مشغل VLC، أبحث عن البث (عكس/أمام) باستخدام عناصر التحكم في مشغل VLC.عندما أفعل هذا البحث عن العملية بشكل مستمر، فإنه يجعل جهاز الكمبيوتر المضيف لينكس.شنق / تجميد.لا يعمل جهاز الإدخال/الإخراج، تعمل إعادة التشغيل فقط.

حاولت الآن رؤية السجلات الموجودة في جهاز الكمبيوتر المضيف Linux /var/log (dmesg) لمعرفة ما إذا كان لدي فكرة حول العملية/التطبيق الذي تسبب في التجميد، لكن لم أتمكن من الحصول على أي مدخلات منه.

1. كيف يمكنني المتابعة لعزل المكونات المختلفة (البرامج، الأجهزة،) المشاركة في هذا الإعداد بالكامل لتضييق نطاق السبب الجذري للمشكلة؟

2. هل هناك أي طريقة للتواصل مع مضيف Linux المجمد عبر بعض الوسائل (كبل تسلسلي أو أي اتصال آخر للحصول على أي بيانات منه عند تعليقه؟

3. ما هي الخطوات التي يجب أن أتبعها؟كيف يمكنني معرفة ما إذا كان تطبيق VLC يمثل مشكلة أو أن برنامج تشغيل بطاقة الشبكة FPGA يمثل مشكلة أم أن هناك شيئًا آخر؟

أي مؤشرات ستكون مفيدة.

شكرًا.

-إعلان.

Answer 1

لقد ذكرت أن مضيف Linux متجمد.أود أولاً تحديد ما إذا كان مغلقًا بالفعل في kernel أو إذا كانت هناك بعض عمليات (عمليات) مساحة المستخدم تستهلك الكثير من وحدة المعالجة المركزية.

هل يمكن اختبار اتصال المضيف (ويفضل أن يكون ذلك على واجهة منفصلة عن بطاقة FPGA Ethernet الخاصة بك)؟إذا استجابت، فلن يتم قفل النواة.

مشكلة في الأجهزة؟

إذا كان ذلك ممكنًا، هل يمكن تغيير الإعداد مؤقتًا لإزالة بطاقة FPGA Ethernet ثم إعادة ظهور المشكلة؟سأفعل ذلك للمساعدة في عزل المشكلات المتعلقة على وجه التحديد بالأجهزة (FPGA Ethernet).

مشكلة مساحة المستخدم (البرمجيات)؟

إذا قمت بإزالة VLC من المعادلة، فهل لا يزال بإمكانك إجراء القفل/التعليق باستخدام طريقة أخرى لإنشاء حركة مرور Ethernet؟

يمكنك محاولة إنشاء غلاف يتم تشغيله بأولوية أعلى لاسترداد البيانات عندما يبدو أن النظام معطل.ربما من خلال تشغيل أعلى هذه الصدفة ذات الأولوية العالية، يمكنك تحديد من يستخدم وحدة المعالجة المركزية بأكملها، إن وجد.يمكنك تشغيل هذا الصدفة عبر الشبكة (telnet/ssh) أو عبر محطة تسلسلية.

#include <errno.h>
#include <sched.h>
#include <stdio.h>
#include <unistd.h>

int main()
{
    struct sched_param scheduling_parameters;

    scheduling_parameters.sched_priority = 10;

    if (sched_setscheduler(getpid(), SCHED_FIFO, &scheduling_parameters) < 0) {
        printf("error is %d\n", errno);
    }

    execlp("/bin/bash", "bash",0, 0, 0, 0);

    return 0;
}

مشكلة النواة (البرمجيات)؟

يمكنك تمكين مفتاح sysrq السحري وافحص حالة النظام وانطلق من هناك.يستخدم مطورو Kernel هذه الواجهة لتصحيح أخطاء برامجهم.يجب تمكين خيار CONFIG_MAGIC_SYSRQ في وقت ترجمة kernel من أجل استخدام هذه الوظيفة.

بعد تضييق نطاق الخطأ تجريبيًا إلى وحدة معينة، لا يزال printk() مصدرًا جيدًا.

قد يكون من المفيد أيضًا تمكين مصحح أخطاء kernel (كي دي بي) والاتصال به عبر كابل تسلسلي.

Answer 2

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