From owner-freebsd-current@FreeBSD.ORG Fri Feb 13 03:21:58 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 298FE16A4CE for ; Fri, 13 Feb 2004 03:21:58 -0800 (PST) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AA8C43D2F for ; Fri, 13 Feb 2004 03:21:57 -0800 (PST) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id i1DBLrFS014660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Feb 2004 12:21:53 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.12.11/8.12.5/Submit) id i1DBLrXn014659; Fri, 13 Feb 2004 12:21:53 +0100 (CET) Date: Fri, 13 Feb 2004 12:21:53 +0100 From: Divacky Roman To: Andre Guibert de Bruet Message-ID: <20040213112153.GA14493@stud.fit.vutbr.cz> References: <20040213094957.GA8898@stud.fit.vutbr.cz> <20040213045538.I34361@alpha.siliconlandmark.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040213045538.I34361@alpha.siliconlandmark.com> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: current@freebsd.org Subject: Re: panic in 11th Feb current 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, 13 Feb 2004 11:21:58 -0000 > Source from the 11th indicates that this line number to points to a > vm_map_lock_read() call inside vm_map_lookup() which would be called on a > page fault. seems so > > stray iqr 9 > > _mtx_lock_sleep: recursed on non-recursive mutex > > kern_mutex.c:436 > > Ouch. > > > I have kernel dump which I can provide (but my kernel is not -g > > compiled) > > Run an "nm /boot/kernel/kernel |sort" and report the function names and > addresses of the functions just above and below the eip (0xc05babdc). > > Regards, is this enough? c05ba630 t vm_map_zfini c05ba660 t vm_map_zinit c05ba6e0 t vmspace_zdtor c05ba710 t vm_map_zdtor c05ba7c0 T vmspace_alloc c05ba840 T vm_init2 c05ba8e0 T vmspace_free c05ba9e0 T vmspace_exitfree c05baac0 T _vm_map_lock c05bab60 T _vm_map_unlock c05babc0 T _vm_map_lock_read c05bac50 T _vm_map_unlock_read c05bacb0 T _vm_map_trylock c05bad30 T _vm_map_trylock_read c05badb0 T _vm_map_lock_upgrade c05bae40 T _vm_map_lock_downgrade c05baec0 T vm_map_unlock_and_wait c05baf40 T vm_map_wakeup c05bafb0 T vmspace_resident_count c05bafc0 T vmspace_wired_count c05bafd0 T vm_map_create c05bb020 t _vm_map_init c05bb070 T vm_map_init