Зависание 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 не излечивает девайс, а лишь убирает симптом.

[Tarbal]

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


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



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

Понятно. Для начала кернел не обязательно. Только рут файловую систему скопируйте.
Используите ключи при копировании -arp
cp -arp rootfs_source/* rootfs_target/

если без -arp , то получится неправильная копия.

В результате вы будете знать в чем проблема в верхнем уровне или нижнем.

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


Еще вот какая мысль:
написать апликацию, которая делает дамп памяти и сравнить содержимое регистров конфигурации динамической памяти когда начинаются проблемы с исходным содержимым. Если нет ничего подобного {не удивлюсь если уже проверили } -- могу прислать.

Сообщение отредактировал Tarbal - Aug 30 2013, 11:37

[AnMD]

Еще вот какая мысль:
написать апликацию, которая делает дамп памяти и сравнить содержимое регистров конфигурации динамической памяти когда начинаются проблемы с исходным содержимым. Если нет ничего подобного {не удивлюсь если уже проверили } -- могу прислать.

А вот этого еще не делали. Присылайте cedar.lab.electro@gmail.com. Попробуем

Ядро обычно по-тихому не валится. Нужно включить в kernel hacking debug info. И/или отладочные сообщения в драйвере сети.
Одно непонятно - вы считаете, что у вас валится только консоль, а плата при этом продолжает работать?
В юзерспейсе запускается что-нибудь, кроме BusyBox и т.п.? Какое-то самописное пользовательское по?
Что с потреблением памяти, если оставить консоль работать с включенным top?

Дебаг инфу включили. Когда валится до конца ты выдает дамп и бэктрейс. Все как положено.

Я думаю у нас валится не только консоль, просто симптомы начинаются с консоли. При этом плата продолжает работать, потому что крутится ПО дергающее картинку с камеры, и вот это ПО продолжает писать в консоль через каждые 1000 картинок средний FPS(кадров в секунду).
В юзерспейсе кроме бизибокса работает:около десятка самописных приложений: для получения и анализа картинки с камеры + для осуществления коммуникации через ethernet по разным протоколам.

Память никто не кушает. Проверяли. Топ это тоже доказывает.


Сейчас решили попробовать ядро на девайсе с микросхемами ОЗУ от другого производителя. Посмотрим что получится. Пока uptime 2-ое суток.

[psL]

Дебаг инфу включили. Когда валится до конца ты выдает дамп и бэктрейс. Все как положено.

Я думаю у нас валится не только консоль, просто симптомы начинаются с консоли. При этом плата продолжает работать, потому что крутится ПО дергающее картинку с камеры, и вот это ПО продолжает писать в консоль через каждые 1000 картинок средний FPS(кадров в секунду).
В юзерспейсе кроме бизибокса работает:около десятка самописных приложений: для получения и анализа картинки с камеры + для осуществления коммуникации через ethernet по разным протоколам.

Память никто не кушает. Проверяли. Топ это тоже доказывает.

Сейчас решили попробовать ядро на девайсе с микросхемами ОЗУ от другого производителя. Посмотрим что получится. Пока uptime 2-ое суток.

Консоль можно поднять через telnet.
Как у вас смонтирована rootfs? В ram или на mtd?
Может развернуть rootfs на nfs, и писать статистику прямо в файл, а не на консоль? Система упадет, а состояние близкое к последнему останется в nfs шаре и его м.б. проанализировать. Или при проблемах с eth увидите, что nfs через какое-то время отваливается, особенно при интенсивном обмене в файловой системе.
Возможно было бы правильнее не запускать свое ПО - оставить только ось. В качестве нагрузки, например, создать два раздела tmpfs и копировать тестовый файл с одного на другой, или передавать файлы с платы/на плату по ftp, если виноват обмен по сети. В u-boot для теста памяти есть mtest.
Утечки м.б. не только в юзерспейсе, но и в ядре, особенно если есть самописные модули. Можно посмотреть через kmemleak