Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Oct 2002 23:40:27 +0100
From:      Philipp Stutz <philipp.stutz@gmx.ch>
To:        hackers@freebsd.org
Subject:   Re: core dump from ffs_write - i think
Message-ID:  <3DC05FDB.1020607@gmx.ch>
In-Reply-To: <3DC05516.5000603@gmx.ch>
References:  <3DC05516.5000603@gmx.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
had an other core dump (looks almost the same):

IdlePTD at phsyical address 0x00354000
initial pcb at physical address 0x002c5dc0
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x0
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0257d0a
stack pointer           = 0x10:0xc4ce0c04
frame pointer           = 0x10:0xc4ce0c30
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         = 5 (syncer)
interrupt mask          = none
trap number             = 12
panic: page fault

syncing disks... 30 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
done
Uptime: 3h9m34s

dumping to dev #ad/0x20002, offset 117160068
dump ata0: resetting devices .. done
48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 
24 23 22 21 20 19 18 17 16 1
5 14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
487             if (dumping++) {
(kgdb) where
#0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
#1  0xc0169084 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:316
#2  0xc01694d1 in panic (fmt=0xc0298aac "%s") at 
/usr/src/sys/kern/kern_shutdown.c:595
#3  0xc0259570 in trap_fatal (frame=0xc4ce0bc4, eva=0) at 
/usr/src/sys/i386/i386/trap.c:974
#4  0xc025920d in trap_pfault (frame=0xc4ce0bc4, usermode=0, eva=0)
     at /usr/src/sys/i386/i386/trap.c:867
#5  0xc0258d7f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, 
tf_edi = -1042837504,
       tf_esi = 0, tf_ebp = -993129424, tf_isp = -993129488, tf_ebx = 
4096, tf_edx = -1042837504,
       tf_ecx = 1024, tf_eax = -1042837504, tf_trapno = 12, tf_err = 0, 
tf_eip = -1071284982,
       tf_cs = 8, tf_eflags = 66070, tf_esp = -993129180, tf_ss = 
-993129208})
     at /usr/src/sys/i386/i386/trap.c:466
#6  0xc0257d0a in generic_bcopy ()
#7  0xc021aabd in ffs_write (ap=0xc4ce0ccc) at 
/usr/src/sys/ufs/ufs/ufs_readwrite.c:531
#8  0xc09b8e6f in ?? ()
#9  0xc02328d6 in vnode_pager_generic_putpages (vp=0xc5074b00, 
m=0xc4ce0de4, bytecount=4096,
     flags=0, rtvals=0xc4ce0db4) at vnode_if.h:363
#10 0xc09b8cab in ?? ()
#11 0xc02326fa in vnode_pager_putpages (object=0xc505ea20, m=0xc4ce0de4, 
count=1, sync=0,
     rtvals=0xc4ce0db4) at vnode_if.h:1147
#12 0xc022f5e5 in vm_pageout_flush (mc=0xc4ce0de4, count=1, flags=0)
     at /usr/src/sys/vm/vm_pager.h:145
#13 0xc022c4d2 in vm_object_page_collect_flush (object=0xc505ea20, 
p=0xc04b4708,
     curgeneration=11141, pagerflags=0) at /usr/src/sys/vm/vm_object.c:800
#14 0xc022c0d5 in vm_object_page_clean (object=0xc505ea20, start=0, 
end=0, flags=4)
     at /usr/src/sys/vm/vm_object.c:602
#15 0xc01992ba in vfs_msync (mp=0xc091c000, flags=2) at 
/usr/src/sys/kern/vfs_subr.c:2710
#16 0xc01995cb in sync_fsync (ap=0xc4ce0f7c) at 
/usr/src/sys/kern/vfs_subr.c:2971
#17 0xc0197b47 in sched_sync () at vnode_if.h:558

Philipp Stutz wrote:

> in the last few days i had three core dumps. the machine was up for a
> few month without a problem. this is the backtrace of the third core
> dump (haven't got vmcore.X of the others):
>
> IdlePTD at phsyical address 0x00354000
> initial pcb at physical address 0x002c5dc0
> panicstr: page fault
> panic messages:
> ---
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x0
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc0257d0a
> stack pointer           = 0x10:0xc4ce0c04
> frame pointer           = 0x10:0xc4ce0c30
> 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         = 5 (syncer)
> interrupt mask          = none
> trap number             = 12
> panic: page fault
>
> syncing disks... 30 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
> done
> Uptime: 3h9m34s
>
> dumping to dev #ad/0x20002, offset 117160068
> dump ata0: resetting devices .. done
> 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25
> 24 23 22 21 20 19 18 17 16 1
> 5 14 13 12 11 10 9 8 7 6 5 4 3 2 1
> ---
> #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
> 487             if (dumping++) {
> (kgdb) where
> #0  dumpsys () at /usr/src/sys/kern/kern_shutdown.c:487
> #1  0xc0169084 in boot (howto=256) at 
> /usr/src/sys/kern/kern_shutdown.c:316
> #2  0xc01694d1 in panic (fmt=0xc0298aac "%s") at
> /usr/src/sys/kern/kern_shutdown.c:595
> #3  0xc0259570 in trap_fatal (frame=0xc4ce0bc4, eva=0) at
> /usr/src/sys/i386/i386/trap.c:974
> #4  0xc025920d in trap_pfault (frame=0xc4ce0bc4, usermode=0, eva=0)
>     at /usr/src/sys/i386/i386/trap.c:867
> #5  0xc0258d7f in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
> tf_edi = -1042837504,
>       tf_esi = 0, tf_ebp = -993129424, tf_isp = -993129488, tf_ebx =
> 4096, tf_edx = -1042837504,
>       tf_ecx = 1024, tf_eax = -1042837504, tf_trapno = 12, tf_err = 0,
> tf_eip = -1071284982,
>       tf_cs = 8, tf_eflags = 66070, tf_esp = -993129180, tf_ss =
> -993129208})
>     at /usr/src/sys/i386/i386/trap.c:466
> #6  0xc0257d0a in generic_bcopy ()
> #7  0xc021aabd in ffs_write (ap=0xc4ce0ccc) at
> /usr/src/sys/ufs/ufs/ufs_readwrite.c:531
> #8  0xc09b8e6f in ?? ()
> #9  0xc02328d6 in vnode_pager_generic_putpages (vp=0xc5074b00,
> m=0xc4ce0de4, bytecount=4096,
>     flags=0, rtvals=0xc4ce0db4) at vnode_if.h:363
> #10 0xc09b8cab in ?? ()
> #11 0xc02326fa in vnode_pager_putpages (object=0xc505ea20, m=0xc4ce0de4,
> count=1, sync=0,
>     rtvals=0xc4ce0db4) at vnode_if.h:1147
> #12 0xc022f5e5 in vm_pageout_flush (mc=0xc4ce0de4, count=1, flags=0)
>     at /usr/src/sys/vm/vm_pager.h:145
> #13 0xc022c4d2 in vm_object_page_collect_flush (object=0xc505ea20,
> p=0xc04b4708,
>     curgeneration=11141, pagerflags=0) at /usr/src/sys/vm/vm_object.c:800
> #14 0xc022c0d5 in vm_object_page_clean (object=0xc505ea20, start=0,
> end=0, flags=4)
>     at /usr/src/sys/vm/vm_object.c:602
> #15 0xc01992ba in vfs_msync (mp=0xc091c000, flags=2) at
> /usr/src/sys/kern/vfs_subr.c:2710
> #16 0xc01995cb in sync_fsync (ap=0xc4ce0f7c) at
> /usr/src/sys/kern/vfs_subr.c:2971
> #17 0xc0197b47 in sched_sync () at vnode_if.h:558
>
> $ uname -a
> FreeBSD obelix.home 4.7-STABLE FreeBSD 4.7-STABLE #0: Wed Oct 30
> 02:04:53 CET 2002     phil@asterix.
> home:/usr/obj/usr/src/sys/OBELIX  i386
>
> i had to run fsck manualy. all drives use softupdates. the kernel was
> cvsuped yesterday.
>
> phil
>
> i'm not (yet) subscribed to this list so please cc and excuse a
> non-native speaker...
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DC05FDB.1020607>