Date: Tue, 25 Jan 2005 04:30:46 -0500 (EST) From: Jeff Roberson <jroberson@chesapeake.net> To: Kris Kennaway <kris@obsecurity.org> Cc: current@freebsd.org Subject: Re: tree may not be buildable for an hour. Message-ID: <20050125043000.R18864@mail.chesapeake.net> In-Reply-To: <20050125044210.GA46896@xor.obsecurity.org> References: <20050124040646.H97135@mail.chesapeake.net> <20050125044210.GA46896@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Jan 2005, Kris Kennaway wrote: > On Mon, Jan 24, 2005 at 05:56:48AM -0500, Jeff Roberson wrote: > > That's all of it. If you wait for your cvsup mirror to catch up, you can > > try running with a smpsafe vfs by setting the debug.mpsafevfs tunable. > > This option requires mpsafevm as well. I have two known bugs that have > > only been triggered by peter holm's excellent stress suite, but none are > > known to cause problems if mpsafevfs is disabled, and none of them have > > been seen on normal systems to my knowledge. > > Still seeing this one: > What did you do to reproduce this? Is there any chance you can recompile with DEBUG_LOCKS in your kernel and fetch the file and line strings out of the lockmgr lock for me? I've never seen this one myself. > panic: lockmgr: locking against myself > cpuid = 3 > KDB: enter: panic > [thread pid 79530 tid 100360 ] > Stopped at kdb_enter+0x30: leave > db> tr > Tracing pid 79530 tid 100360 td 0xd1342000 > kdb_enter(c06f3e4a,3,c06f228b,ee4fe580,d1342000) at kdb_enter+0x30 > panic(c06f228b,0,c06f21a1,ee,d1342000) at panic+0x13e > lockmgr(dc753e98,90022,c6565450,d1342000,12b) at lockmgr+0x3cd > getdirtybuf(dc753e38,c6565450,1,1298,2) at getdirtybuf+0xf0 > softdep_sync_metadata(ee4fe6e4,0,c0706326,10d,1) at softdep_sync_metadata+0x11e > ffs_fsync(ee4fe6e4,d0a8d834,10880,ee4fe840,c062d9b7) at ffs_fsync+0x397 > VOP_FSYNC_AP(ee4fe6e4,5ff,0,600,d1875a00) at VOP_FSYNC_AP+0x76 > ffs_truncate(c6565450,600,0,880,d1875a00) at ffs_truncate+0xa67 > ufs_direnter(c6565450,c749133c,ee4fe8ec,ee4febfc,0) at ufs_direnter+0x91b > ufs_makeinode(81a4,c6565450,ee4febe8,ee4febfc,ee4fed14) at ufs_makeinode+0x4c7 > ufs_create(ee4fea64,ee4febd4,602,ee4feb20,c058c071) at ufs_create+0x37 > VOP_CREATE_AP(ee4fea64,ee4fea60,2,c06f5474,0) at VOP_CREATE_AP+0x76 > vn_open_cred(ee4febd4,ee4fecd4,1a4,d1875a00,4) at vn_open_cred+0x1cc > vn_open(ee4febd4,ee4fecd4,1a4,4,c07535d4) at vn_open+0x33 > kern_open(d1342000,8066794,0,602,1b6) at kern_open+0xca > open(d1342000,ee4fed14,c,8070000,3) at open+0x36 > syscall(2f,2f,2f,8066794,1) at syscall+0x271 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (5, FreeBSD ELF32, open), eip = 0x2811ec77, esp = 0xbfbfe23c, ebp = 0xbfbfe2d8 --- > db> > > Also, another machine panicked with mpsafevfs=0, but as is commonplace > on SMP machines it hung trying to print the panic string, so I can't > tell whether it's related to your commits or not. > > Kris >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050125043000.R18864>