From owner-freebsd-current@FreeBSD.ORG Sat Dec 4 13:08:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79CA116A4D1 for ; Sat, 4 Dec 2004 13:08:33 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D9143D5A for ; Sat, 4 Dec 2004 13:08:32 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iB4D6Fb4027698; Sat, 4 Dec 2004 08:06:15 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iB4D6Fv4027695; Sat, 4 Dec 2004 13:06:15 GMT (envelope-from robert@fledge.watson.org) Date: Sat, 4 Dec 2004 13:06:15 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: SMP FFS Part 3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Dec 2004 13:08:34 -0000 On Sat, 4 Dec 2004, Robert Watson wrote: > The first update of the same tree didn't cause a problem, so maybe it's > a path we hit the second time due to cached lookups/etc? A little bit more information from gdb: (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc0460cba in db_fncall (dummy1=-1067294688, dummy2=0, dummy3=-1, dummy4=0xef1ff9cc "") at ../../../ddb/db_command.c:531 #2 0xc0461050 in db_command_loop () at ../../../ddb/db_command.c:349 #3 0xc0462a7c in db_trap (type=3, code=0) at ../../../ddb/db_main.c:221 #4 0xc06263e6 in kdb_trap (type=3, code=0, tf=0xef1ffaf4) at ../../../kern/subr_kdb.c:421 #5 0xc07b420c in trap (frame= {tf_fs = -283181032, tf_es = -1067319280, tf_ds = -1065287664, tf_edi = 0, tf_esi = 1, tf_ebp = -283116748, tf_isp = -283116768, tf_ebx = -283116704, tf_edx = -1065230914, tf_ecx = -1064437184, tf_eax = -1065222375, tf_trapno = 3, tf_err = 0, tf_eip = -1067294688, tf_cs = 8, tf_eflags = 642, tf_esp = -283116716, tf_ss = -1067387953}) at ../../../i386/i386/trap.c:573 #6 0xc07a2d6a in calltrap () at ../../../i386/i386/exception.s:140 #7 0xef1f0018 in ?? () #8 0xc0620010 in blst_leaf_alloc (scan=0x0, blk=1102741364158, count=0) at ../../../kern/subr_blist.c:394 #9 0xc060f3cf in panic (fmt=0x282
) at ../../../kern/kern_shutdown.c:538 #10 0xc062f1b8 in witness_unlock (lock=0xc08de5a0, flags=8, file=0xc0825f81 "kern/vfs_lookup.c", line=220) at ../../../kern/subr_witness.c:1105 #11 0xc0607f83 in _mtx_unlock_flags (m=0xc08de5a0, opts=0, file=0xc0825f78 "../../../kern/vfs_lookup.c", line=220) at ../../../kern/kern_mutex.c:296 #12 0xc065c26c in namei (ndp=0x1) at ../../../kern/vfs_lookup.c:220 #13 0xc06686fe in stat (td=0xc2b23c00, uap=0xef1ffd14) at ../../../kern/vfs_syscalls.c:2091 #14 0xc07b4650 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135020764, tf_esi = 135009282, tf_ebp = -1077941384, tf_isp = -283116172, tf_ebx = 674566284, tf_edx = 33619715, tf_ecx = 135012361, tf_eax = 188, tf_trapno = 12, tf_err = 2, tf_eip = 674072391, tf_cs = 31, tf_eflags = 530, tf_esp = -1077942068, tf_ss = 47}) at ../../../i386/i386/trap.c:951 #15 0xc07a2dbf in Xint0x80_syscall () at ../../../i386/i386/exception.s:201 #16 0x0000002f in ?? () #44 0xc061f6ff in sched_switch (td=0x80c1402, newtd=0x2835108c, flags=Cannot access memory at address 0xbfbfeb88 ) at ../../../kern/sched_4bsd.c:865 In the stat() frame: (kgdb) inspect nd $3 = {ni_dirp = 0x80c2000
, ni_segflg = 16777216, ni_startdir = 0x0, ni_rootdir = 0xc2731bdc, ni_topdir = 0x0, ni_vp = 0xc2731bdc, ni_dvp = 0xc277a8a0, ni_pathlen = 1, ni_next = 0xc280000b "", ni_loopcnt = 0, ni_cnd = {cn_nameiop = 0, cn_flags = 2154692, cn_thread = 0xc2b23c00, cn_cred = 0xc2934280, cn_pnbuf = 0xc2800000 "../../../..", cn_nameptr = 0xc2800009 "..", cn_namelen = 2, cn_consume = 0}} Looks like cvs was looking up all theway to the root, from an NFS subdir to a UFS root. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research