LINUX.ORG.RU

Зависание embedded linux на ARM.

 , ,


0

3

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

В данный момент занимаемся разработкой девайса следующей конфигурации:
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.

[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 ничего интересного не выдает. Работа якобы в нормальном режиме.

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



Последнее исправление: cetjs2 (всего исправлений: 1)

Иногда могут сами по себе в консоли появляться сообщения - хелп по SysRQ.

Забавно, ведь «случайно» SysRQ не прилетит с клавы - это же 3хклавишная комбинация. Значит в ядре кому-то крышу сносит и оно вызывается. Но если бы был переход по рендомному адресу, то приключений было бы больше (или просто везет попадать на SysRQ/help).

Добавь panic() в SysRQ/help - хоть стектрейс узнаешь.

Pavval ★★★★★
()

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

Зато нельзя исключить конструктивный недостаток.

tailgunner ★★★★★
()

Иногда могут сами по себе в консоли появляться сообщения - хелп по SysRQ.

Не знаю, как с этим в Linux-arm, а в Linux-Sparc SysRQ вызывается ещё и через Send-Break в консоли подключенной через последовательный порт. Может, глючит rs232-USB?

А если нет, то наоборот, можно посмотреть стэк SysRQ T после зависания. Если всё время виснет в одном драйвере - он и виноват.

alt-x ★★★★★
()
Ответ на: комментарий от tailgunner

Конструктивный недостаток возможен. Но пока пытаемся искать проблему в софтварной части.

AnMD
() автор топика
Ответ на: комментарий от alt-x

Будем смотреть на стек. Если увидим что-то интересное, отпишусь.

AnMD
() автор топика
Ответ на: комментарий от alt-x

Не знаю, как с этим в Linux-arm, а в Linux-Sparc SysRQ вызывается ещё и через Send-Break в консоли подключенной через последовательный порт.

В Linux-е на ARM-е точно также. )

Может, глючит rs232-USB?

Я тоже об этом подумал, но похоже что в данном случае что-то более серьезное.

AnMD, а конфиг ядра сами делали или взяли готовый для этого SoC?

dvl36
()

Все просто - отключить скрипты, которые вешают систему обработкой картинок, вырубить все кроме ядра и слушать его дыхание - если прерывистое, значит переконпилять. Если нормальное, значит переписать декодер камеры. Ну и сеть для отладки не нужна, если есть UART

minakov ★★★★★
()
Ответ на: комментарий от minakov

Обработкой картинок занимаются приложения,не скрипты. Без них тестили, результат тот же.

Что в вашем понимании «дыхание ядра» и как его слушать? И в случае «прерывистости» вы предлагаете просто пересобрать ядро?Без изменений?Типа компилятор ошибся?

Я вас не понимаю...возможно опыта мало.

AnMD
() автор топика
Ответ на: комментарий от Pavval

Не вопрос. Пока результатов положительных ноль. Хотим попробовать обкатать ядро с таким конфигом на мистралевском ките, чтобы отмести железные проблемы. Выходные наверное как раз уйдут.

AnMD
() автор топика
Ответ на: комментарий от dvl36

Не пробовали. Но скорее всего не заработает. Слишком много отличий.

AnMD
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.