|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alex Masterov 2:5002/63.100 12 Jan 2007 10:45:58
To : All
Subject : трапы в 6.1-RELEASE
--------------------------------------------------------------------------------
Был проведен апгрейд с 4.11-RELEASE до 6.1-RELEASE.
4.11 работала стабильно.
6.1 была поставлена с нуля, потом перенесены пользователи, данные и пр.
Сразу начались трапы. Иногда аптайм до трапа достигал 20 и более дней иногда
было по два трапа за сутки, но больше месяца аптайм не поднимался ни разу.
Железо менял полностью, за исключением винта. memtest гонял - проблем не
обнаружено.
make -j4 buildworld проходит нормально.
dd if=/dev/ad0 of=/dev/null bs=4k прошел без ошибок, скорость, вроде,
нормальная.
Анализ дампа:
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Unde
fined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x0
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc0822886
stack pointer = 0x28:0xcc9c0c54
frame pointer = 0x28:0xcc9c0c80
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 21 (swi0: sio)
trap number = 12
panic: page fault
Uptime: 2h44m17s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 255MB (65264 pages) 239 223 207 191 175 159 143 127 111 95 79 63 47 3
1 15
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:165
#1 0xc064e22d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:402
#2 0xc064e4c4 in panic (fmt=0xc086f9a3 "%s")
at /usr/src/sys/kern/kern_shutdown.c:558
#3 0xc0824bc4 in trap_fatal (frame=0xcc9c0c14, eva=0)
at /usr/src/sys/i386/i386/trap.c:836
#4 0xc082492b in trap_pfault (frame=0xcc9c0c14, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:744
#5 0xc0824569 in trap (frame=
{tf_fs = -1067122680, tf_es = -1038745560, tf_ds = 40, tf_edi =
-1037598996, tf_esi = 0, tf_ebp = -862188416, tf_isp = -862188480, tf_ebx = 128,
tf_edx =
128, tf_ecx = 32, tf_eax = -1037598996, tf_trapno = 12, tf_err = 0, tf_eip = -10
65211770, tf_cs = 32, tf_eflags = 590338, tf_esp = 0, tf_ss = -1037616072})
at /usr/src/sys/i386/i386/trap.c:434
#6 0xc0813aca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc0822886 in generic_bcopy () at /usr/src/sys/i386/i386/support.s:489
Previous frame inner to this frame (corrupt stack?)
Предыдущие трапы тоже были Fatal trap 12: page fault while in kernel mode.
Учитывая, что "Previous frame inner to this frame (corrupt stack?)" я правильно
понял, что от дампа нет никакого толка?
Вешать serial console не хочется, т.к. сервак боевой и нужно, чтобы он
поднимался после трапа.
Что можно предпринять?
С уважением, Alex.
--- FleetStreet 1.27.1
* Origin: Ceterum censeo Carthaginem delendam esse! (2:5002/63.100)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
