From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 21:43: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 8513A16A4CE for ; Fri, 6 Feb 2004 21:43:09 -0800 (PST) Received: from gddsn.org.cn (mail.gddsn.org.cn [210.21.6.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 122B343D1F for ; Fri, 6 Feb 2004 21:43:08 -0800 (PST) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gw [210.21.6.34]) by gddsn.org.cn (Postfix) with ESMTP id 9037038CB53 for ; Sat, 7 Feb 2004 13:43:05 +0800 (CST) Message-ID: <40247AE9.6070805@gddsn.org.cn> Date: Sat, 07 Feb 2004 13:43:05 +0800 From: Huang wen hui User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; zh-CN; rv:1.6) Gecko/20040123 X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Processes blocked on getblk or ufs 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: Sat, 07 Feb 2004 05:43:09 -0000 Robin P. Blanchard wrote: >Ok. I just induced a getblk with installworld (again stuck in makewhatis). I >logged the ddb session below, during which I manually induced a dump. The >dump allegedly completely sucessfully; but the box never rebooted. I had to >manually (hard) reboot it. Once it came back up, savecore recorded the dump >as expected. Unfortunately, it is apparently useless (at least to me). I have >saved kernel.debug as well as vmcore for anyone who thinks they can use this. >I'm now at a loss as to how to proceed. >Thanks in advance. > > > woo, Scott's commit seem to fix this problem for me! Thanks, --hwh scottl 2004/02/06 19:26:38 PST FreeBSD src repository Modified files: sys/dev/aac aac.c Log: - Broaden the scope of locking in aac_command_thread() again to catch some edge cases in the loop. - Try to grab a command before dequeueing the bio from the bioq. The old behaviour of requeuing deferred bios to the end of the bioq is arguably wrong. This should be fixed in the future to check the bioq head without automatically dequeueing the bio. Revision Changes Path 1.83 +17 -11 src/sys/dev/aac/aac.c