Date: Sat, 4 Dec 2004 12:49:35 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: current@freebsd.org Subject: Re: SMP FFS Part 3 Message-ID: <Pine.NEB.3.96L.1041204124738.607J-100000@fledge.watson.org> In-Reply-To: <20041203052824.K18185@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Dec 2004, Jeff Roberson wrote: > This patch removes Giant from every file related syscall. It fixes all > known bugs except for one which Peter Holm has seen after very long > periods of extreme load, and a nfs netbooting problem that I haven't yet > looked in to. I can buildworld -j3 for hours on my dual opteron without > issues. I hope to fix the remaining problems in a day or two. > > http://www.chesapeake.net/~jroberson/smpffs.diff In installed the latest patch on a box a couple of minutes ago, and began a second update of a CVS tree over NFS to an NFS-mounted directory, got this: hippy# cvs -q update -dP panic: lock (sleep mutex) Giant not locked @ kern/vfs_lookup.c:220 cpuid = 0 KDB: enter: panic [thread pid 1117 tid 100168 ] Stopped at kdb_enter+0x2c: leave db> bt No such command db> trace Tracing pid 1117 tid 100168 td 0xc2b23c00 kdb_enter(c081ddbe,100,c2b23c00,c2b23c70,c08de5a0) at kdb_enter+0x2c panic(c0821748,c0835631,c082e79d,c0825f81,dc) at panic+0x17f witness_unlock(c08de5a0,8,c0825f78,dc) at witness_unlock+0x170 _mtx_unlock_flags(c08de5a0,0,c0825f78,dc) at _mtx_unlock_flags+0x3b namei(ef1ffc30,80c2000,1000000,0,c2731bdc) at namei+0x5f0 stat(c2b23c00,ef1ffd14,2,1,212) at stat+0x4a syscall(2f,2f,2f,80c40dc,80c1402) at syscall+0x128 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x282d8747, esp = 0xbfbfe8cc, ebp = 0xbfbfeb78 --- db> show locks db> show pcpu cpuid = 0 curthread = 0xc2b23c00: pid 1117 "cvs" curpcb = 0xef1ffda0 fpcurthread = none idlethread = 0xc2281a80: pid 14 "idle: cpu0" APIC ID = 0 currentldt = 0x30 spin locks held: 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? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041204124738.607J-100000>