From owner-freebsd-current@FreeBSD.ORG Tue Aug 10 16:45: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 55EE516A4CE; Tue, 10 Aug 2004 16:45:09 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3346643D46; Tue, 10 Aug 2004 16:45:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 2B0E61FF9A6; Tue, 10 Aug 2004 18:45:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 413AF1FF92F; Tue, 10 Aug 2004 18:45:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 20CDE15665; Tue, 10 Aug 2004 16:41:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1D80715329; Tue, 10 Aug 2004 16:41:43 +0000 (UTC) Date: Tue, 10 Aug 2004 16:41:43 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: "Andrew A. Leikand" cc: FreeBSD current mailing list Subject: Re: 5.2-CURRENT crashes everyday 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: Tue, 10 Aug 2004 16:45:09 -0000 On Tue, 10 Aug 2004, Robert Watson wrote: > On Tue, 10 Aug 2004, Scott Long wrote: > > > I'm pretty sure that this is a known, harmless bug. It might even have > > been fixed in the last few weeks, but I can't remember for sure. You > > can avoid the panics by removing INVARIANTS from your kernel config. > > Lock reversals don't generate a panic by default, so the hang must happen > shortly after the lock order reversal. I.e., there's a real bug here, but > it may or may not be related to the WITNESS output. > > Andrew -- if you use a serial console, are you able to use a serial break > to get into the debugger if the debugger is compiled in with serial break > support? You can find details on setting up the debugging environment in > the handbook. apart from that I remember someone with exact the same symptoms and the same report (no serial log but only this well known LOR) but I cannot remember what had been the actual problem or if it got solved. Search for this LOR in the archives of the last two months. Might help anyone who is going to look into this to get more input. > > Andrew A. Leikand wrote: > > > > > > well i have a real big problem it is the server with 5.2-current. > > > Harware is IBM eServer 345 Dual Xeon with serveRAID 6i, raid controller > > > has no support under STABLE thus i had no choice :( > > > There are apache and sendmail on the server, load averages about 0.01, > > > but it crashes everyday and i have no idea how to force it work. > > > The only messages before it goes down is > > > > > > lock order reversal > > > 1st 0xc6574738 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:1311 > > > 2nd 0xc0673ae0 swap_pager swhash (swap_pager swhash) @ /usr/src/sys/vm/swap_pager.c:1797 > > > 3rd 0xc0c43a50 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:925 > > > Stack backtrace: > > > backtrace(0,1,c064cf90,c064e0c0,c06194dc) at backtrace+0x12 > > > witness_checkorder(c0c43a50,9,c05fe7bf,39d) at witness_checkorder+0x53b > > > _mtx_lock_flags(c0c43a50,0,c05fe7bf,39d,c350b288) at _mtx_lock_flags+0x57 > > > obj_alloc(c3502dc0,1000,de086a2b,101,de086a38) at obj_alloc+0x31 > > > slab_zalloc(c3502dc0,1,c3502dc0,c3502dc0,c350b280) at slab_zalloc+0x87 > > > uma_zone_slab(c3502dc0,1,c350b288,0,c05fe7bf,79c) at uma_zone_slab+0xb0 > > > uma_zalloc_internal(c3502dc0,0,1,c350b288,0) at uma_zalloc_internal+0x29 > > > uma_zalloc_arg(c3502dc0,0,1) at uma_zalloc_arg+0x2a2 > > > swp_pager_meta_build(c6574738,5e,0,2,0) at swp_pager_meta_build+0x108 > > > swap_pager_putpages(c6574738,de086bf0,1,0,de086b60) at swap_pager_putpages+0x2a8 > > > default_pager_putpages(c6574738,de086bf0,1,0,de086b60) at default_pager_putpages+0x18 > > > vm_pageout_flush(de086bf0,1,0,c064c6e0,2ff) at vm_pageout_flush+0x112 > > > vm_pageout_clean(c2ca1f88) at vm_pageout_clean+0x2a5 > > > vm_pageout_scan(0,c0673fe0,0,c05fe55f,5a7) at vm_pageout_scan+0x543 > > > vm_pageout(0,de086d48,0,c057f0e4,0) at vm_pageout+0x2cf > > > fork_exit(c057f0e4,0,de086d48) at fork_exit+0x98 > > > fork_trampoline() at fork_trampoline+0x8 > > > --- trap 0x1, eip = 0, esp = 0xde086d7c, ebp = 0 --- > > > > > > Kernel config and dmesg are attached. > > > > > > Appreciate any comments or feedback on this. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT