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>