rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 54 deletions

diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn
deleted file mode 100644
index 23f54a4a..00000000
--- a/open_issues/ext2fs_deadlock.mdwn
+++ /dev/null
@@ -1,54 +0,0 @@
-[[!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