From owner-freebsd-current@FreeBSD.ORG Fri Aug 20 18:32:09 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 7DE3016A4CE for ; Fri, 20 Aug 2004 18:32:09 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C72BE43D2D for ; Fri, 20 Aug 2004 18:32:08 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i7KIT2FX054994 for freebsd-current@FreeBSD.org.checked; (8.12.8/vak/2.1) Fri, 20 Aug 2004 22:29:02 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i7KISWfh054967; (8.12.8/vak/2.1) Fri, 20 Aug 2004 22:28:32 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4126431E.9010702@cronyx.ru> Date: Fri, 20 Aug 2004 22:29:50 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4125B172.9060303@cronyx.ru> <200408201302.26421.jhb@FreeBSD.org> In-Reply-To: <200408201302.26421.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: Robert Watson Subject: Re: Tracking down LORs 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: Fri, 20 Aug 2004 18:32:09 -0000 John Baldwin wrote: >On Friday 20 August 2004 04:08 am, Roman Kurakin wrote: > > >>Robert Watson wrote: >> >> >>>On Fri, 20 Aug 2004, Roman Kurakin wrote: >>> >>> >>>> Currently I am trying to track down a couple of LORS in my code. >>>>But it seems that I do not undestand smth or all things id realy so bad. >>>> >>>> >>>I find it's very helpful to add lock orders to the hard-coded lock order >>>table in subr_witness.c. Without hard-coded entries, WITNESS will >>>dynamically build an order based on observed lock use. This is generally >>>fine, but once in a while the "wrong" order will be used before the >>>"right" order, so the lock order warning will print for the "right" order, >>>leaving less useful debugging information. The table allows the >>>definition of partial orders, so you can specify relationships between >>>subsets of mutexes of interest. WITNESS will flesh out remaining orders >>>through dynamic discovery. >>> >>> >>I'll try to go this way, since I am in dead end. >> >> > >Note that some lock orders as also inferred via transitivity. > >For example, let's say you have three locks a, b, and c. One thread locks a >then b, so witness saves that order. A second thread locks b then c, so >witness saves that order. If a third thread tries to lock c then a, an LOR >will result. This is similar to how > is transitive, i.e. if a > b and b > >c, then a > c. > > It looks like I have smth like that. But I am get stuck with boot loader problem for now :-( I switched to that problem since that machine was the only that could work fast enough and has ISA slots. Than I get back to LOR problem and solve it, I guess I'll have to write some FAQ that will help to track down LORs. Thanks to all for replies! Now I have some ideas to move on. rik