From owner-freebsd-fs@FreeBSD.ORG Sun Feb 22 23:55:02 2009 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CF071065688 for ; Sun, 22 Feb 2009 23:55:02 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from defout.telus.net (defout.telus.net [204.209.205.13]) by mx1.freebsd.org (Postfix) with ESMTP id ACF1F8FC1D for ; Sun, 22 Feb 2009 23:55:01 +0000 (UTC) (envelope-from k0802647@telus.net) Received: from priv-edmwaa05.telusplanet.net ([204.209.205.55]) by priv-edmwes51.telusplanet.net (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090222235456.MUZP1759.priv-edmwes51.telusplanet.net@priv-edmwaa05.telusplanet.net>; Sun, 22 Feb 2009 16:54:56 -0700 Received: from oliver.bc.lan (d75-157-11-254.bchsia.telus.net [75.157.11.254]) by priv-edmwaa05.telusplanet.net (BorderWare Security Platform) with ESMTP id 2C3F153630050D26; Sun, 22 Feb 2009 16:54:55 -0700 (MST) Received: from [10.111.111.112] (unknown [10.111.111.112]) by oliver.bc.lan (Postfix) with ESMTP id 587FC62AA; Sun, 22 Feb 2009 15:54:55 -0800 (PST) Message-ID: <49A1E5CE.5000501@telus.net> Date: Sun, 22 Feb 2009 15:54:54 -0800 From: Carl User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <49A10626.8060705@telus.net> <20090222110052.GH41617@deviant.kiev.zoral.com.ua> In-Reply-To: <20090222110052.GH41617@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2009 23:55:02 -0000 Kostik Belousov wrote: > Please, see > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > for instructions on how to gather the required information to diagnose > the issue. I'm not sure that it's possible for me to get into rebuilding and debugging the kernel, tar, or whatever component is at issue right now. If others can reproduce the problem, that would at least rule out a hardware problem as a starting point and hopefully garner further insight from someone more knowledgeable than I. FWIW, my system did not "stop doing useful work". Since I was using 'screen', upon the tar process hanging I switched to another window and was able to use ps, mount the procfs, try killing things, etc. Aside from being unable to kill the tar process or reboot the system, at least some other forms of work are still possible. Does this qualify as a kernel deadlock? Is there some other way to forcibly reboot a remote system from the command line when a normal shutdown command is going to totally hang the system in this way? Or perhaps some kind of watchdog that has a good chance of surviving long enough to unjam a situation like this? Carl / K0802647