Страница 1 из 1

Вчерашняя -STABLE: panic

Добавлено: 2009-06-24 11:03:00
Laa

Код: Выделить всё

Jun 24 10:50:32 mail kernel: panic: vm_page_insert: page already inserted
Jun 24 10:50:32 mail kernel: cpuid = 1
Jun 24 10:50:32 mail kernel: Uptime: 10m50s
Jun 24 10:50:32 mail kernel: Physical memory: 2038 MB
Jun 24 10:50:32 mail kernel: Dumping 172 MB:
Jun 24 10:50:32 mail kernel:
Jun 24 10:50:32 mail kernel: Fatal trap 12: page fault while in kernel mode
Jun 24 10:50:32 mail kernel: cpuid = 0; apic id = 00
Jun 24 10:50:32 mail kernel: fault virtual address      = 0x10000
Jun 24 10:50:32 mail kernel: fault code         = supervisor read, page not present
Jun 24 10:50:32 mail kernel: instruction pointer        = 0x20:0x10000
Jun 24 10:50:32 mail kernel: stack pointer              = 0x28:0xe7837234
Jun 24 10:50:32 mail kernel: frame pointer              = 0x28:0xe7837254
Jun 24 10:50:32 mail kernel: code segment               = base 0x0, limit 0xfffff, type 0x1b
Jun 24 10:50:32 mail kernel: = DPL 0, pres 1, def32 1, gran 1
Jun 24 10:50:32 mail kernel: processor eflags   = interrupt enabled, resume, IOPL = 0
Jun 24 10:50:32 mail kernel: current process            = 8113 (bsdtar)
Jun 24 10:50:32 mail kernel: trap number                = 12
Jun 24 10:50:32 mail kernel:
Jun 24 10:50:32 mail kernel:
Jun 24 10:50:32 mail kernel: Fatal trap 12: page fault while in kernel mode
Jun 24 10:50:32 mail kernel: cpuid = 1; apic id = 01
Jun 24 10:50:32 mail kernel: fault virtual address      = 0x200
Jun 24 10:50:32 mail kernel: fault code         = supervisor read, page not present
Jun 24 10:50:32 mail kernel: instruction pointer        = 0x20:0x200
Jun 24 10:50:32 mail kernel: stack pointer              = 0x28:0xe531d8f0
Jun 24 10:50:32 mail kernel: frame pointer              = 0x28:0xe531d910
Jun 24 10:50:32 mail kernel: code segment               = base 0x0, limit 0xfffff, type 0x1b
Jun 24 10:50:32 mail kernel: = DPL 0, pres 1, def32 1, gran 1
Jun 24 10:50:32 mail kernel: processor eflags   = interrupt enabled, resume, IOPL = 0
Jun 24 10:50:32 mail kernel: current process            = 4 (g_down)
Jun 24 10:50:32 mail kernel: trap number                = 12
Jun 24 10:50:32 mail kernel: panic: page fault
Jun 24 10:50:32 mail kernel: cpuid = 1
Что это может быть?

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-24 11:43:04
Гость
Laa писал(а):current process = 4 (g_down)
g_down - отсоединение geom провайдера?

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-24 13:48:56
Laa
Переустановил этот винт в другую мамку и проц, и пока фря не паниковала. :good:
Времени разбираться нет. Нужно быстро. :st:
Странно, но предыдущая мамка и проц работали на другой ОС несколько месяцев без сбоев... :sorry:

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-25 21:11:34
paix
для рабочих машин предпочтительней использовать RELEASE а не STABLE.
Рекомендую включить вам сохранение корок:

Код: Выделить всё

dumpdev="AUTO"
dumpdir="/var/crash"
savecore_flags="-v"
тогда после паника можно будет посмотреть бектрейс и четко определить проблему....Последние, увы, иногда бывают на ровном месте.

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-26 0:48:04
Гость
без сырцов и kernel.debug под рукой много не посмотришь. Лучше на всякий случай еще врубить crashinfo и/или textdump'ы в rc.conf. textdump'ы запишут вывод ddb команд в дамп сразу после паники, а crashinfo(8) извлечет уже из дампа информацию по командам kgdb.

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-26 9:46:57
paix
Гость писал(а):без сырцов и kernel.debug под рукой много не посмотришь. Лучше на всякий случай еще врубить crashinfo и/или textdump'ы в rc.conf. textdump'ы запишут вывод ddb команд в дамп сразу после паники, а crashinfo(8) извлечет уже из дампа информацию по командам kgdb.
да, это я действительно забыл что ядро должно быть собрано с DEBUG.
crashinfo можно запускать уже и потом, главное чтобы корка ядра сохранилась.
Но интересно узнать на счет texdump в rc.conf, в defaults/rc.conf я такого не нашел.

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-26 10:30:24
Гость
paix писал(а):да, это я действительно забыл что ядро должно быть собрано с DEBUG.
GENERIC собирается с отладочными символами по умолчанию.
paix писал(а):crashinfo можно запускать уже и потом, главное чтобы корка ядра сохранилась.
кроме корки должны быть еще и исходники с ней синхронизированы. Хотя я ни разу не использовал crashinfo(8), может быть и не нужно.
paix писал(а):Но интересно узнать на счет texdump в rc.conf, в defaults/rc.conf я такого не нашел.

Код: Выделить всё

ddb_enable="NO"		# Set to YES to load ddb scripts at boot.
ddb_config="/etc/ddb.conf"	# ddb(8) config file.
crashinfo_enable="YES"	# Automatically generate crash dump summary.
crashinfo_program="/usr/sbin/crashinfo"	# Script to generate crash dump summary.
ddb(8) позоволяет настроить скрипт для textdump(4)'а, кой выполняет ddb(4) во время паники или другого события из kdb.enter.* (перечислены в мане).

Я для экономии места и времени загрузки после сбоя (savecore(8) на старых тачках работает медленно) ставлю только textdump'ы. В большинстве случаев я в корку лезть с помощью kgdb(1) все равно не буду. А на случай крайней необходимости можно из kgdb(1) подключиться к gdb(4) по последовательному/firewire порту.

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-26 11:15:41
Alex Keda
2 гвест
а подробней - по файрваре - это как?

Re: Вчерашняя -STABLE: panic

Добавлено: 2009-06-26 11:58:47
Гость
lissyara писал(а):а подробней - по файрваре - это как?
см. gdb(4), секцию "Debugging a live system with a remote firewire link"
сам пробовал только по последовательному порту