Date: 29 May 1997 01:57:18 -0400 From: Robert Sanders <rsanders@mindspring.net> To: current@freebsd.org Subject: Re: Boom! :-) Message-ID: <knenaqbz29.fsf@xena.mindspring.com> In-Reply-To: Doug Rabson's message of Tue, 27 May 1997 14:12:56 %2B0100 (BST) References: <l03020910afb05a09eb52@[194.32.164.2]> <Pine.BSF.3.95q.970527141015.349C-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson <dfr@nlsystems.com> writes: > This is a workaround for the lockstatus panic. A better fix will probably > have to wait until Peter is finished with poll(2). That seems to have helped with the lockstatus panic. Now I have a different problem, detailed below. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01a7d5d stack pointer = 0x10:0xf3f13f10 frame pointer = 0x10:0xf3f13f4c 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 = 4 (update) interrupt mask = trap number = 12 panic: page fault syncing disks... Fatal trap 12: page fault while in kernel mode fault virtual address = 0x10 fault code = supervisor read, page not present instruction pointer = 0x8:0xf01a7d5d stack pointer = 0x10:0xf3f13da8 frame pointer = 0x10:0xf3f13de4 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 = 4 (update) interrupt mask = trap number = 12 panic: page fault IdlePTD 23e000 current pcb at 21aa2c panic: page fault #0 boot (howto=260) at ../../kern/kern_shutdown.c:265 265 dumppcb.pcb_cr3 = rcr3(); (kgdb) bt #0 boot (howto=260) at ../../kern/kern_shutdown.c:265 #1 0xf0113042 in panic (fmt=0xf01c75ff "page fault") at ../../kern/kern_shutdown.c:393 #2 0xf01c8191 in trap_fatal (frame=0xf3f13d6c) at ../../i386/i386/trap.c:754 #3 0xf01c7c60 in trap_pfault (frame=0xf3f13d6c, usermode=0) at ../../i386/i386/trap.c:661 #4 0xf01c792f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -202293808, tf_esi = -202293816, tf_ebp = -202293788, tf_isp = -202293868, tf_ebx = -260260992, tf_edx = -266275088, tf_ecx = -260261888, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -266699427, tf_cs = 8, tf_eflags = 66118, tf_esp = -261084672, tf_ss = 0}) at ../../i386/i386/trap.c:319 #5 0xf01a7d5d in ffs_sync (mp=0xf0702a00, waitfor=2, cred=0xf04f5a80, p=0xf022ee60) at ../../ufs/ffs/ffs_vfsops.c:839 #6 0xf013408f in sync (p=0xf022ee60, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:480 #7 0xf0112c4d in boot (howto=256) at ../../kern/kern_shutdown.c:203 #8 0xf0113042 in panic (fmt=0xf01c75ff "page fault") at ../../kern/kern_shutdown.c:393 #9 0xf01c8191 in trap_fatal (frame=0xf3f13ed4) at ../../i386/i386/trap.c:754 #10 0xf01c7c60 in trap_pfault (frame=0xf3f13ed4, usermode=0) at ../../i386/i386/trap.c:661 #11 0xf01c792f in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -202293448, tf_esi = -202293456, tf_ebp = -202293428, tf_isp = -202293508, tf_ebx = -260260992, tf_edx = 2147483647, tf_ecx = -260261888, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -266699427, tf_cs = 8, tf_eflags = 66118, tf_esp = -261084672, tf_ss = 0}) at ../../i386/i386/trap.c:319 #12 0xf01a7d5d in ffs_sync (mp=0xf0702a00, waitfor=2, cred=0xf04f5a80, p=0xf073ee00) at ../../ufs/ffs/ffs_vfsops.c:839 #13 0xf013408f in sync (p=0xf073ee00, uap=0x0, retval=0x0) at ../../kern/vfs_syscalls.c:480 #14 0xf012ee8f in vfs_update () at ../../kern/vfs_bio.c:1712 #15 0xf0106ede in kproc_start (udata=0xf020ab10) at ../../kern/init_main.c:249 #16 0xf01bf37d in fork_trampoline () #17 0x63616672 in ?? () Cannot access memory at address 0x65746e6d. (kgdb) frame 12 #12 0xf01a7d5d in ffs_sync (mp=0xf0702a00, waitfor=2, cred=0xf04f5a80, p=0xf073ee00) at ../../ufs/ffs/ffs_vfsops.c:839 839 ip = VTOI(vp); 840 if (((ip->i_flag & [where VTOI(vp) is defined as ((struct inode *)(vp)->v_data)] (kgdb) p vp $1 = (struct vnode *) 0xf07cbb80 (kgdb) p *vp $3 = {v_flag = 768, v_usecount = 0, v_writecount = 0, v_holdcnt = 0, v_lastr = 0, v_id = 18797, v_mount = 0xf0702a00, v_op = 0xf0731c00, v_freelist = {tqe_next = 0xf07cba00, tqe_prev = 0xdeadb}, v_mntvnodes = { le_next = 0xf07cb800, le_prev = 0xf07b1e28}, v_cleanblkhd = { lh_first = 0x0}, v_dirtyblkhd = {lh_first = 0x0}, v_numoutput = 0, v_type = VCHR, v_un = {vu_mountedhere = 0xf04f4d50, vu_socket = 0xf04f4d50, vu_specinfo = 0xf04f4d50, vu_fifoinfo = 0xf04f4d50}, v_lease = 0x0, v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_object = 0x0, v_interlock = {lock_data = 0}, v_vnlock = 0x0, v_tag = VT_UFS, v_data = 0x0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xf07cbbf0}, v_dd = 0xf07cbb80, v_ddid = 0} Should this vnode exist without an underlying inode? I know very little about the BSD kernel, so excuse the naive question. This may simply be superstition, but these panics always follow within an update period of me killing pppd to bring down a kernel PPP connection. It does seem significant that v_type = VCHR and the problem seems to coincide with me closing a PPP session on a character device (/dev/cuaa2). Unfortunately, without knowing what inode v_data used to point to, I suppose there's no way to trace the origin on this vnode. Could this be related to this comment in ffs_vget(): /* * If this MALLOC() is performed after the getnewvnode() * it might block, leaving a vnode with a NULL v_data to be * found by ffs_sync() if a sync happens to fire right then, * which will cause a panic because ffs_sync() blindly * dereferences vp->v_data (as well it should). */ -- Robert P.S. kernel and core available on request.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?knenaqbz29.fsf>