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

[Carl]

The same truncate sequence has now been tried on a second system which 
is hardware- and OS-identical. The same hanging scenario occurs on it. 
That should eliminate the possibility of a defective hard disk as the cause.

The same sequence has also now been tried on a laptop, both natively and 
in a virtual machine on top of WinXP, although both were FreeBSD 7.1 
rather than 7.0. Neither have failed so far.

Given the latest hang opportunity, "reboot -q" and "reboot -nq" were 
tried as suggested by Kevin Day. The former didn't work and itself went 
into the 'D' state permanently. The "-nq" option *did* work, but 
obviously one has to recognize it's needed before totally hanging the 
remote system. Once the tar process has hung, screen keeps working, 
which gives a chance to create/change to a new window and issue the 
reboot. New SSH connections don't work. Commands like ps and date still 
work, but commands like ls go straight into a permanent 'D' state 
themselves. Bad scene for a remote system :-(

Dimitar Vasilev wrote:
> How about a soekris board, a USB stick and a null modem cable for collecting
> data from the local box? Or a laptop with a USB to serial adapter ?

I'll take them ;-)

Sorry, Dimitar, if I was unclear. I've already got equipment connected 
to the serial console on my local machine, so capturing output is no 
problem. It's all the kernel debugging stuff I've no knowledge of.

Carl                                             / K0802647