Date: 18 Mar 2002 10:30:20 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Kris Kennaway <kris@obsecurity.org>, current@FreeBSD.org, fs@FreeBSD.org Subject: Re: panic: bwrite: buffer is not busy??? Message-ID: <xzpu1renryr.fsf@flood.ping.uio.no> In-Reply-To: <xzpadt6p7wl.fsf@flood.ping.uio.no> References: <20020317124958.A34008@xor.obsecurity.org> <xzpadt6r1xr.fsf@flood.ping.uio.no> <20020318061739.GB894@elvis.mu.org> <xzpvgbupdqa.fsf@flood.ping.uio.no> <20020318071623.GD894@elvis.mu.org> <xzpadt6p7wl.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
BTW, I actually ran across a related bug (or possibly the exact same)
about a week ago, but didn't post a stack trace because I thought the
panic might be a consequence of some other patches I was testing. The
kernel debugging tutorial mwlucas is preparing is based on this stack
trace, though :)
(kgdb) where
#0 dumpsys () at ../../../kern/kern_shutdown.c:505
#1 0xc0143119 in db_fncall (dummy1=0, dummy2=0, dummy3=0,
dummy4=0xe0b749a4 " \0048\200%") at ../../../ddb/db_command.c:551
#2 0xc0142f33 in db_command (last_cmdp=0xc0313724, cmd_table=0xc0313544,
aux_cmd_tablep=0xc030df2c, aux_cmd_tablep_end=0xc030df30)
at ../../../ddb/db_command.c:348
#3 0xc0142fff in db_command_loop () at ../../../ddb/db_command.c:474
#4 0xc0145393 in db_trap (type=12, code=0) at ../../../ddb/db_trap.c:72
#5 0xc02ad0f6 in kdb_trap (type=12, code=0, regs=0xe0b74af4)
at ../../../i386/i386/db_interface.c:161
#6 0xc02ba004 in trap_fatal (frame=0xe0b74af4, eva=40)
at ../../../i386/i386/trap.c:846
#7 0xc02b9d71 in trap_pfault (frame=0xe0b74af4, usermode=0, eva=40)
at ../../../i386/i386/trap.c:765
#8 0xc02b9907 in trap (frame={tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 0, tf_ebp = -524858548, tf_isp = -524858592,
tf_ebx = -525288192, tf_edx = 0, tf_ecx = 1000000000, tf_eax = 0,
tf_trapno = 12, tf_err = 0, tf_eip = -1071645917, tf_cs = 8,
tf_eflags = 66182, tf_esp = -1070136512, tf_ss = 0})
at ../../../i386/i386/trap.c:433
#9 0xc01ffb23 in vcount (vp=0xe0b0bd00) at ../../../kern/vfs_subr.c:2301
#10 0xc01a5e58 in spec_close (ap=0xe0b74b94)
at ../../../fs/specfs/spec_vnops.c:591
#11 0xc01a55f1 in spec_vnoperate (ap=0xe0b74b94)
at ../../../fs/specfs/spec_vnops.c:121
#12 0xc0207454 in vn_close (vp=0xe0b0bd00, flags=3, cred=0xc32cce00,
td=0xe0a8d360) at vnode_if.h:183
#13 0xc0207fab in vn_closefile (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/vfs_vnops.c:757
#14 0xc01b1d50 in fdrop_locked (fp=0xc3369080, td=0xe0a8d360)
at ../../../sys/file.h:230
#15 0xc01b155a in fdrop (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/kern_descrip.c:1538
#16 0xc01b152d in closef (fp=0xc3369080, td=0xe0a8d360)
at ../../../kern/kern_descrip.c:1524
#17 0xc01b114e in fdfree (td=0xe0a8d360) at ../../../kern/kern_descrip.c:1345
#18 0xc01b5173 in exit1 (td=0xe0a8d360, rv=256)
at ../../../kern/kern_exit.c:199
#19 0xc01b4ec2 in sys_exit (td=0xe0a8d360, uap=0xe0b74d20)
at ../../../kern/kern_exit.c:109
#20 0xc02ba2b7 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 135227560, tf_esi = 0, tf_ebp = -1077941020,
tf_isp = -524857996, tf_ebx = -1, tf_edx = 135044144,
tf_ecx = -1077942116, tf_eax = 1, tf_trapno = 12, tf_err = 2,
tf_eip = 134865696, tf_cs = 31, tf_eflags = 663, tf_esp = -1077941064,
tf_ss = 47}) at ../../../i386/i386/trap.c:1049
#21 0xc02ae06d in syscall_with_err_pushed ()
#22 0x80503a5 in ?? ()
#23 0x807024a in ?? ()
#24 0xbfbfffb4 in ?? ()
#25 0x807daaf in ?? ()
#26 0x807d6eb in ?? ()
#27 0x80630c1 in ?? ()
#28 0x8062fed in ?? ()
#29 0x805ea4c in ?? ()
#30 0x8065949 in ?? ()
#31 0x806544d in ?? ()
#32 0x806dc17 in ?? ()
#33 0x80616b7 in ?? ()
#34 0x80613f0 in ?? ()
#35 0x8048135 in ?? ()
(kgdb) up 9
#9 0xc01ffb23 in vcount (vp=0xe0b0bd00) at ../../../kern/vfs_subr.c:2301
2301 SLIST_FOREACH(vq, &vp->v_rdev->si_hlist, v_specnext)
(kgdb) p *vp
$1 = {v_flag = 8, v_usecount = 2, v_writecount = 1, v_holdcnt = 0,
v_id = 6985, v_mount = 0x0, v_op = 0xc2d52a00, v_freelist = {tqe_next = 0x0,
tqe_prev = 0xe083de1c}, v_nmntvnodes = {tqe_next = 0xe0b0b700,
tqe_prev = 0xe0b0c024}, v_cleanblkhd = {tqh_first = 0x0,
tqh_last = 0xe0b0bd2c}, v_dirtyblkhd = {tqh_first = 0x0,
tqh_last = 0xe0b0bd34}, v_synclist = {le_next = 0x0, le_prev = 0x0},
v_numoutput = 0, v_type = VBAD, v_un = {vu_mountedhere = 0x0,
vu_socket = 0x0, vu_spec = {vu_specinfo = 0x0, vu_specnext = {
sle_next = 0x0}}, vu_fifoinfo = 0x0}, v_lastw = 0, v_cstart = 0,
v_lasta = 0, v_clen = 0, v_object = 0x0, v_interlock = {mtx_object = {
lo_class = 0xc0335c60, lo_name = 0xc02ef5c1 "vnode interlock",
lo_flags = 196608, lo_list = {stqe_next = 0x0}, lo_witness = 0x0},
mtx_lock = 4, mtx_recurse = 0, mtx_blocked = {tqh_first = 0x0,
tqh_last = 0xe0b0bd84}, mtx_contested = {le_next = 0x0, le_prev = 0x0},
tsp = {tv_sec = 3584, tv_nsec = 101067509},
file = 0xc02ef50a "../../../kern/vfs_subr.c", line = 1726,
has_trace_time = 0}, v_lock = {lk_interlock = 0xc036e320,
lk_flags = 16777216, lk_sharecount = 0, lk_waitcount = 0,
lk_exclusivecount = 0, lk_prio = 80, lk_wmesg = 0xc02ef5d1 "vnlock",
lk_timo = 6, lk_lockholder = -1}, v_vnlock = 0x0, v_tag = VT_NON,
v_data = 0x0, v_cache_src = {lh_first = 0x0}, v_cache_dst = {
tqh_first = 0x0, tqh_last = 0xe0b0bdd8}, v_dd = 0xe0b0bd00, v_ddid = 0,
v_pollinfo = 0x0, v_vxproc = 0x0}
(kgdb) up 8
#17 0xc01b114e in fdfree (td=0xe0a8d360) at ../../../kern/kern_descrip.c:1345
warning: Source file is more recent than executable.
1345 (void) closef(*fpp, td);
(kgdb) p fpp - fdp->fd_ofiles
$2 = 2
(kgdb) up
#18 0xc01b5173 in exit1 (td=0xe0a8d360, rv=256)
at ../../../kern/kern_exit.c:199
warning: Source file is more recent than executable.
199 fdfree(td); /* XXXKSE *//* may not be the one in proc */
(note that the vnode's mutex looks a bit weird; my kernel is
instrumented to measure how long each mutex is held)
The vnode (the process's stderr) is VBAD because it's been revoked. I
don't remember the exact circumstances of the panic, but I believe I
was in single-user mode, and the process in question was a zsh I'd
left suspended, and the panic occurred as I was either rebooting or
going to single-user mode.
DES
--
Dag-Erling Smorgrav - des@ofug.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzpu1renryr.fsf>