From owner-freebsd-hackers Wed Apr 24 9:14:54 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 F41F837B405; Wed, 24 Apr 2002 09:14:45 -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 g3OGEjf64436; Wed, 24 Apr 2002 09:14:45 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Wed, 24 Apr 2002 09:14:45 -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 On Wed, 24 Apr 2002, John Baldwin wrote: > > On 24-Apr-2002 Matthew Jacob wrote: > > > > This is a recent i386 SMP kernel: > > > > > > panic: mutex isp not owned at ../../../kern/kern_synch.c:449 > > cpuid = 0; lapic.id = 00000000 > > Debugger("panic") > > Stopped at Debugger+0x41: xorl %eax,%eax > > db> > > db> t > > Debugger(c031189a) at Debugger+0x41 > > panic(c0310ae8,c030470d,c0312018,1c1,d2d08438) at panic+0xd8 > > _mtx_assert(d2d0843c,9,c0312018,1c1,69) at _mtx_assert+0x59 > > msleep(d2d08438,d2d0843c,4c,c0301260,7d0) at msleep+0x157 > > isp_mboxcmd(d2d08400,d2d19c04,f,d07dee8,0) at isp_mboxcmd+0x19c > > isp_fw_state(d2d08400,d2d19c54,d2d08400,d2d09000,d2d08400) at > > isp_fw_state+0x2b > > isp_fclink_test(d2d08400,1e8480,d2d08400,d2d09000,d2d0843c) at > > isp_fclink_test+0x5d > > isp_control(d2d08400,4,d2d19d18) at isp_control+0x28b > > isp_kthread(d2d08400,d2d19d48,d2d02a3c,c017b25c,0) at isp_kthread+0x6d > > fork_exit(c017b25c,d2d08400,d2d19d48) at fork_exit+0x88 > > fork_trampoline() at fork_trampoline+0x37 > > Is this code that is checked into the tree? Yes. > If so I can't see where > isp_kthread() calls isp_control(). isp_fc_runstate is an inline that calls isp_control. > mtx_owned() should always work. If > we own the lock then we were the last to write to it, so the value in our > cache can't be stale (at least, not the thread value, the contested bit > could be set by another CPU, but we mask off that bit when reading the > owner, so it's value doesn't matter). If we don't own the lock, it's > value but we don't care so long as we don't get a false positive. Since > we would have to write out the unowned cookie before another lock could > grab it though, we would at least have a value that up to date, so we > wouldn't read a stale value that had us owning the lock when we didn't. This pp is hard to parse, but I think we're in agreement that this occurrence is 'inconceivable'. I am *very* puzzled. > > > Examination of the code path shows to me that this has been what it has been > > for months- isp_lock is grabbed at the top of isp_kthread- various cv_wait && > > msleeps *should* assure it's still grabbed at the point in time it calls the > > inline isp_fc_runstate which then calls isp_control...isp_mboxcmd...where > > isp_mboxcmd calls msleep with isp_lock as the (should be still > > owned) argument. > > What is the output of 'show locks' from ddb? (You need witness for it to work.) Sigh. In order to be able to compile a kernel this year I turned off witness :-( > > > WTF, O? > > > > -matt > > -- > > 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