From owner-freebsd-questions Thu Jun 24 14:36:37 1999 Delivered-To: freebsd-questions@freebsd.org Received: from mailgate.program-products.co.uk (samson.program-products.co.uk [212.240.242.226]) by hub.freebsd.org (Postfix) with ESMTP id BF93414EAD for ; Thu, 24 Jun 1999 14:36:08 -0700 (PDT) (envelope-from terry@program-products.co.uk) Received: by mailgate.program-products.co.uk via smap (V2.1) id xma015791; Thu, 24 Jun 99 22:35:57 +0100 To: Greg Lehey Cc: freebsd-questions@freebsd.org Subject: Re: Multiple panics in ufs_vnoperate (3.2-STABLE) References: <9906231415.AA16160@program-products.co.uk> <19990624100339.F417@freebie.lemis.com> From: Terry Glanfield Date: 24 Jun 1999 22:35:54 +0100 In-Reply-To: Greg Lehey's message of "Thu, 24 Jun 1999 10:03:40 +0930" Message-Id: Lines: 108 X-Mailer: Gnus v5.6.44/Emacs 19.34 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Greg Lehey writes: > The first thing you want to do is look at the stack frame where the > problem occurred. Do this: > > (kgdb) f 5 > (kgdb) p *ap > > This will be an iterative effort; it'll take a while to find it, but > I'd guess you have a corrupted file on disk. Shame you're in a totally different time-zone. I've done some more digging and I may have found the inode of the offending file. Could you please take a look through this for me - it's rare for me to delve into the kernel sources. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x63746572 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0220658 stack pointer = 0x10:0xc33eae5c frame pointer = 0x10:0xc33eae5c 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 = 50328 (plug-gw) interrupt mask = trap number = 12 panic: page fault (kgdb) f 6 #6 0xc0180ce8 in vn_stat (vp=0xc34dfc00, sb=0xc33eaf00, p=0xc335f260) at vnode_if.h:247 247 return (VCALL(vp, VOFFSET(vop_getattr), &a)); (kgdb) list 234,248 234 static __inline int VOP_GETATTR(vp, vap, cred, p) 235 struct vnode *vp; 236 struct vattr *vap; 237 struct ucred *cred; 238 struct proc *p; 239 { 240 struct vop_getattr_args a; 241 242 a.a_desc = VDESC(vop_getattr); 243 a.a_vp = vp; 244 a.a_vap = vap; 245 a.a_cred = cred; 246 a.a_p = p; 247 return (VCALL(vp, VOFFSET(vop_getattr), &a)); 248 } (kgdb) p *vp $1 = {v_flag = 8192, v_usecount = 1, v_writecount = 0, v_holdcnt = 1, v_lastr = 0, v_id = 506372, v_mount = 0xc0760400, v_op = 0xc075f100, v_freelist = {tqe_next = 0xc34a21c0, tqe_prev = 0xc34d78e0}, v_mntvnodes = { le_next = 0xc33868c0, le_prev = 0xc33d7ca8}, v_cleanblkhd = { tqh_first = 0xc13a23d0, tqh_last = 0xc13a23d8}, v_dirtyblkhd = { tqh_first = 0x0, tqh_last = 0xc34dfc38}, v_synclist = {le_next = 0x0, le_prev = 0x0}, v_numoutput = 0, v_type = VREG, v_un = { vu_mountedhere = 0x0, vu_socket = 0x0, vu_specinfo = 0x0, vu_fifoinfo = 0x0}, v_lease = 0x0, v_lastw = 0, v_cstart = 0, v_lasta = 0, v_clen = 0, v_maxio = 126976, v_object = 0xc34ebc38, v_interlock = { lock_data = 0}, v_vnlock = 0x0, v_tag = VT_UFS, v_data = 0xc0860000, v_cache_src = {lh_first = 0x0}, v_cache_dst = {tqh_first = 0xc08c89c0, tqh_last = 0xc08c89d0}, v_dd = 0xc34dfc00, v_ddid = 0, v_pollinfo = { vpi_lock = {lock_data = 0}, vpi_selinfo = {si_pid = 0, si_flags = 0}, vpi_events = 0, vpi_revents = 0}} Assuming that v_data is the inode... (kdb) print *(struct inode *)vp->v_data $9 = {i_lock = {lk_interlock = {lock_data = 0}, lk_flags = 0, lk_sharecount = 0, lk_waitcount = 0, lk_exclusivecount = 0, lk_prio = 8, lk_wmesg = 0xc029dc3c "inode", lk_timo = 0, lk_lockholder = -1}, i_hash = { le_next = 0x0, le_prev = 0xc086a020}, i_vnode = 0xc34dfc00, i_devvp = 0xc335cec0, i_flag = 128, i_dev = 131072, i_number = 15808, i_effnlink = 1, inode_u = {fs = 0xc077e800, e2fs = 0xc077e800}, i_dquot = { 0x0, 0x0}, i_modrev = 1500231005160124, i_lockf = 0x0, i_count = 0, i_endoff = 0, i_diroff = 0, i_offset = 0, i_ino = 0, i_reclen = 0, i_spare = {0, 0, 0, 0}, i_din = {di_mode = 33188, di_nlink = 1, di_u = { oldids = {0, 0}, inumber = 0}, di_size = 39, di_atime = 930146525, di_atimensec = 0, di_mtime = 921777770, di_mtimensec = 0, di_ctime = 921791420, di_ctimensec = 0, di_db = {68828, 0 }, di_ib = {0, 0, 0}, di_flags = 0, di_blocks = 2, di_gen = 1753976401, di_uid = 0, di_gid = 0, di_spare = {0, 0}}} .. and that i_number is the one I'm looking for... # find -x / -inum 15808 -print /usr/local/etc/resolv.conf # ls -ld /etc/resolv.conf lrwxr-xr-x 1 root wheel 26 Mar 18 21:12 /etc/resolv.conf -> /usr/local/etc/resolv.conf # cat /etc/resolv.conf domain ppsl.co.uk nameserver 127.0.0.1 # I doubt the symlink could be causing problems but I'm willing to be proved wrong. This file is obviously used on a regular basis and the fault is intermittent so corrution seems unlikely. What would you suggest as a next step? Replace the symlink with the real data and wait to see if it happens again? Any help would be much appeciated though I won't be able to get back to this until next week. Cheers, Terry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message