Зависание embedded linux на ARM. Опции Подписка на тему Сообщить другу Версия для печати Скачать тему Подписка на этот форум Режимы отображения Древовидный Переключить на: Стандартный Переключить на: Линейный

[AnMD]

Добрый день. Необходима помощь.

В данный момент занимаемся разработкой девайса следующей конфигурации:
cpu: TI AM3715
ram: 2 микросхемы K4X1G163PC(по 128MB) - в данный момент одна микросхема отключена софтварно.
ethernet: 2 контроллера KSZ8851SNLI(интерфейс подключения SPI)
flash: 2 микросхемы MT29F2G(по 256MB) - в данный момент одна микросхема отключена софтварно.
также подключена камера по интерфейсу с которой получаем картинку, обрабатываем и отдаем на внешку по ethernet или кладем на флешку(по запросу).

Все это дело работает под управлением ядра linux-3.9.2.
Файловая система с набором необходимого софта собрана при помощи buildroot-2013.05.
Кросскомпилятор которым собирается ядро и весь самописный софт gcc-4.6.4.

Вся связь, дебаг и все такое осуществляется через преобразователь rs232-USB.


Проблема заключается в том что система нестабильна и переодически зависает. Тесты проводились на 22-х тестовых образцах данного устройства, поэтому неисправность одного конкретного экзепляра можно исключить. Проблема повторяется на всех устрйоствах.

Сначала грешили на связку(ethernet-SPI), но серия испытаний с отключенным ethernet'ом опровергла данные подозрения(отключали ethernet исключением процедуры инициализации в ядре).

При опросе через ethernet(выкачивание картинки, опрос состояния по протоколу modbus TCP), появление проблем происходит значительно быстрее.

Характерные признаки начала проблем с системой:
1)Полностью отваливается сеть.
2)Команды вводимые в консоли, выполняются только по двойному нажатию enter.
3)Выполнение некоторых комманд приводит к полному повисанию консоли(возможно и всего устройства). Например команды top.
4)Иногда могут сами по себе в консоли появляться сообщения - хелп по SysRQ.

CODE

[78238.108581] SysRq : HELP : loglevel(0-9) reBoot Crash show-all-locks(D) terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I)
thaw-filesystems(J) saK show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) dump-ftrace-buffer(Z)

Dmesg ничего интересного не выдает. Работа якобы в нормальном режиме.

Подскажите что может вызывать описаные симптомы. Возможно кто-то уже сталкивался с таким повдением.

[Tarbal]

У этого процессора есть ножка, которую можно использовать как вывод разных внутренних clocks. Если она подключена, то можно попробовать если частоты правильные и не меняются когда проблемы начинаются. В конфигурации выхода есть возможность поделить. Если не поделить, то частоты выше 100 мегагерц непросто смотреть осциллографом или чем другим.
Что помню там есть два выхода, второй может быть подключен к разным источникам.
Проверьте если частоты не изменяются.

Тест проделайте:
Поставьте эту же систему на Beagleboard. Там почти такой же процессор.
Ну для начала рут файл систему записать на устройство с биглбордом и попробовать те же условия.

Это даст вам информацию, что виновато верхний уровень или кернел, бутлоадер и икхлоадер.

Судя по выскакивающему Magic SysRq я бы сказал, что у Вас какая-то проблема с последоваельным портом или преобразователем USB-serial. Если его совсем отключить, устройство виснет?

Кстати да!
Можно запретить в конфигурации кернела CONFIG_MAGIC_SYSRQ и перестроить кернел.

А проверить стазу можно вот так:
echo 0 >/proc/sys/kernel/sysrq


in /proc/sys/kernel/sysrq:
0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signalling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all RT tasks

You can set the value in the file by the following command:
echo "number" >/proc/sys/kernel/sysrq


Сообщение отредактировал Tarbal - Aug 29 2013, 19:14

[AnMD]

У этого процессора есть ножка, которую можно использовать как вывод разных внутренних clocks. Если она подключена, то можно попробовать если частоты правильные и не меняются когда проблемы начинаются. В конфигурации выхода есть возможность поделить. Если не поделить, то частоты выше 100 мегагерц непросто смотреть осциллографом или чем другим.
Что помню там есть два выхода, второй может быть подключен к разным источникам.
Проверьте если частоты не изменяются.

Частоты проверяли. Понижали и смотрели осциллографом. Все стабильно.

Тест проделайте:
Поставьте эту же систему на Beagleboard. Там почти такой же процессор.
Ну для начала рут файл систему записать на устройство с биглбордом и попробовать те же условия.

Это даст вам информацию, что виновато верхний уровень или кернел, бутлоадер и икхлоадер.

Биглборда у нас нет. Но есть Mistral'евский кит с данным процом. Попробуем залить ядро на него.

Кстати да!
Можно запретить в конфигурации кернела CONFIG_MAGIC_SYSRQ и перестроить кернел.

А проверить стазу можно вот так:
echo 0 >/proc/sys/kernel/sysrq


in /proc/sys/kernel/sysrq:
0 - disable sysrq completely
1 - enable all functions of sysrq
>1 - bitmask of allowed sysrq functions (see below for detailed function
description):
2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signalling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all RT tasks

You can set the value in the file by the following command:
echo "number" >/proc/sys/kernel/sysrq

Отключить SysRq не проблема. Но появление сообщения скорее симптом, а не причина. Поэтому отключение SysRq не излечивает девайс, а лишь убирает симптом.