Date: 24 Jun 1999 22:35:54 +0100 From: Terry Glanfield <terry@program-products.co.uk> To: Greg Lehey <grog@lemis.com> Cc: freebsd-questions@freebsd.org Subject: Re: Multiple panics in ufs_vnoperate (3.2-STABLE) Message-ID: <eiu8dz3gl.fsf@program-products.co.uk> In-Reply-To: Greg Lehey's message of "Thu, 24 Jun 1999 10:03:40 %2B0930" References: <9906231415.AA16160@program-products.co.uk> <19990624100339.F417@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey <grog@lemis.com> 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 <repeats 11 times>}, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eiu8dz3gl.fsf>