LINUX.ORG.RU

Отладка в embedded linux


0

1

Здравствуйте! Есть embedded linux, и после изменения в voip-драйвере (обновления proslic-api) при запуске утилиты для voip-телефонии (pjsua) ядро падает следующим образом:

[CPU 0 Unable to handle kernel paging request at virtual address 00000000
, epc == 00000000, ra == 802b40b0
79Oops[#1]:
Cpu 0
$ 0   : 00000000 7f856db0 8055a7e0 00000001
$ 4   : 80f05798 7f856db0 00000000 00000000
$ 8   : 006e46cc 83f73df4 0064e260 006be044
$12   : c14e4545 00000000 00000000 00000000
$16   : 7f856d9c 7f856dbc 001408b2 00000003
$20   : 006be044 00000000 00000000 2ab2df80
$24   : 00000000 00000000
$28   : 83f70000 83f73dc8 7f856d80 802b40b0
Hi    : 00000000
Lo    : 00000000
epc   : 00000000 (null)
    Not tainted
ra    : 802b40b0 0x802b40b0
Status: 90000404    IEp
Cause : 00000008
BadVA : 00000000
PrId  : 0000dc02 (<NULL>)
Process pjsua-mips-unkn (pid: 969, threadinfo=83f70000, task=838bbc70, tls=00000
000)
Stack : 004ea3a8 838bbc70 83f73eb8 00000000 83e3ec94 83f7c80c 00000000 0000000c
        0064e260 006be044 006e46cc 00000008 00000007 83e6f460 7f856d9c 8007d574
        00000000 0000000c 90000401 801420bc 83a17d80 00030002 00000000 00000000
        80468cf0 00000001 00000002 00000004 7f856de8 8004a85c 000007d0 00000004
        53c016b0 00000000 8046788c 804b3c04 804b3c04 00000008 004003f0 83e6f460
        ...
Call Trace:[<8007d574>] 0x8007d574
[<801420bc>] 0x801420bc
[<8004a85c>] 0x8004a85c
[<8007d620>] 0x8007d620
[<8001ba44>] 0x8001ba44
[<80001c30>] 0x80001c30
[<8000040c>] 0x8000040c
[<800a0088>] 0x800a0088


Code: 00000000  00000000  00000000 <401a4000> 3c1b8059  8f7be000  001ad582  001a
d080  037ad821

Далее следует перезагрузка.

При этом расстановка отладочных сообщений показала, что падает оно ещё до того как voip начинает инициализироваться. Точнее падает на инициализации библиотеки для работы с flash-памятью. Аналогичная инициализация в других утилитах к падению ядра не приводит.

Смущает, что падение часто происходит так, что в консоль не успевает польностью вывестись очередное отладочное сообщение. Пробовал fflush(stdout), но не помогает.

Хотелось бы понять где же происходит ошибка, но Call trace к сожалению весь в циферках. Версию pjsua с отладочной информацией на устройство к сожалению поместить не представляется возможным — она 15 Мб. А addr2line не помогает.

Вопросы:

1) Если ошибка в части кода без системных вызовов (как следует из расстановки отладочных сообщений) почему это может приводить к падению ядра, а не одного приложения?

2) Если ошибка всё же в ядре, и просто что-то не успевает вывестись, как же гарантированно вывести всё, если не fflush'ом?

★★★★★

[CPU 0 Unable to handle kernel paging request at virtual address 00000000

проверяй на ноль когда указатель разименовываешь

dimon555 ★★★★★
()

А addr2line не помогает.

Что значит не помогает? Сделай objdump и найди нужный адрес руками тогда.

anonymous
()

насколько серьезными были изменения? пересобиралось ли ядро и остальные модули из одной ветки?

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

Что значит не помогает? Сделай objdump и найди нужный адрес руками тогда.

Не помогает так как нет в выводе `objdump -S` такого адреса. addr2line пишет:

$ addr2line -e ./pjsip-apps/bin/pjsua-mips-unknown-linux-gnu-no-strip 0x8007d574
??:0

Думал может это адреса из ядра. Он находит какие-то строчки, но в сумме получается call trace не возможный. Вот типа такого:

$ eu-addr2line -f -e vmlinux 0x8007d574 0x800338b4 0x8004a85c
do_vfs_ioctl
fs/ioctl.c:564
__run_timers inlined at kernel/timer.c:1203 in run_timer_softirq
kernel/timer.c:970
handle_IRQ_event
kernel/irq/handle.c:384

Но в функции __run_timers() нет вызова do_vfs_ioctl(). А значит это бред..

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

насколько серьезными были изменения?

Изменения целого модуля ядра. Была древняя версия, стала новая. Многие функции убраны, добавлены новые, т.е. изменился как API так и код отдельных функций.

пересобиралось ли ядро и остальные модули из одной ветки?

Да, пересобирал всё ядро.

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

Ну стек может быть испорчен, например. У тебя же epc == 00000000, т.е. ты прыгнул в какой-то момент на ноль. Откуда и как ты туда попал - другой вопрос.

Ядро без этого модуля нормально работает? А с загруженным модулем, но не обращаясь к нему?

anonymous
()
Ответ на: комментарий от unDEFER

не могло ли остаться хотя бы одного бинарного модуля? в зависимости от опций некоторые ядреные структуры обрастают новыми полями или наоборот избавляются от них и если есть какой либо бинарный модуль использующий старый тип структуры то поведение непредсказуемо.

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