UFS2 and/or sparse file bug causing copy process to land in 'D'' state?

[Carl]

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