AnMD 0 29 августа, 2013 Опубликовано 29 августа, 2013 · Жалоба Добрый день. Необходима помощь. В данный момент занимаемся разработкой девайса следующей конфигурации: 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 ничего интересного не выдает. Работа якобы в нормальном режиме. Подскажите что может вызывать описаные симптомы. Возможно кто-то уже сталкивался с таким повдением. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 29 августа, 2013 Опубликовано 29 августа, 2013 (изменено) · Жалоба Добрый день. Необходима помощь. В данный момент занимаемся разработкой девайса следующей конфигурации: 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 ничего интересного не выдает. Работа якобы в нормальном режиме. Подскажите что может вызывать описаные симптомы. Возможно кто-то уже сталкивался с таким повдением. Перед uBoot в 64К кеш процессора загружается и запускается X-loader. В бут партишне он представлен файлом MLO. X-loader загрузит uBoot когда все настроит. Он настраивает контроллер динамической памяти: Частоту и временную диаграму. Скорее всего у вас неверно настроено. Там по умолчанию кажется 200 мегагерцовая память. Я это место хорошо знаю. Я даже писал тест. Загружешь X-loader и тестируешь хардвер. В основном память. Если найду -- пришлю Изменено 29 августа, 2013 пользователем Tarbal Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnMD 0 29 августа, 2013 Опубликовано 29 августа, 2013 · Жалоба Перед uBoot в 64К кеш процессора загружается и запускается X-loader. В бут партишне он представлен файлом MLO. X-loader загрузит uBoot когда все настроит. Он настраивает контроллер динамической памяти: Частоту и временную диаграму. Скорее всего у вас неверно настроено. Там по умолчанию кажется 200 мегагерцовая память. Я это место хорошо знаю. Я даже писал тест. Загружешь X-loader и тестируешь хардвер. В основном память. Если найду -- пришлю Все частоты, тайминги и прочее у нас вынесено в икслоадер. В данный момент работает память на 133Mhz. Все остальные параметры инициализации проверены несколько раз, это уже пройденный этап. Тесты проходят, тоже писали:) Проблема выше... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Dron_Gus 2 29 августа, 2013 Опубликовано 29 августа, 2013 · Жалоба Судя по выскакивающему Magic SysRq я бы сказал, что у Вас какая-то проблема с последоваельным портом или преобразователем USB-serial. Если его совсем отключить, устройство виснет? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 29 августа, 2013 Опубликовано 29 августа, 2013 (изменено) · Жалоба У этого процессора есть ножка, которую можно использовать как вывод разных внутренних 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 Изменено 29 августа, 2013 пользователем Tarbal Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnMD 0 30 августа, 2013 Опубликовано 30 августа, 2013 · Жалоба У этого процессора есть ножка, которую можно использовать как вывод разных внутренних 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 4 30 августа, 2013 Опубликовано 30 августа, 2013 (изменено) · Жалоба Частоты проверяли. Понижали и смотрели осциллографом. Все стабильно. Биглборда у нас нет. Но есть Mistral'евский кит с данным процом. Попробуем залить ядро на него. Отключить SysRq не проблема. Но появление сообщения скорее симптом, а не причина. Поэтому отключение SysRq не излечивает девайс, а лишь убирает симптом. Понятно. Для начала кернел не обязательно. Только рут файловую систему скопируйте. Используите ключи при копировании -arp cp -arp rootfs_source/* rootfs_target/ если без -arp , то получится неправильная копия. В результате вы будете знать в чем проблема в верхнем уровне или нижнем. Кернел возможно придется конфигурировать если вы меняли/добавляли устройства. Еще вот какая мысль: написать апликацию, которая делает дамп памяти и сравнить содержимое регистров конфигурации динамической памяти когда начинаются проблемы с исходным содержимым. Если нет ничего подобного {не удивлюсь если уже проверили :)} -- могу прислать. Изменено 30 августа, 2013 пользователем Tarbal Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psL 0 30 августа, 2013 Опубликовано 30 августа, 2013 · Жалоба Ядро обычно по-тихому не валится. Нужно включить в kernel hacking debug info. И/или отладочные сообщения в драйвере сети. Одно непонятно - вы считаете, что у вас валится только консоль, а плата при этом продолжает работать? В юзерспейсе запускается что-нибудь, кроме BusyBox и т.п.? Какое-то самописное пользовательское по? Что с потреблением памяти, если оставить консоль работать с включенным top? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnMD 0 31 августа, 2013 Опубликовано 31 августа, 2013 · Жалоба Еще вот какая мысль: написать апликацию, которая делает дамп памяти и сравнить содержимое регистров конфигурации динамической памяти когда начинаются проблемы с исходным содержимым. Если нет ничего подобного {не удивлюсь если уже проверили :)} -- могу прислать. А вот этого еще не делали. Присылайте [email protected]. Попробуем:) Ядро обычно по-тихому не валится. Нужно включить в kernel hacking debug info. И/или отладочные сообщения в драйвере сети. Одно непонятно - вы считаете, что у вас валится только консоль, а плата при этом продолжает работать? В юзерспейсе запускается что-нибудь, кроме BusyBox и т.п.? Какое-то самописное пользовательское по? Что с потреблением памяти, если оставить консоль работать с включенным top? Дебаг инфу включили. Когда валится до конца ты выдает дамп и бэктрейс. Все как положено. Я думаю у нас валится не только консоль, просто симптомы начинаются с консоли. При этом плата продолжает работать, потому что крутится ПО дергающее картинку с камеры, и вот это ПО продолжает писать в консоль через каждые 1000 картинок средний FPS(кадров в секунду). В юзерспейсе кроме бизибокса работает:около десятка самописных приложений: для получения и анализа картинки с камеры + для осуществления коммуникации через ethernet по разным протоколам. Память никто не кушает. Проверяли. Топ это тоже доказывает. Сейчас решили попробовать ядро на девайсе с микросхемами ОЗУ от другого производителя. Посмотрим что получится. Пока uptime 2-ое суток. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psL 0 31 августа, 2013 Опубликовано 31 августа, 2013 · Жалоба Дебаг инфу включили. Когда валится до конца ты выдает дамп и бэктрейс. Все как положено. Я думаю у нас валится не только консоль, просто симптомы начинаются с консоли. При этом плата продолжает работать, потому что крутится ПО дергающее картинку с камеры, и вот это ПО продолжает писать в консоль через каждые 1000 картинок средний FPS(кадров в секунду). В юзерспейсе кроме бизибокса работает:около десятка самописных приложений: для получения и анализа картинки с камеры + для осуществления коммуникации через ethernet по разным протоколам. Память никто не кушает. Проверяли. Топ это тоже доказывает. Сейчас решили попробовать ядро на девайсе с микросхемами ОЗУ от другого производителя. Посмотрим что получится. Пока uptime 2-ое суток. Консоль можно поднять через telnet. Как у вас смонтирована rootfs? В ram или на mtd? Может развернуть rootfs на nfs, и писать статистику прямо в файл, а не на консоль? Система упадет, а состояние близкое к последнему останется в nfs шаре и его м.б. проанализировать. Или при проблемах с eth увидите, что nfs через какое-то время отваливается, особенно при интенсивном обмене в файловой системе. Возможно было бы правильнее не запускать свое ПО - оставить только ось. В качестве нагрузки, например, создать два раздела tmpfs и копировать тестовый файл с одного на другой, или передавать файлы с платы/на плату по ftp, если виноват обмен по сети. В u-boot для теста памяти есть mtest. Утечки м.б. не только в юзерспейсе, но и в ядре, особенно если есть самописные модули. Можно посмотреть через kmemleak Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 9 31 августа, 2013 Опубликовано 31 августа, 2013 (изменено) · Жалоба Характерные признаки начала проблем с системой: 1)Полностью отваливается сеть. 2)Команды вводимые в консоли, выполняются только по двойному нажатию enter. 3)Выполнение некоторых комманд приводит к полному повисанию консоли(возможно и всего устройства). Например команды top. 4)Иногда могут сами по себе в консоли появляться сообщения - хелп по SysRQ. Я бы в первую очередь посмотрел 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 Изменено 31 августа, 2013 пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AnMD 0 31 августа, 2013 Опубликовано 31 августа, 2013 (изменено) · Жалоба Консоль можно поднять через 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 будем использовать. Посмотрим что даст. Спасибо. Изменено 31 августа, 2013 пользователем AnMD Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psL 0 31 августа, 2013 Опубликовано 31 августа, 2013 · Жалоба не совсем понимаю что конкретно писать в файл по nfs? перенаправить консоль в файл и отключиться от консоли, если дело в консоли, лог смотреть через nfs. Опять же с nfs будет нагрузка на eth Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 9 31 августа, 2013 Опубликовано 31 августа, 2013 (изменено) · Жалоба Тест памяти в u-boot'е говорит что все ок. Этот тест ни о чем не говорит. В первую очередь запустите тест хотя бы на сутки с нормальным тестером, например вполне приличный http://pyropus.ca/software/memtester/ поддержка его есть например в buildroot. Сейчас вы возможно ищите черную кошку в темной комнате которой там нет. Консоль можно поднять через telnet. ... Может развернуть rootfs на nfs забавные советы, учитывая что Характерные признаки начала проблем с системой: 1)Полностью отваливается сеть. Изменено 31 августа, 2013 пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 31 августа, 2013 Опубликовано 31 августа, 2013 · Жалоба послал емайл Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
