Revert "rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn"

This reverts commit 95878586ec7611791f4001a4ee17abf943fae3c1.

1 files changed, 54 insertions, 0 deletions

diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn
new file mode 100644
index 00000000..23f54a4a
--- /dev/null
+++ b/open_issues/ext2fs_deadlock.mdwn
@@ -0,0 +1,54 @@
+[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="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|/fdl]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+On 2010-10-26, [[I|tschwinge]]'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.
+
+    # gdb /hurd/ext2fs
+    [...]
+    (gdb) set noninvasive on
+    (gdb) attach 177
+    [...]
+    [New Thread 177.535]
+    Reading symbols [...]
+    (gdb) info threads
+    [all the same from 177.535 down to...]
+      11 Thread 177.11  0x010e3efc in mach_msg_trap ()
+        at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+      10 Thread 177.10  0x010e3efc in mach_msg_trap ()
+        at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+    [doesn't continue with thread 9, but hangs, taking all CPU time]
+
+New GDB instance, again noninvasive, I'm able to continue.
+
+Here are backtraces for threads [[1 to 8|bt_1-8]] and [[10 to 535|bt_10-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 [[!taglink 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