From owner-freebsd-current@FreeBSD.ORG Fri Jul 2 11:11:01 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 E22B316A4CE for ; Fri, 2 Jul 2004 11:11:01 +0000 (GMT) Received: from ops.tamu.edu (ops.tamu.edu [165.91.250.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA17D43D2F for ; Fri, 2 Jul 2004 11:11:01 +0000 (GMT) (envelope-from nipsy@ops.tamu.edu) Received: from nipsy by ops.tamu.edu with local (Exim 4.30; FreeBSD) id 1BgLv8-0009qD-3s for freebsd-current@freebsd.org; Fri, 02 Jul 2004 06:09:30 -0500 Date: Fri, 2 Jul 2004 06:09:30 -0500 From: Mark Nipper To: freebsd-current@freebsd.org Message-ID: <20040702110930.GC27016@ops.tamu.edu> References: <20040702105532.GA27016@ops.tamu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040702105532.GA27016@ops.tamu.edu> User-Agent: Mutt/1.5.5.1i Sender: Mark Nipper Subject: Re: LOR's in VM 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, 02 Jul 2004 11:11:02 -0000 On 02 Jul 2004, Mark Nipper wrote: > > lock order reversal > > 1st 0xc0698ac0 UMA lock (UMA lock) @ > > /usr/src/sys/vm/uma_core.c:1200 > > 2nd 0xc0c31100 system map (system map) @ > > /usr/src/sys/vm/vm_map.c:2210 > > lock order reversal > > 1st 0xc95b1bdc vm object (vm object) @ > > /usr/src/sys/vm/swap_pager.c:1323 > > 2nd 0xc0697f60 swap_pager swhash (swap_pager swhash) @ > > /usr/src/sys/vm/swap_pager.c:1838 > > 3rd 0xc0c38738 vm object (vm object) @ > > /usr/src/sys/vm/uma_core.c:873 Well, I hate to do it, but I found the LOR page (doh!), and it looks like those are 007 and 001 respectively. I was hoping not though because I've had some hard freezes (power button to recover) under heavy disk access, one being when a large number of clients were hitting my Debian mirror on the machine via HTTP (Apache 1.3.x) and the other being during heavy disk access after such a crash while NFS clients were trying to ramp back up and background fsck was happening simultaneously. Those situations only occurred though without all the debugging options turned on in the kernel. Now that I have them turned on, it doesn't seem to happen anymore, the machine is just slow as sin. :) Oh well, maybe I just need to move to the latest 5.2.1 patch level. -- Mark Nipper e-contacts: Computing and Information Services nipsy@tamu.edu Texas A&M University http://ops.tamu.edu/nipsy/ College Station, TX 77843-3142 AIM/Yahoo: texasnipsy ICQ: 66971617 (979)575-3193 MSN: nipsy@tamu.edu -----BEGIN GEEK CODE BLOCK----- GG/IT d- s++:+ a- C++$ UBL+++$ P--->+++ L+++$ E--- W++ N+ o K++ w(---) O++ M V(--) PS+++(+) PE(--) Y+ PGP++(+) t 5 X R tv b+++ DI+(++) D+ G e h r++ y+(**) ------END GEEK CODE BLOCK------ ---begin random quote of the moment--- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian W. Kernighan ----end random quote of the moment----