Date: Sun, 22 Feb 2009 15:54:54 -0800 From: Carl <k0802647@telus.net> To: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? Message-ID: <49A1E5CE.5000501@telus.net> In-Reply-To: <20090222110052.GH41617@deviant.kiev.zoral.com.ua> References: <49A10626.8060705@telus.net> <20090222110052.GH41617@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49A1E5CE.5000501>