From owner-freebsd-hackers Wed Apr 24 11:37: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 25B8E37B41E; Wed, 24 Apr 2002 11:37:00 -0700 (PDT) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g3OIaxf88550; Wed, 24 Apr 2002 11:36:59 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 24 Apr 2002 11:36:59 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: John Baldwin Cc: hackers@FreeBSD.org Subject: RE: mutex owned stuff fallible? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > Me, too. The next time this happens, try dumping the contents of the > mutex structure from ddb. The first argument to mtx_assert() and 2nd arg > to msleep() is a pointer to the mutex, so you have the address. (The > pointer looks right since the name was right in the panic message at > least.) The first bits of the structure will be a struct lock_object > which contains 3 pointers, an int, and then 2 more pointers. The next > word will be the actual lock contents. You can use 'show pcpu' to get the > per-CPU information containing (among other things) curthread. The value > of the lock should be curthread (possibly with bits 1 or 2 set). If it is > 0x4 (MTX_UNOWNED) it means the lock was released somehow. I actually left the system in DDB, so I still have access. db> show pcpu cpuid = 0 curthread = 0xd2d02a3c: pid 24 "isp1: fc_thrd" curpcb = 0xd2d19da0 fpcurthread = none idlethread = 0xd1e4fa3c: pid 11 "idle: cpu0" currentldt = 0x28 and db> x/x 0xd2d0843c 0xd2d0843c: c035c620 db> 0xd2d08440: c030470d db> 0xd2d08444: c030470d db> 0xd2d08448: 30000 db> 0xd2d0844c: 0 db> 0xd2d08450: 0 db> 0xd2d08454: 4 Looks like you're right and the lock was freed somewhere but not locked again. I'll try your KTR stuff to try and trap what has happened. -matt > If that is the case, you can compile KTR into your kernel with lock > tracing using: > > options KTR > options KTR_COMPILE=KTR_LOCK > options KTR_MASK=KTR_LOCK > > Then when it breaks do a 'show ktr' in ddb to get a trace of the most recent > lock operations. You might want to turn on KTR_PROC as well > (s/KTR_LOCK/(KTR_LOCK|KTR_PROC)/ above) so that you see when we switch > processes so it is less confusing. This info might be useful to look at > anyways. > > Hmm, I wonder if the mutex is recursed and mtx_assert() isn't printing the > right error message? Hmm, nope. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message