Зависание 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

[AnMD]

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

rootfs смонтирована как mtd. По nfs тоже работали, не совсем понимаю что конкретно писать в файл по nfs? Логи и после перезагрузки остаются на устройстве, вряд ли что-то новое увидим если будем через nfs работать.

Тестирование без своего ПО проводилось. Результат аналогичный. Если гонять голое ядро, все равно симптомы проявляются, только через больший промежуток времени. Даже если из ядра выпилить все упоминания о наличии eth контроллеров. Тест памяти в u-boot'е говорит что все ок.

Kmemleak попробуем использовать. Спасибо.

Я бы в первую очередь посмотрел

cat /proc/interrupts

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

http://events.linuxfoundation.org/slides/2...010_rostedt.pdf
https://www.kernel.org/doc/Documentation/trace/ftrace.txt
http://www.omappedia.com/wiki/Installing_and_Using_Ftrace

Счетчик прерываний вроде в пределах нормы(если сравнивать на упавшем девайся и на не упавшем).

Ftrace будем использовать. Посмотрим что даст. Спасибо.

Сообщение отредактировал AnMD - Aug 31 2013, 07:41

[psL]

не совсем понимаю что конкретно писать в файл по nfs?

перенаправить консоль в файл и отключиться от консоли, если дело в консоли, лог смотреть через nfs. Опять же с nfs будет нагрузка на eth