Hello!
I'm experiencing repeated (1-4 times a week) non-reproductable panics on
4.8-RELEASE-p13. Actually, they have begun with 4.5-RELEASE, and I hoped that
upgrade helped me.
Fatal trap 12: page fault while in kernel mode
mp_lock = 00000002; cpuid = 0; lapic.id = 03000000
fault virtual address = 0x6c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc0273145
stack pointer = 0x10:0xe7e95dc8
frame pointer = 0x10:0xe7e95de8
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 = 77770 (suexec)
interrupt mask = none <- SMP: XXX
trap number = 12
panic: page fault
mp_lock = 00000002; cpuid = 0; lapic.id = 03000000
boot() called on cpu#0
(kgdb) where
#0 0xc017f142 in dumpsys ()
#1 0xc017ef13 in boot ()
#2 0xc017f36c in poweroff_wait ()
#3 0xc0274830 in trap_fatal ()
#4 0xc02744c1 in trap_pfault ()
#5 0xc027405f in trap ()
#6 0xc0273145 in setlock ()
#7 0xc3a222ba in ?? ()
#8 0xc01ad903 in vrele ()
#9 0xc01b4507 in vn_close ()
#10 0xc01b4e47 in vn_closefile ()
#11 0xc0174a03 in fdrop ()
#12 0xc017494b in closef ()
#13 0xc0173d4d in close ()
#14 0xc0274b61 in syscall2 ()
#15 0xc026224b in Xint0x80_syscall ()
#16 0x2804e718 in ?? ()
#17 0x2804d84f in ?? ()
Panic is ALWAYS in somewhere under Xint0x80_syscall. ALWAYS @Supervisor
read"; different programs all the time.
I think it is somethiung hardware-related, but what? The box is a little aged
Intel ISP, 2 CPUs, 3 SCSI disks; correlation with disk activity is REALLY
slight.
Any ideas, what should I test? I don't get any random sig11.
--
Alex.
Try building a debug kernel to compare against your core dump. It will give
more information.
---Mike
At 04:40 PM 19/10/2003, Alex Povolotsky wrote:>Hello!
>
>I'm experiencing repeated (1-4 times a week) non-reproductable panics on
>4.8-RELEASE-p13. Actually, they have begun with 4.5-RELEASE, and I hoped
>that upgrade helped me.
>
>Fatal trap 12: page fault while in kernel mode
>mp_lock = 00000002; cpuid = 0; lapic.id = 03000000
>fault virtual address = 0x6c
>fault code = supervisor write, page not present
>instruction pointer = 0x8:0xc0273145
>stack pointer = 0x10:0xe7e95dc8
>frame pointer = 0x10:0xe7e95de8
>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 = 77770 (suexec)
>interrupt mask = none <- SMP: XXX
>trap number = 12
>panic: page fault
>mp_lock = 00000002; cpuid = 0; lapic.id = 03000000
>boot() called on cpu#0
>
>(kgdb) where
>#0 0xc017f142 in dumpsys ()
>#1 0xc017ef13 in boot ()
>#2 0xc017f36c in poweroff_wait ()
>#3 0xc0274830 in trap_fatal ()
>#4 0xc02744c1 in trap_pfault ()
>#5 0xc027405f in trap ()
>#6 0xc0273145 in setlock ()
>#7 0xc3a222ba in ?? ()
>#8 0xc01ad903 in vrele ()
>#9 0xc01b4507 in vn_close ()
>#10 0xc01b4e47 in vn_closefile ()
>#11 0xc0174a03 in fdrop ()
>#12 0xc017494b in closef ()
>#13 0xc0173d4d in close ()
>#14 0xc0274b61 in syscall2 ()
>#15 0xc026224b in Xint0x80_syscall ()
>#16 0x2804e718 in ?? ()
>#17 0x2804d84f in ?? ()
>
>Panic is ALWAYS in somewhere under Xint0x80_syscall. ALWAYS @Supervisor
>read"; different programs all the time.
>
>I think it is somethiung hardware-related, but what? The box is a little
>aged Intel ISP, 2 CPUs, 3 SCSI disks; correlation with disk activity is
>REALLY slight.
>
>Any ideas, what should I test? I don't get any random sig11.
>--
>Alex.
>_______________________________________________
>freebsd-stable@freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>To unsubscribe, send any mail to
"freebsd-stable-unsubscribe@freebsd.org"
On 20 October, 2003, at 00:40 (+0400) Alex Povolotsky <tarkhil@webmail.sub.ru> wrote:> Hello! > > I'm experiencing repeated (1-4 times a week) non-reproductable panics on 4.8-RELEASE-p13. Actually, they have begun with 4.5-RELEASE, and I hoped that upgrade helped me. > > Fatal trap 12: page fault while in kernel mode > mp_lock = 00000002; cpuid = 0; lapic.id = 03000000 > fault virtual address = 0x6cHere's another possibility. A year ago, I saw similar behavior with a brand new box on which I'd loaded 4.7-RELEASE. The problem was bad RAM, which memtest86 (www.memtest86.com) confirmed for me. I replaced the memory, and the problem hasn't recurred since. - Brian Clapper, http://www.clapper.org/bmc/