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

[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

Что это может быть?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[Гость]

current process = 4 (g_down)

g_down - отсоединение geom провайдера?

[Laa]

Переустановил этот винт в другую мамку и проц, и пока фря не паниковала.
Времени разбираться нет. Нужно быстро.
Странно, но предыдущая мамка и проц работали на другой ОС несколько месяцев без сбоев...

[paix]

для рабочих машин предпочтительней использовать RELEASE а не STABLE.
Рекомендую включить вам сохранение корок:

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

dumpdev="AUTO"
dumpdir="/var/crash"
savecore_flags="-v"

тогда после паника можно будет посмотреть бектрейс и четко определить проблему....Последние, увы, иногда бывают на ровном месте.

[Гость]

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

[paix]

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

да, это я действительно забыл что ядро должно быть собрано с DEBUG.
crashinfo можно запускать уже и потом, главное чтобы корка ядра сохранилась.
Но интересно узнать на счет texdump в rc.conf, в defaults/rc.conf я такого не нашел.

[Гость]

да, это я действительно забыл что ядро должно быть собрано с DEBUG.

GENERIC собирается с отладочными символами по умолчанию.

crashinfo можно запускать уже и потом, главное чтобы корка ядра сохранилась.

кроме корки должны быть еще и исходники с ней синхронизированы. Хотя я ни разу не использовал crashinfo(8), может быть и не нужно.

Но интересно узнать на счет 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 порту.

[Alex Keda]

2 гвест
а подробней - по файрваре - это как?

[Гость]

а подробней - по файрваре - это как?

см. gdb(4), секцию "Debugging a live system with a remote firewire link"
сам пробовал только по последовательному порту