On 2010-10-26, I've been doing the following: cp -a
../tmpdir/dump*.o ./ (65 files), changed my mind, hit C-c, continued with
cp -a ../tmpdir/dump*.o ./ (to preserve timestamps), wondered why this takes
so long, hit C-c again, then found the FS deadlocked (using no CPU; but
syncfs -s -c wouldn't finish, for example). Judging from the files'
timestamps (after rebooting and fsck), I would assume that it already hung at
the second cp's time, and the deadlock thus is not due to the second C-c,
but due to the first one.

Here are backtraces for threads 1 to 8 and 10 to 535,
I didn't succeed to get any information about thread 9 (which thus would
probably be the most interesting one...) -- GDB would always hang when
accessing it, no matter whether noninvasive mode or not. (Didn't have time to
pull the information out of the process' memory manually (how to do that,
anyways?), and also didn't have time to continue with debugging GDB itself, but
this sounds like a open issue gdb...)

IRC, freenode, #hurd, 2010-10-27

<youpi> thread 8 hung on ports_begin_rpc
<youpi> that's probably where one could investigated first
<youpi> yes, a lot of threads are hung on that
<tschwinge> You mean 0x10b9488, right?
<youpi> yes

Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled GNU Free Documentation
License.