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

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




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

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

Перед uBoot в 64К кеш процессора загружается и запускается X-loader. В бут партишне он представлен файлом MLO. X-loader загрузит uBoot когда все настроит. Он настраивает контроллер динамической памяти: Частоту и временную диаграму. Скорее всего у вас неверно настроено. Там по умолчанию кажется 200 мегагерцовая память.
Я это место хорошо знаю. Я даже писал тест. Загружешь X-loader и тестируешь хардвер. В основном память. Если найду -- пришлю

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

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

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

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

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


Кстати да!
Можно запретить в конфигурации кернела 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

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


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



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

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

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

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

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


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

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

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



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

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

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


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

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

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

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

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




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

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

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

Этот тест ни о чем не говорит. В первую очередь запустите тест хотя бы на сутки с нормальным тестером, например вполне приличный
http://pyropus.ca/software/memtester/

поддержка его есть например в buildroot. Сейчас вы возможно ищите черную кошку в темной комнате которой там нет.



забавные советы, учитывая что

послал емайл

Кстати если в системе есть гнездо для флеш карточки, то можно с нее загружаться.
Для разработки очень удобно. TFTP + NFS конечно еще удобнее. У нас была проблема с етим процессором запустить TFTP. Там что-то с сетью в uBoot не конфигурировалось, но уже забыл детали.




Скопируйте сюда бэктрейс

Видимо, чем чаще будет падать система, тем проще обнаружить и устранить проблему.
Может быть в системе как раз с mtd плохо - что-нибудь с кешем , либо с тактированием нанда. Нанд, судя по первому сообщению, вообще отключен: откуда берутся разделы mtd - непонятно.

1. Я не очень знаком с ядрами от TI, но обычно у производителя есть буферный репозиторий ядра, где делают все фиксы, и только потом они идут в официальный репозиторий ядра. Все таки версия 3.9.2 очень свежая и возможно от производителя туда попали еще не все необходимые изменения.

2. Буфер куда пишутся сообщения по printk из ядра расположен в ОЗУ, и только потом синхронизируется с физическим носителем. Если устройство намертво зависло, то какая-то информация из буфера ядра должна остаться в ОЗУ. Для этого грузитесь в uboot и дампите все адресное пространство физической памяти на физический носитель для последующей анализа. Файл будет большой, но если его пропустить через strings, то это значительно упростит поиск.

3. Процессор греется?

4. Если есть дамп, с которым свалилось ядро, то его стоит показать.