Проблем с потребителски драйвер за Ethernet

Не знам дали този въпрос е уместен тук или за суперпотребител, но все пак попитайте.

Имам спомената по-долу настройка - система за настолен компютър с Linux. Към това е свързана една персонализирана платка за разработка на FPGA. В тази FPGA има реализиран и изпълняван IP адрес на Ethernet мрежова карта. Тази платка е свързана към платката за разработка на FPGA чрез USB портове-USB кабел и сериен кабел. По същество цялата тази настройка тества базираната на FPGA мрежова карта и свързаните Ethernet драйвери, реализирани на нея.

Има много приложения, които се изпълняват на хост linux компютър и изпращат данните към FPGA базирана Ethernet n/w карта, която ги приема, извършва необходимата обработка и изпраща до физическия слой, реализиран на FPGA, който след това ги изпраща през ethernet мрежа към друг възел/устройство в мрежата.

Тази настройка работи добре, дори когато множество приложения от хост компютъра изпращат данни към FPGA мрежовата карта. Като едно от приложенията използвам базиран на Linux VLC плейър (той е мултимедиен плейър), за да възпроизвеждам някои мултимедийни потоци от Linux-хоста и тези данни се изпращат до FPGA мрежовата карта. Във VLC плейъра търся (назад/напред) потока с помощта на контролите на vlc плейъра. Когато правя тази операция за търсене непрекъснато, това прави Linux хост компютъра. виси/замразява. Не работи I/O устройство, работи само рестартиране.

Сега се опитах да видя регистрационните файлове в linux host pc /var/log (dmesg), за да видя дали ще получа представа за това кой процес/приложение е причинило замразяването, но не можах да получа никаква информация от него.

  1. Как да продължа да изолирам различни компоненти (софтуер, хардуер, ), участващи в цялата тази моя настройка, за да стесня основната причина за проблема?

  2. Има ли някакъв начин да се комуникира със замразения хост на linux по някакъв начин (сериен кабел или друга връзка, за да се получат данни от него, когато увисне?

  3. Какви стъпки трябва да следвам? Как мога да разбера дали VLC приложението е проблем или драйверът на FPGA мрежовата карта е проблем, или нещо друго?

Всякакви насоки ще бъдат полезни.

Благодаря.

-AD.


linux driver ethernet
person goldenmean    schedule 17.12.2009    source източник
comment
Общата насока е, че ако пишете код, мястото му е тук. Ако конфигурирате, това принадлежи на суперпотребител.   -  person Dave Swersky    schedule 17.12.2009
comment
В настройката, за която попитах, съм написал код, т.е. FPGA базиран Ethernet фърмуер.   -  person goldenmean    schedule 17.12.2009

Отговори (2)


arrow_upward
2
arrow_downward

Споменавате, че Linux хостът е замразен. Първо бих определил дали действително е заключен в ядрото или има някакъв процес(и) в потребителското пространство, който консумира твърде много CPU.

Може ли хостът да бъде пингован (за предпочитане на интерфейс, отделен от вашата 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 ключ и да проверите състоянието на системата и да продължите от там. Разработчиците на ядрото използват този интерфейс за отстраняване на грешки в своя софтуер. Опцията CONFIG_MAGIC_SYSRQ трябва да бъде разрешена по време на компилиране на ядрото, за да се използва тази функционалност.

След емпирично стесняване на грешка до конкретен модул, printk() все още е добър ресурс.

Може също да е полезно да активирате дебъгера на ядрото (KDB) и да се свържете с него чрез сериен кабел.

person jschmier    schedule 17.12.2009

arrow_upward
1
arrow_downward

@Jscheimer: благодаря за подробните насоки относно моя проблем. След много отстраняване на грешки и някои дискусии с други системни разработчици на работното място, най-накрая открих основната причина. Има DMA периферия, която се появява в цялата тази настройка. DMA беше конфигуриран за подравнен достъп, но някъде при някакъв трансфер на данни получаваше неподравнен адрес, в резултат на това, че не проверих подравняването на буфера от мен в кода, което причиняваше увисване/замръзване. И нямаше модел за това поведение.

person goldenmean    schedule 20.12.2009