fix merge conflict

36 files changed, 996 insertions, 143 deletions

diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
new file mode 100644
index 00000000..797d540f
--- /dev/null
+++ b/open_issues/64-bit_port.mdwn
@@ -0,0 +1,36 @@
+[[!meta copyright="Copyright © 2011 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_gnumach open_issue_mig]]
+
+IRC, freenode, #hurd, 2011-10-16:
+
+    <youpi> it'd be really good to have a 64bit kernel, no need to care about
+      addressing space :)
+    <braunr> yes a 64 bits kernel would be nice
+    <braunr> i guess it wouldn't be too hard to have a special mach kernel for
+      64 bits processors, but 32 bits userland only
+    <youpi> well, it means tinkering with mig
+    <braunr> like old sparc systems :p
+    <youpi> to build the 32bit interface, not the 64bit one
+    <braunr> ah yes
+    <braunr> hm
+    <braunr> i'm not sure
+    <braunr> mig would assume a 32 bits kernel, like now
+    <youpi> and you'll have all kinds of discrepancies in vm_size_t & such
+    <braunr> yes
+    <braunr> the 64 bits type should be completely internal
+    <braunr> types*
+    <braunr> but it would be far less work than changing all the userspace bits
+      for 64 bit (ofc we'll do that some day but in the meanwhile ..)
+    <youpi> yes
+    <youpi> and it'd boost userland addrespace to 4GiB
+    <braunr> yes
+    <youpi> leaving time for a 64bit userland :)
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 64af3d00..46526641 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -13,7 +13,7 @@ License|/fdl]]."]]"""]]
 A bunch of this should also be covered in other (introductionary) material,
 like Bushnell's Hurd paper.  All this should be unfied and streamlined.
 
-IRC, freenode, #hurd, 2011-03-08
+IRC, freenode, #hurd, 2011-03-08:
 
     <foocraft> I've a question on what are the "units" in the hurd project, if
       you were to divide them into units if they aren't, and what are the
@@ -40,7 +40,7 @@ IRC, freenode, #hurd, 2011-03-08
 
 ---
 
-IRC, freenode, #hurd, 2011-03-12
+IRC, freenode, #hurd, 2011-03-12:
 
     <dEhiN> when mach first starts up, does it have some basic i/o or fs
       functionality built into it to start up the initial hurd translators?
@@ -86,3 +86,13 @@ RPC stubs.
 ---
 
 More stuff like [[hurd/IO_path]].
+
+--
+
+IRC, freenode, #hurd, 2011-10-18:
+
+    <frhodes> what happens @ boot. and which translators are started in what
+      order?
+    <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts
+      ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs
+      init. from there on, it's just standard UNIX stuff
diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
index d796bf6b..afdcfb73 100644
--- a/open_issues/benefits_of_a_native_hurd_implementation.mdwn
+++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
@@ -27,7 +27,7 @@ IRC, #hurd, August / September 2010
       runs Linux in user space (just flip the two) for the drivers
     <marcusb> ArneBab: that is what the L4 people did with the DDE
 
-([[DDE]])
+[[/DDE]].
 
     <marcusb> ArneBab: so, with these different cuts, there are different
       opportunities. on the one end, you can run Linux as normal and get some
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index b86ed607..246e819d 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -30,8 +30,8 @@ though, as explained below.
 
 # Configuration
 
-Last reviewed up to the [[Git mirror's 066f3707e988b24f8f39d01f105662a814c0979a
-(2011-10-11) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's e605e0bc9fced128199177fff775851c7e50b4e5
+(2011-10-20) sources|source_repositories/binutils]].
 
   * Globally
 
@@ -108,7 +108,7 @@ Last reviewed up to the [[Git mirror's 066f3707e988b24f8f39d01f105662a814c0979a
 # Build
 
 Here's a log of a binutils build run; this is from our [[Git repository's
-11637a710adc7baea102d0ef5975b7a92b07aea1 (2011-10-11)
+6e78bdc1d64c55962d36ef29d15f06fb2415261b (2011-10-20)
 sources|source_repositories/binutils]], run on kepler.SCHWINGE and
 coulomb.SCHWINGE.
 
diff --git a/open_issues/binutils/log_build.diff b/open_issues/binutils/log_build.diff
index 79172cf6..79946f63 100644
--- a/open_issues/binutils/log_build.diff
+++ b/open_issues/binutils/log_build.diff
@@ -1,5 +1,5 @@
---- /dev/fd/63	2011-10-11 14:23:15.275568065 +0200
-+++ /dev/fd/62	2011-10-11 14:23:15.275568065 +0200
+--- /dev/fd/63	2011-10-22 11:44:16.461445903 +0200
++++ /dev/fd/62	2011-10-22 11:44:16.461445903 +0200
 @@ -276,12 +276,12 @@
  checking for sys/sysinfo.h... yes
  checking for machine/hal_sysinfo.h... no
@@ -214,7 +214,7 @@
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
-@@ -2473,7 +2452,7 @@
+@@ -2475,7 +2454,7 @@
  checking for BSD- or MS-compatible name lister (nm)... nm
  checking the name lister (nm) interface... BSD nm
  checking whether ln -s works... yes
@@ -223,7 +223,7 @@
  checking whether the shell understands some XSI constructs... yes
  checking whether the shell understands "+="... no
  checking for ld option to reload object files... -r
-@@ -2494,7 +2473,7 @@
+@@ -2496,7 +2475,7 @@
  checking if gcc-4.6 supports -c -o file.o... (cached) yes
  checking whether the gcc-4.6 linker (ld) supports shared libraries... yes
  checking whether -lc should be explicitly linked in... no
@@ -232,7 +232,7 @@
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
-@@ -2510,7 +2489,7 @@
+@@ -2512,7 +2491,7 @@
  checking if g++-4.6 supports -c -o file.o... yes
  checking if g++-4.6 supports -c -o file.o... (cached) yes
  checking whether the g++-4.6 linker (ld) supports shared libraries... yes
@@ -241,7 +241,7 @@
  checking how to hardcode library paths into programs... immediate
  checking whether NLS is requested... yes
  checking for catalogs to be installed...  bg da es fi fr ga id ja sv tr vi zh_CN zh_TW
-@@ -2590,13 +2569,13 @@
+@@ -2592,13 +2571,13 @@
  /bin/dash ../../master/ld/../ylwrap ../../master/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d 
  updating ldgram.h
  (echo "/* This file is automatically generated.  DO NOT EDIT! */";\
@@ -257,7 +257,7 @@
  	 | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \
  	    echo "  &ld_${f}_emulation, \\"; \
  	done;\
-@@ -2710,17 +2689,11 @@
+@@ -2712,17 +2691,11 @@
  gcc-4.6 -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT plugin.o -MD -MP -MF .deps/plugin.Tpo -c -o plugin.o ../../master/ld/plugin.c
  mv -f .deps/plugin.Tpo .deps/plugin.Po
  cp ../../master/ld/emultempl/astring.sed stringify.sed
diff --git a/open_issues/binutils/log_install.diff b/open_issues/binutils/log_install.diff
index 27dff188..100ebf5c 100644
--- a/open_issues/binutils/log_install.diff
+++ b/open_issues/binutils/log_install.diff
@@ -1,5 +1,5 @@
---- /dev/fd/63	2011-10-11 14:23:22.899444227 +0200
-+++ /dev/fd/62	2011-10-11 14:23:22.903444162 +0200
+--- /dev/fd/63	2011-10-22 11:44:48.780903894 +0200
++++ /dev/fd/62	2011-10-22 11:44:48.780903894 +0200
 @@ -68,7 +68,6 @@
  libtool: install: /usr/bin/install -c .libs/libbfd.a [...]/hurd/master.build.install/lib/libbfd.a
  libtool: install: chmod 644 [...]/hurd/master.build.install/lib/libbfd.a
diff --git a/open_issues/binutils/sum.diff b/open_issues/binutils/sum.diff
index a466b82c..0c612411 100644
--- a/open_issues/binutils/sum.diff
+++ b/open_issues/binutils/sum.diff
@@ -1,9 +1,9 @@
---- open_issues/binutils/sum_linux	2011-10-11 14:23:39.000000000 +0200
-+++ open_issues/binutils/sum_hurd	2011-10-11 14:23:33.000000000 +0200
+--- open_issues/binutils/sum_linux	2011-10-22 11:49:33.000000000 +0200
++++ open_issues/binutils/sum_hurd	2011-10-22 11:23:09.000000000 +0200
 @@ -1,5 +1,5 @@
--Test Run By thomas on Tue Oct 11 14:12:56 2011
+-Test Run By thomas on Sat Oct 22 11:43:32 2011
 -Native configuration is i686-pc-linux-gnu
-+Test Run By thomas on Tue Oct 11 13:36:51 2011
++Test Run By thomas on Fri Oct 21 12:54:58 2011
 +Native configuration is i686-unknown-gnu0.3
  
  		=== binutils tests ===
@@ -12,9 +12,9 @@
  
  # of expected passes		90
  # of unsupported tests		3
--Test Run By thomas on Tue Oct 11 14:13:19 2011
+-Test Run By thomas on Sat Oct 22 11:43:59 2011
 -Native configuration is i686-pc-linux-gnu
-+Test Run By thomas on Tue Oct 11 13:38:54 2011
++Test Run By thomas on Fri Oct 21 12:56:51 2011
 +Native configuration is i686-unknown-gnu0.3
  
  		=== ld tests ===
@@ -60,20 +60,20 @@
  PASS: ELF DSO small bar (size)
  PASS: ELF DSO foo with small bar (size)
  PASS: ELF DSO big bar (size)
-@@ -939,13 +939,13 @@ Running [...]/hurd/master/ld/testsuite/l
+@@ -940,13 +940,13 @@ Running [...]/hurd/master/ld/testsuite/l
  
  		=== ld Summary ===
  
--# of expected passes		671
+-# of expected passes		672
 -# of expected failures		8
-+# of expected passes		661
++# of expected passes		662
 +# of expected failures		18
  # of untested testcases		6
- [...]/hurd/master.build/ld/ld-new 2.22.51.20111011
+ [...]/hurd/master.build/ld/ld-new 2.22.51.20111021
  
--Test Run By thomas on Tue Oct 11 14:13:02 2011
+-Test Run By thomas on Sat Oct 22 11:43:38 2011
 -Native configuration is i686-pc-linux-gnu
-+Test Run By thomas on Tue Oct 11 13:37:18 2011
++Test Run By thomas on Fri Oct 21 12:55:21 2011
 +Native configuration is i686-unknown-gnu0.3
  
  		=== gas tests ===
diff --git a/open_issues/binutils/sum_hurd b/open_issues/binutils/sum_hurd
index 7d12b17f..31f8f997 100644
--- a/open_issues/binutils/sum_hurd
+++ b/open_issues/binutils/sum_hurd
@@ -1,4 +1,4 @@
-Test Run By thomas on Tue Oct 11 13:36:51 2011
+Test Run By thomas on Fri Oct 21 12:54:58 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== binutils tests ===
@@ -122,7 +122,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ...
 
 # of expected passes		90
 # of unsupported tests		3
-Test Run By thomas on Tue Oct 11 13:38:54 2011
+Test Run By thomas on Fri Oct 21 12:56:51 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== ld tests ===
@@ -625,6 +625,7 @@ PASS: Check --gc-section/-r/-u
 PASS: --gc-sections -r without -e
 PASS: --gc-sections with note section
 PASS: --gc-sections with __start_
+PASS: --gc-sections with __gxx_personality
 PASS: --gc-sections with shared library
 Running [...]/hurd/master/ld/testsuite/ld-h8300/h8300.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-i386/i386.exp ...
@@ -939,12 +940,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ...
 
 		=== ld Summary ===
 
-# of expected passes		661
+# of expected passes		662
 # of expected failures		18
 # of untested testcases		6
-[...]/hurd/master.build/ld/ld-new 2.22.51.20111011
+[...]/hurd/master.build/ld/ld-new 2.22.51.20111021
 
-Test Run By thomas on Tue Oct 11 13:37:18 2011
+Test Run By thomas on Fri Oct 21 12:55:21 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== gas tests ===
@@ -1416,5 +1417,5 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ...
 		=== gas Summary ===
 
 # of expected passes		346
-../as-new 2.22.51.20111011
+../as-new 2.22.51.20111021
 
diff --git a/open_issues/binutils/sum_linux b/open_issues/binutils/sum_linux
index f765b983..09c11722 100644
--- a/open_issues/binutils/sum_linux
+++ b/open_issues/binutils/sum_linux
@@ -1,4 +1,4 @@
-Test Run By thomas on Tue Oct 11 14:12:56 2011
+Test Run By thomas on Sat Oct 22 11:43:32 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== binutils tests ===
@@ -122,7 +122,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ...
 
 # of expected passes		90
 # of unsupported tests		3
-Test Run By thomas on Tue Oct 11 14:13:19 2011
+Test Run By thomas on Sat Oct 22 11:43:59 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== ld tests ===
@@ -625,6 +625,7 @@ PASS: Check --gc-section/-r/-u
 PASS: --gc-sections -r without -e
 PASS: --gc-sections with note section
 PASS: --gc-sections with __start_
+PASS: --gc-sections with __gxx_personality
 PASS: --gc-sections with shared library
 Running [...]/hurd/master/ld/testsuite/ld-h8300/h8300.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-i386/i386.exp ...
@@ -939,12 +940,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ...
 
 		=== ld Summary ===
 
-# of expected passes		671
+# of expected passes		672
 # of expected failures		8
 # of untested testcases		6
-[...]/hurd/master.build/ld/ld-new 2.22.51.20111011
+[...]/hurd/master.build/ld/ld-new 2.22.51.20111021
 
-Test Run By thomas on Tue Oct 11 14:13:02 2011
+Test Run By thomas on Sat Oct 22 11:43:38 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== gas tests ===
@@ -1416,5 +1417,5 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ...
 		=== gas Summary ===
 
 # of expected passes		346
-../as-new 2.22.51.20111011
+../as-new 2.22.51.20111021
 
diff --git a/open_issues/bsd_compatibility.mdwn b/open_issues/bsd_compatibility.mdwn
new file mode 100644
index 00000000..5c916908
--- /dev/null
+++ b/open_issues/bsd_compatibility.mdwn
@@ -0,0 +1,34 @@
+[[!meta copyright="Copyright © 2011 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_documentation]]
+
+IRC, freenode, #hurd, 2011-10-12:
+
+    <pinotree> hm, why our sys/param.h #define's BSD?
+    <braunr> pinotree: because we're evil
+    <pinotree> is that correct?
+    <pinotree> (the define, not the evilness)
+    <braunr> pinotree: i think it's because the Hurd is closer to the BSD
+      interfaces, probably because of Mach (which is itself derived from
+      BSD4.2)
+    <pinotree> braunr: but mach being bsd-ish won't make the userland (glibc)
+      interfaces bsd-ish, will it?
+    <braunr> pinotree: no
+    <pinotree> braunr: so...? :)
+    <braunr> pinotree: i guesse there are bsdisms in the glibc hurd specific
+      code, possibly because of mach
+    <braunr> or they used to be bsdisms, before being standardized
+    <braunr> e.g. mmap
+    <pinotree> braunr: hrmm...
+    <antrik> braunr: the BSDisms are there on purpose... Hurd was originally
+      even meant to be binary-compatible with BSD
+    <antrik> nothing to do with Mach really
+    <braunr> antrik: ok
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index ef319a5c..9e2ec742 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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
@@ -8,4 +8,25 @@ 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]]."]]"""]]
 
-[[!meta redir=/dde]]
+[[General Information|/dde]].
+
+
+# IRC, freenode, #hurd, 2011-10-18
+
+[[!tag open_issue_hurd]]
+
+    [DDE crash, or similar]
+    <youpi> it's fake_local_irq_disable_flags(), then raw_local_irq_disable(),
+      then raw_local_irq_restore(), which *does not* release the cli_lock
+    <youpi> the "prove it" comment is (as I expected) completely wrong
+    <youpi> npnth: http://paste.debian.net/137784/
+
+[[137784]]
+
+    <youpi> could you try this patch ?
+    <youpi> (I've not even tried to build it)
+    <npnth> youpi: speaking of which, it still seems to hang :/  I'll 1) double
+      check it applied correctly and 2) get a gdb output if it did
+    <youpi> npnth: could you add printing the value of unlock_refcnt?
+    <youpi> so we can check what's happening
+    <npnth> unlock_refcnt is at 0, interesting
diff --git a/open_issues/dde/137784 b/open_issues/dde/137784
new file mode 100644
index 00000000..1529465b
--- /dev/null
+++ b/open_issues/dde/137784
@@ -0,0 +1,43 @@
+diff --git a/libdde_linux26/lib/src/arch/l4/cli_sti.c b/libdde_linux26/lib/src/arch/l4/cli_sti.c
+index 051f259..6a8c460 100644
+--- a/libdde_linux26/lib/src/arch/l4/cli_sti.c
++++ b/libdde_linux26/lib/src/arch/l4/cli_sti.c
+@@ -4,6 +4,8 @@
+ 
+ /* IRQ lock reference counter */
+ static atomic_t      _refcnt   = ATOMIC_INIT(0);
++/* Refcnt value at which unlocking the cli_lock (it's not always 0) */
++static int unlock_refcnt;
+ static ddekit_lock_t cli_lock;
+ 
+ /* Check whether IRQs are currently disabled.
+@@ -57,9 +59,6 @@ void fake_local_irq_restore(unsigned long flags)
+ /* Store the current flags state.
+  *
+  * This is done by returning the current refcnt.
+- *
+- * XXX: Up to now, flags was always 0 at this point and
+- *      I assume that this is always the case. Prove?
+  */
+ unsigned long __raw_local_save_flags(void)
+ {
+@@ -82,7 +81,7 @@ void raw_local_irq_restore(unsigned long flags)
+ {
+ 	Assert(cli_lock != NULL);
+ 	atomic_set(&_refcnt, flags);
+-	if (flags == 0)
++	if (flags == unlock_refcnt)
+ 		ddekit_lock_unlock(&cli_lock);
+ }
+ 
+@@ -95,7 +94,9 @@ void raw_local_irq_disable(void)
+ 	if (cli_lock == NULL)
+ 		ddekit_lock_init_unlocked(&cli_lock);
+ 
+-	nested_lock(cli_lock);
++	if (nested_lock(cli_lock))
++		/* Tell the corresponding restorer to release cli_lock */
++		unlock_refcnt = atomic_read(&_refcnt);
+ 	atomic_inc(&_refcnt);
+ }
+ 
diff --git a/open_issues/dev_zero_size.mdwn b/open_issues/dev_zero_size.mdwn
new file mode 100644
index 00000000..20c5147e
--- /dev/null
+++ b/open_issues/dev_zero_size.mdwn
@@ -0,0 +1,21 @@
+[[!meta copyright="Copyright © 2011 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]]
+
+IRC, freenode, #hurd, 2011-10-18:
+
+    <pinotree> i guess it is not normal for /dev/zero have a size of
+      (size_t)-1, no?
+    <pinotree> (it isn't (size_t)-1, but (long long)-1)
+
+2011-10-19:
+
+    <pinotree> see the size you get with `stat /dev/zero`
diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn
index ce50d93e..5bda0213 100644
--- a/open_issues/device_drivers_and_io_systems.mdwn
+++ b/open_issues/device_drivers_and_io_systems.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2011 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
@@ -68,7 +68,7 @@ Also see [[user-space device drivers]].
 
 # External Projects
 
-  * [[DDE]]
+  * [[/DDE]]
 
   * [Building Linux Device Drivers on
     FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html)
diff --git a/open_issues/fifo_O_RDWR.mdwn b/open_issues/fifo_O_RDWR.mdwn
new file mode 100644
index 00000000..730e5c6f
--- /dev/null
+++ b/open_issues/fifo_O_RDWR.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+[[!meta title="fifo O_RDWR"]]
+
+[[!tag open_issue_hurd]]
+
+[[!debbug 646016]]
+
+IRC, OFTC, #debian-hurd, 2011-10-19:
+
+    <tschwinge> pinotree: Nice!  And that open(FIFO, O_RDWR) hanging issue may
+      warrant investigation on the Hurd side, too -- if the other systems
+      behave differently, we should probably have convincing reasons for our
+      behavior.
+    <pinotree> i gue somebody working on hurd never cared about that case - i
+      guess it falls back to one of O_RDONLY or O_WRONLY
+    <pinotree> *guess
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index be262261..d3f88673 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -40,12 +40,12 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
         `t/dup3`: hidden def.  ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why
         not for dup3, too?  Because it is a syscall (that is always inlined)?
 
-  * t/init-first.c
+  * `t/init-first.c`
 
-    Have to revert 53b56b1101fc9bb4f295f23f54e7e19f8da8da16 to keep it working
-    with GCC 4.4.  Figure out what's going on.  Also see [[glibc_init_first]].
-
-    There is a `RETURN_ADDRESS` macro in glibc.
+    Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]]
+    or [[!message-id "87mxe4kwws.fsf@gnu.org"]].  Close [[!GNU_Savannah_bug
+    17647]].  Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]]
+    (part of Ludo's patch; the part that is not harmful to GCC 4.4).
 
   * `t/kernel-features.h_includes`
 
@@ -59,6 +59,8 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
 
       * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed.
 
+  * [[t/tls-threadvar]]
+
   * t/verify.h
 
     People didn't like this too much.
@@ -192,8 +194,6 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
         Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
         14d96785125abee5e9a49a1c3037f35a581750bd.
 
-  * Building with GCC 4.5, 4.6, trunk will cause different kinds of faults.
-
   * Create `t/cleanup_kernel-features.h`.
 
   * Add tests from Linux kernel commit messages for `t/dup3` et al.
@@ -371,7 +371,7 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
 # Build
 
 Here's a log of a glibc build run; this is from our [[Git repository's
-8cb1875ef1e3211ec133d8eea328dbe59538c2a7 (2011-10-11)
+0abded0927c62f02399658395837917548d5e281 (2011-10-14)
 sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -383,7 +383,7 @@ sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
 This takes up around 400 MiB and needs roughly 120 min on coulomb.SCHWINGE.
 
 <!--
-    $ (make install_root=/INVALID && touch .go-check) 2>&1 | tee log_build_ && test -f .go-check && make -k install_root=/INVALID check 2>&1 | tee log_check
+    $ (make install_root=/INVALID && touch .go-check) 2>&1 | tee log_build_ && test -f .go-check && make -k install_root=/INVALID check TIMEOUTFACTOR=100 2>&1 | tee log_check
     $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do ~/tmp/gcc/git/contrib/compare-debug --preserve ../Roger_Whittaker.build-gcc-4.4-486.O/"$f" "$f"; done 2>&1 | less 
     $ while read f; do (readelf -a "$f" && objdump -xDrtw "$f") > N && (cd ../Roger_Whittaker.build-gcc-4.4-486.O/ && readelf -a "$f" && objdump -xDrtw "$f") > O && diff -u O N | less; done
     $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do readelf -h "$f" | grep OS/ABI | (read a b && [ x"$b" != x'UNIX - System V' ] && echo "### $f: $b"); done
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
index ce6ba9d2..331632f3 100644
--- a/open_issues/glibc/debian.mdwn
+++ b/open_issues/glibc/debian.mdwn
@@ -37,10 +37,28 @@ fail.  (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for
 example.)  Why is this special handling only done for `xen`, but not for
 `i686`?
 
+> Samuel: Historically because it's done that way in linux-i386. I don't know
+> the real reason.
+
 Do `export LC_ALL=C` before building, otherwise the testsuite/make error
 messages will be different from those stored in the
-`debian/testsuite-checking/expected-results-*` files.
+`debian/testsuite-checking/expected-results-*` files, resulting in a spurious
+build failure.
+
+Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`
+to build (or `build` instead of `build-arch` to build the arch-independent
+stuff, too).  Can interrupt with `C-c` during locale stuff or testsuite if only
+interested in the build tree.
+
+Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2
+[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the
+architecture-dependent ones.
+
+The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules
+EGLIBC_PASSES=libc' -nc -b -uc`.  `-nc` will prevent the *clean step* which
+would first try to un-patch, which may conflict if you have done any edits
+apter applying patches.
 
-Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`.
-Can stop with `C-c` during locale stuff or testsuite if only interested in the
-build tree.
+If the Debian symbol versioning file is not up to date and the build of Debian
+packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the
+environment \`\`helps''; see `man dpkg-gensymbols`.
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
new file mode 100644
index 00000000..f6a81590
--- /dev/null
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -0,0 +1,24 @@
+[[!meta copyright="Copyright © 2011 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_glibc open_issue_libpthread]]
+
+IRC, freenode, #hurd, 2011-10-23:
+
+    <tschwinge> youpi: If we want to replace threadvars with TLS, there is one
+      problem: the threadvars interface is publically exported:
+      /usr/include/hurd/threadvar.h.
+    <tschwinge> youpi: But I am somewhat inclined to say that the only user of
+      this is libthreads/libpthread.  Do you think differently?
+    <youpi> tschwinge: that's very probable
+    <youpi> so I think we can just drop it
+    <youpi> (people should use TLS anyway)
+
+[[libpthread_set_stack_size]].
diff --git a/open_issues/glibc_init_first.mdwn b/open_issues/glibc_init_first.mdwn
deleted file mode 100644
index 774b7828..00000000
--- a/open_issues/glibc_init_first.mdwn
+++ /dev/null
@@ -1,78 +0,0 @@
-[[!meta copyright="Copyright © 2011 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_glibc]]
-
-IRC, freenode, #hurd, 2011-07-22
-
-    [additional init-first.c patch]
-    < tschwinge> civodul: The only thing I wonder about: Roland also once had
-      done similar changes, which I then found they didn'T work with GCC 4.1,
-      and backed them out in 08f53ee9d265ffdc7e0affd6acf346cceeb65559 and fixed
-      the issue differently in d8d27e633a7860b37fd2e3142822b640a066cc0f (and
-      e17cef66140d4c97710ea88bd8d12612799e1e0f).  Have you reviewed this?
-    < tschwinge> That's in the Savannah glibc repository.
-    < tschwinge> And this has been in 2007, four years ago.  I don't remember
-      all the details.
-    < tschwinge> And here is quite a good summary of this stuff, from
-      init-first.c:
-    < tschwinge> /* XXX This is all a crock and I am not happy with it.
-    < tschwinge>    This poorly-named function is called by static-start.S,
-    < civodul> braunr: thanks; i must admit it took me a while to figure it out
-      ;-)
-    < tschwinge>    which should not exist at all.  */
-    < tschwinge> civodul: I can imagine...  :-/
-    < civodul> tschwinge: re Roland's changes, that's weird; i plan to try to
-      reinstate his change and see if it works
-    < civodul> now, i won't test with GCC 4.1...
-    < tschwinge> Yeah...
-    < tschwinge> I'm happy if it works with 4.4 onwards.
-    < tschwinge> civodul: And it's safe (in GCC terms) to write to ``* ((void
-      **) __builtin_frame_address (0) + 1)'', and similar?
-    < tschwinge> Or should we be coding this few stuff in assembly?
-    < civodul> tschwinge: well, we should add a compile-time assertion for
-      __builtin_return_address (0) == *((void**)__builtin_frame_address (0) +
-      1)
-    < civodul> (i think GCC can figure it out at compile-time)
-    < civodul> but on IA32 it should always be true
-    < civodul> what's the name of glibc's compile-time assert macro already?
-    < tschwinge> I wonder whether that might interfere with some of GCC's
-      optimizations?
-    < civodul> what?
-    < tschwinge> Well, it seems unclean for me to be modifying a function's
-      return address from within C code.
-    < tschwinge> civodul: I added a verify.h in the t/verify.h branch.  But
-      people didn't really like it too much.  They rather wanted to directly
-      inline the array[(cond)?1:-1] code.
-    < civodul> ok
-    < civodul> i remember a debate about Gnulib's verify.h
-    < civodul> i thought something comparable had landed eventually
-    < tschwinge> civodul: Oh, maybe I missed it.
-    < tschwinge> civodul: In init-first.c:init, what about the usage of
-      data[-1] in the else path (not using cthreads) -- is that good as-is?
-    < civodul> tschwinge: oooh, it probably needs to fixed too
-    < civodul> but i haven't reached that point yet ;-)
-     * civodul tries to cross-bootstrap GNU from scratch
-    < tschwinge> civodul: I'd be happy to learn what was wrong with Roland's
-      original idea of fixing this.  Or perhaps this was a GCC 4.1 bug?  Or
-      perhaps GCC was inlining to much, and then got confused with frames and
-      return addresses?
-    < civodul> tschwinge: Roland's change looks good to me, so it could have
-      been a GCC bug
-    < civodul> tschwinge: OK to commit the patch to t/init-first.c (with both
-      data[-1] replaced)?
-    < tschwinge> civodul: OK, if you are confident that it works with GCC 4.4
-      onwards.  If yes, please add your changelog snippet to .topmsg, and also
-      add a not that Roland's original code may in fact have been fine, and we
-      may have hit a compiler bug.
-    < civodul> tschwinge: OK, will do
-    < civodul> tschwinge: though regarding Roland's change, i'd prefer to
-      actually test and see
-    < tschwinge> civodul: Thanks!
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index fb3d6895..9a4418c1 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -1777,3 +1777,36 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> an idea for when there's time
     <braunr> eh
     <antrik> hehe :-)
+
+
+# IRC, freenode, #hurd, 2011-10-13
+
+    <braunr> mcsim: what's the current state of your gnumach branch ?
+    <mcsim> I've merged it with master in September
+    <braunr> yes i've seen that, but does it build and run fine ?
+    <mcsim> I've tested it on gnumach from debian repository, but for building
+      I had to make additional change in device/ramdisk.c, as I mentioned.
+    <braunr> mcsim: why ?
+    <mcsim> And it runs fine for me.
+    <braunr> mcsim: why did you need to make other changes ?
+    <mcsim> because there is a patch which comes with from-debian-repository
+      kernel and it addes some code, where I have to make changes. Earlier
+      kernel_map was a pointer to structure, but I change that and now
+      kernel_map is structure. So handling to it should be by taking the
+      address (&kernel_map)
+    <braunr> why did you do that ?
+    <braunr> or put it another way: what made you do that type change on
+      kernel_map ?
+    <mcsim> Earlier memory for kernel_map was allocating with zalloc. But now
+      salloc can't allocate memory before it's initialisation
+    <braunr> that's not a good reason
+    <braunr> a simple workaround for your problem is this :
+    <braunr> static struct vm_map kernel_map_store;
+    <braunr> vm_map_t kernel_map = &kernel_map_store;
+    <mcsim> braunr: Ok. I'll correct this.
+
+
+# IRC, freenode, #hurd, 2011-11-01
+
+    <braunr> etenil: but mcsim's work is, for one, useful because the allocator
+      code is much clearer, adds some debugging support, and is smp-ready
diff --git a/open_issues/gnumach_memory_management_2.mdwn b/open_issues/gnumach_memory_management_2.mdwn
new file mode 100644
index 00000000..64aae2a4
--- /dev/null
+++ b/open_issues/gnumach_memory_management_2.mdwn
@@ -0,0 +1,246 @@
+[[!meta copyright="Copyright © 2011 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_gnumach]]
+
+IRC, freenode, #hurd, 2011-10-16:
+
+    <youpi> braunr: I realize that kmem_alloc_wired maps the allocated pages in
+      the kernel map
+    <youpi> it's a bit of a waste when my allocation is exactly a page size
+    <youpi> is there a proper page allocation which would simply return its
+      physical address?
+    <youpi> pages returned by vm_page_grab  may get swapped out, right?
+    <youpi> so could it be a matter of calling vm_page_alloc then vm_page_wire
+      (with lock_queues held) ?
+    <youpi> s/alloc/grab/
+    <braunr> vm_page_grab() is only used at boot iirc
+    <braunr> youpi: mapping allocated memory in the kernel map is normal, even
+      if it's only a page
+    <braunr> the allocated area usually gets merged with an existing
+      vm_map_entry
+    <braunr> youpi: also, i'm not sure about what you're trying to do here, so
+      my answers may be out of scope :p
+    <youpi> saving addressing space
+    <youpi> with that scheme we're using twice as much addressing space for
+      kernel buffers
+    <braunr> kernel or user task ?
+    <youpi> kernl
+    <braunr> hm are there so many wired areas ?
+    <youpi> several MiBs, yes
+    <youpi> there are also the zalloc areas
+    <braunr> that's pretty normal
+    <youpi> which I've recently incrased
+    <braunr> hm forget what i've just said about vm_page_grab()
+    <braunr> youpi: is there a particular problem caused by kernel memory
+      exhaustion ?
+    <youpi> I currently can't pass the dh_strip stage of iceweasel due to this
+    <youpi> it can not allocate a stack 
+    <braunr> a kernel thread stack ?
+    <youpi> yes
+    <braunr> that's surprising
+    <youpi> it'd be good to have a kernel memory profile
+    <braunr> vminfo is able to return the kernel map
+    <youpi> well, it's not suprising if the kernel map is full
+    <youpi> but it doesn't tell what allocates which p ieces
+    <braunr> that's what i mean, it's surprising to have a full kernel map
+    <youpi> (that's what profiling is about)
+    <braunr> right
+    <youpi> well, it's not really surprising, considering that the krenel map
+      size is arbitrarily chosen
+    <braunr> youpi: 2 GiB is really high enough
+    <youpi> it's not 2GiB, precisely
+    <youpi> there is much of the 2GiB addr space which is spent on physical
+      memory mapping
+    <youpi> then there is the virtual mapping
+    <braunr> are you sure we're talking about the kernel map, or e.g. the kmem
+      map
+    <youpi> which is currently only 192MiB
+    <youpi> the kmem_map part of kernel_map
+    <braunr> ok, the kmem_map submap then
+    <braunr> netbsd has used 128 MiB for yeas with almost no issue
+    <braunr> mach uses more kernel objects so it's reasonable to have a bigger
+      map
+    <braunr> but that big ..
+    <youpi> I've made the zalloc areas quite big
+    <youpi> err, not only zalloc area
+    <braunr> kernel stacks are allocated directly from the kernel map
+    <youpi> kalloc to 64MiB, zalloc to 64MiB
+    <youpi> ipc map size to 8MiB
+    <braunr> youpi: it could be the lack of kernel map entries
+    <youpi> and the device io map to 16MiB
+    <braunr> do you have the exact error message ?
+    <youpi> no more room for vm_map_find_entry in 71403294
+    <youpi> no more rooom for kmem_alloc_aligned in 71403294
+    <braunr> ah, aligned
+    <youpi> for a stack
+    <youpi> which is 4 pages only
+    <braunr> memory returned by kmem functions always return pages
+    <braunr> hum
+    <braunr> kmem functions always return memory in page units
+    <youpi> and my xen driver is allocating 1MiB memory for the network buffer
+    <braunr> 4 pages for kernel stacks ?
+    <youpi> through kmem_alloc_wire
+    <braunr> that seems a lot
+    <youpi> that's needed for xen page updates
+    <youpi> without having to split the update in several parts
+    <braunr> ok
+    <braunr> but are there any alignment requirements ?
+    <youpi> I guess mach  uses the alignment trick to find "self"
+    <youpi> anyway, an alignment on 4pages shouldn't be a problem
+    <braunr> i think kmem_alloc_aligned() is the generic function used both for
+      requests with and without alignment constraints
+    <youpi> so I was thinking about at least moving my xen net driver to
+      vm_grab_page instead of kmem_alloc
+    <youpi> and along this, maybe others
+    <braunr> but you only get a vm_page, you can't access the memory it
+      describes
+    <youpi> non, a lloc_aligned always aligns
+    <youpi> why?
+    <braunr> because it's not mapped
+    <youpi> there's even vm_grab_page_physical_addr
+    <youpi> it is, in the physical memory map
+    <braunr> ah, you mean using the direct mapped area
+    <youpi> yes
+    <braunr> then yes
+    <braunr> i don't know that part much
+    <youpi> what I'm afraid of is the wiring
+    <braunr> why ?
+    <youpi> because I don't want to see my page swapped out :)
+    <youpi> or whatever might happen if I don't wire it
+    <braunr> oh i'm almost sure you won't
+    <youpi> why?
+    <youpi> why some people need to wire it, and I won't?
+    <braunr> because in most mach vm derived code i've seen, you have to
+      explicitely tell the vm your area is pageable
+    <youpi> ah,  mach does such thing indeed
+    <braunr> wiring can be annoying when you're passing kernel data to external
+      tasks
+    <braunr> you have to make sure the memory isn't wired once passed
+    <braunr> but that's rather a security/resource management problem
+    <youpi> in the net driver case, it's not passed to anything else
+    <youpi> I'm seeing 19MiB kmem_alloc_wired atm
+    <braunr> looks ok to me
+    <braunr> be aware that the vm_resident code was meant for single page
+      allocations
+    <youpi> what does this mean?
+    <braunr> there is no buddy algorithm or anything else decent enough wrt
+      performance
+    <braunr> vm_page_grab_contiguous_pages() can be quite slow
+    <youpi> err, ok, but what is the relation with the question at stake ?
+    <braunr> you need 4 pages of direct mapped memory for stacks
+    <braunr> those pages need to be physically contiguous if you want to avoid
+      the mapping
+    <braunr> allocating physically contiguous pages in mach is slow
+    <braunr> :)
+    <youpi> I didn't mean I wanted to avoid the mapping for stacks
+    <youpi> for anything more than a page, kmem mapping should be fine
+    <youpi> I'm concerned with code which allocates only page per page
+    <youpi> which thus really doesn't need any mapping
+    <braunr> i don't know the mach details but in derived implementations,
+      there is almost no overhead when allocating single pages
+    <braunr> except for the tlb programming
+    <youpi> well, there is: twice as much addressing space
+    <braunr> well
+    <braunr> netbsd doesn't directly map physical memory
+    <braunr> and for others, like freebsd
+    <braunr> the area is just one vm_map_entry
+    <braunr> and on modern mmus, 4 MiBs physical mappings are used in pmap
+    <youpi> again, I don't care about tlb & performance
+    <youpi> just about the addressing space
+    <braunr> hm
+    <braunr> you say "twice"
+    <youpi> which is short when you're trying to link crazy stuff like
+      iceweasel & co
+    <youpi> yes
+    <braunr> ok, the virtual space is doubled
+    <youpi> yes
+    <braunr> but the resources consume to describe them aren't
+    <braunr> even on mach
+    <youpi> since you have both the physical mapping and the kmem mapping
+    <youpi> I don't care much about the resources
+    <youpi> but about addressing space
+    <braunr> well there are a limited numbers of solutions
+    <youpi> the space it takes  and has to be taken from something else, that
+      is,  here physical memory available to Mach
+    <braunr> reduce the physical mapping
+    <braunr> increase the kmem mapping
+    <braunr> or reduce kernel memory consumption
+    <youpi> and instead of taking the space from physical  mapping, we can as
+      well avoid doubling the space consumption when it's trivial lto
+    <youpi> yes, the hird
+    <youpi> +t
+    <youpi> that's what I'm asking from the beginning :)
+    <braunr> 18:21 < youpi> I don't care much about the resources
+    <braunr> actually, you care :)
+    <youpi> yes and no
+    <braunr> i understand what you mean
+    <youpi> not in the sense "it takes a page_t to allocate a page"
+    <braunr> you want more virtual space, and aren't that much concerned about
+      the number of objects used
+    <youpi> yes
+    <braunr> then it makes sense
+    <braunr> but in this case, it could be a good idea to generalize it
+    <braunr> have our own kmalloc/vmalloc interfaces
+    <braunr> maybe a gsoc project :)
+    <youpi> err, don't we have them already?
+    <youpi> I mean, what exactly do you want to generalize?
+    <braunr> mach only ever had vmalloc
+    <youpi> we already have a hell lot of allocators :)
+    <youpi> and it's a pain to distribute the available space to them
+    <braunr> yes
+    <braunr> but what you basically want is to introduce something similar to
+      kmalloc for single pages
+    <youpi> or just patch the few cases that need it into just grabbing a page
+    <youpi> there are probably not so many
+    <braunr> ok
+    <braunr> i've just read vm_page_grab()
+    <braunr> it only removes a page from the free list
+    <braunr> other functions such as vm_page_alloc insert them afterwards
+    <braunr> if a page is in no list, it can't be paged out
+    <braunr> so i think it's probably safe to assume it's naturally wired
+    <braunr> you don't even need a call to vm_page_wire or a flag of some sort
+    <youpi> ok
+    <braunr> although considering the low amount of work done by
+      vm_page_wire(), you could, for clarity
+    <youpi> braunr: I was also wondering about the VM_PAGE_FREE_RESERVED & such
+      constants
+    <youpi> they're like 50 pages
+    <youpi> is this still reasonable  nowadays?
+    <braunr> that's a question i'm still asking myself quite often :)
+    <youpi> also, the BURST_{MAX,MIN} & such in vm_pageout.c are probably out
+      of date?
+    <braunr> i didn't study the pageout code much
+    <youpi> k
+    <braunr> but correct handling of low memory thresholds is a good point to
+      keep in mind
+    <braunr> youpi: i often wonder how linux can sometimes have so few free
+      pages left and still be able to work without any visible failure
+    <youpi> well, as long as you have enough pages to be able to make progress,
+      you're fine
+    <youpi> that' the point of the RESERVED pages in mach I guess
+    <braunr> youpi: yes but, obviously, hard values are *bad*
+    <braunr> linux must adjust it, depending on the number of processors, the
+      number of pdflush threads, probably other things i don't have in mind
+    <braunr> i don't know what should make us adjust that value in mach
+    <youpi> which value?
+    <braunr> the size of the reserved pool
+    <youpi> I don't think it's adjusted
+    <braunr> that's what i'm saying
+    <braunr> i guess there is an #ifndef line for arch specific definitions
+    <youpi> err, you just said linux must adjust it :
+    <youpi> ))
+    <youpi> there is none
+    <braunr> linux adjusts it dynamically
+    <braunr> well ok
+    <braunr> that's another way to say it
+    <braunr> we don't have code to get rid of this macro
+    <braunr> but i don't even know how we, as maintainers, are supposed to
+      guess it
diff --git a/open_issues/gnumach_memory_management_physical_memory.mdwn b/open_issues/gnumach_memory_management_physical_memory.mdwn
new file mode 100644
index 00000000..58fefe1f
--- /dev/null
+++ b/open_issues/gnumach_memory_management_physical_memory.mdwn
@@ -0,0 +1,46 @@
+[[!meta copyright="Copyright © 2011 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_gnumach]]
+
+IRC, freenode, #hurd, 2011-10:
+
+    <braunr> antrik: about our physical memory limitations, i told you some
+      time ago that part of it was due to the linux drivers
+    <braunr> and i mentioned the paper concerning the integration of the linux
+      drivers written at the time
+    <braunr> it does indeed tell that mach, which used the common 3G->4G area
+      for the kernel space had to be adapted
+    <braunr> because linux used segmentation so that kernel addresses matched
+      physical addresses
+    <braunr> and it looks like some (many) drivers require that
+    <braunr> our current gnumach actually does this (which i found surprising
+      when i first found it)
+    <braunr> and i believe the easy solution to exceed this limitation is to
+      use a strategy similar to what linux still does on i386
+    <braunr> some highmem support
+    <braunr> we could alter the vm_resident module so that, by default, it
+      still looks for pages in the low 0-800 (or 0-1800 on debian patched
+      kernels) area
+    <braunr> but for everything else than the kernel, e.g. all user processes
+    <braunr> we could use a flag or a specialized function that would first
+      look in the highmem pool for available physical pages to map
+    <braunr> the only thing i'm not yet sure of is about user/kernel transfers
+    <braunr> if virtual addresses and copies are always cleanly done, then it's
+      ok
+    <braunr> and i really hope our linux drivers do so :)
+    <braunr> (i mean ,the glue code ofc)
+
+2011-10-23:
+
+    <youpi> braunr: I believe, like Linus, that highmem support is a nightmare
+    <antrik> braunr: uhm... the drivers want virtual addressses to match
+      physical ones? I guess that means switching address spaces before any
+      driver code is executed?...
diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn
index 55c7b87b..72bb3b77 100644
--- a/open_issues/issue_tracking.mdwn
+++ b/open_issues/issue_tracking.mdwn
@@ -102,6 +102,84 @@ IRC, freenode, #hurd, 2011-08-31:
     <mattl> RT is not the easiest thing to set up, but works pretty well once
       it's running.
 
+IRC, freenode, #hurd, 2011-10-19:
+
+    <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd?
+    <antrik> (and possibly some other lists)
+    <tschwinge> antrik: That plan got stalled, obviously.  ;-)
+    <tschwinge> antrik: Now, I had proposed to use hurd-dev for development,
+      and turn bug-hurd into a debbugs bug reportling list.  That proposal has
+      not heard any supportive/unsupportive votes yet.
+    <tschwinge> hurd-devel.  That's the name.
+    <tschwinge> And turn off hurd-devel-readers.  And turn off help-hurd.
+    <tschwinge> And web-hurd.
+    <tschwinge> Keep l4-hurd.
+    <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm
+      not quite sure myself
+    <antrik> on one hand, a dedicated bug list can be convenient; on the other
+      hand, this kind of splits always causes unnecessary overhead IMHO
+    <antrik> also, hurd-devel would obviously be *only* for development, so in
+      this scenario we actually would *need* to keep something like help-hurd
+      as well...
+    <antrik> I think I'd prefer the non-exclusive mode for debbugs... would
+      have to check again how it works exactly though :-)
+    <tschwinge> antrik: I quite liked that exclusive mode for it automatically
+      archives discussions grouped by threads for easy reference.
+    <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of
+      some sort: bug report, patch (that needs to be tracked until it is
+      applied, etc.
+    <antrik> tschwinge: exclusive mode would just mean that people would take
+      most of these discussion elsewhere, and the bug list would only be used
+      when someone explicitly wants something tracked as a bug...
+    <antrik> ideally, the bug tracker should only track things if explicitly
+      CCed. ideally, it should be possible to forward mails that have been
+      posted without CC, so they can be tracked retroactively...
+    <tschwinge> antrik: Why do you think that people would take discussions
+      elsewhere?
+    <antrik> because most people don't consider it useful to put every random
+      question or remark in an issue tracker
+    <antrik> IMHO it should be easy to turn messages into tickets/followups;
+      but it should not happen automatically
+    <tschwinge> What if people wouldn't even notice that their issues is kept
+      in a tracker, too?
+    <draculus> It might send a notification of some sort?
+    <antrik> I once posted to a list with RT in exclusive mode, and quite
+      frankly, I considered it rather strange to get a ticket created for my
+      message :-)
+    <antrik> tschwinge: that would only be useful if you always close tickets
+      for irrelevant or finished discussions, mark duplicates etc. -- and this
+      would have to happen silently, without noise for most other people
+      following the list...
+    <antrik> tschwinge: are you sure you want to do that?... :-)
+    <tschwinge> Yes.
+    <tschwinge> Because that way we don't lose so much stuff as we currently
+      do.
+    <antrik> well, the decision is up to you in that case...
+    <tschwinge> In fact, probably less than manually archiving the content, as
+      I'm doing now, partially.
+    <tschwinge> antrik: Well, I'm just out for getting some comments.
+    <antrik> it would further reduce our bus factor though :-(
+    <tschwinge> That already is low enough that it doesn't matter anymore...
+    <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are
+      not actively opposed to exclusive mode as long as it doesn't too much
+      disturbe any procedures you're currently using?
+    <antrik> well, if it happens mostly in the background, I don't see why
+      anyone should be opposed...
+    <antrik> just make sure people posting to the list don't get a "ticket
+      created" message in response :-)
+    <antrik> it would make it harder though for people to explicitly track
+      issue they are interested in I fear
+    <antrik> when using non-exclusive mode, and people explicitly CC things to
+      the tracker, which sends a notice about a ticket being created, everyone
+      sees that and can act accordingly. if everything happens in the
+      background, few people would even think about it...
+    <antrik> so non-exclusive mode probably needs more effort to keep in order;
+      but it would be more useful too...
+    <tschwinge> Well, but with exclusive mode, people don't lose anything
+      compared to the current state, do they?
+    <antrik> tschwinge: probably not compared to the current state... but
+      possibly compared to a well-used non-exclusive mode :-)
+
 
 # Further Systems
 
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
new file mode 100644
index 00000000..1418bea1
--- /dev/null
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -0,0 +1,52 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+[[!meta title="libpthread: __pthread_enqueue: Assertion `thread->prevp == 0'
+failed"]]
+
+[[!tag open_issue_libpthread]]
+
+IRC, OFTC, #debian-hurd, 2011-10-21:
+
+    [Python testsuite]
+    <pinotree> [169/340/1] test_logging
+    <pinotree> python:
+      /home/pino/sources/hurd/hurd-20110519/./libpthread/pthread/pt-internal.h:109:
+      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
+    <pinotree> sigh
+
+IRC, freenode, #hurd, 2011-10-21:
+
+    <pinotree> am i missing anything, or in libpthread the __pthread_threads
+      list does not ever has elements removed from it?
+    <pinotree> ... thus potentially causing
+      "./libpthread/pthread/pt-internal.h:109: __pthread_enqueue: Assertion
+      `thread->prevp == 0' failed." because threads can be appended on
+      __pthread_dealloc() to the __pthread_free_threads list as well?
+    <pinotree> maybe reusing the same next+prevp pointers in the __pthread
+      struct for more than one list at the same time isn't a good idea...
+
+2011-10-23:
+
+    <youpi> pinotree: I don't understand the relation between thread->prevp !=
+      0 and the __pthread_threads list
+    <youpi> the list never has elements removed indeed, since libpthread never
+      frees __pthread structures apparently
+    <pinotree> youpi: ye sorry, that relation is indeed nonsense
+    <youpi> in which condition did you get prevp != 0
+    <pinotree> i wa trying to find some explaination for the "thread->prevp ==
+      0" assertion in the _queue function
+    <youpi> ?
+    <pinotree> *was
+    <youpi> it's not obvious to me how libpthread makes sure the various
+      cond/mutex/rwlock make sure that it's not queued several times
+    <pinotree> yeah
+    <pinotree> apparently prevp/next are used for lists of held
+      waitcond/mutex/rwlock and free threads
diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn
index a5704d0f..ca2da2f5 100644
--- a/open_issues/libpthread_pthread_key_create_reuse.mdwn
+++ b/open_issues/libpthread_pthread_key_create_reuse.mdwn
@@ -10,10 +10,10 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="libpthread: pthread_key_create, reuse"]]
 
-IRC, FreeNode, #hurd, 2011-07-02
-
 [[!tag open_issue_libpthread]]
 
+IRC, FreeNode, #hurd, 2011-07-02:
+
     < pinotree> hm, maybe i found a libpthread bug
     * pinotree tries a testcase
     < pinotree> yesssss, found the bug :)
@@ -47,3 +47,36 @@ IRC, FreeNode, #hurd, 2011-07-02
       veeery quick glance
 
 Test program: [[pthread_key_create_reuse.c]]
+
+
+2011-11-01:
+
+    <pinotree> youpi: about the bug with pthread keys (reuse): would be an
+      acceptable solution having a mutex for the thread_specifics of each
+      thread?
+    <youpi> you mean one per thread, one global, or one per key, or ?
+    <youpi> what is it supposed to protect?
+    <pinotree> the thread_specifics of each thread
+    <youpi> pinotree: but against what?
+    <pinotree> the idea would be: when destroying a key, iterate over all the
+      exiting threads and remove the key data from the thread_specifics of each
+      thread
+    <youpi> one of the issue is getting to browse through the whole list of
+      threads
+    <youpi> the other is concurrency between that, and a thread dying
+    <pinotree> there's the __pthread_threads_lock rwlock
+    <youpi> it should be enough to keep it locked during the iteration
+    <pinotree> but that wouldn't be enough when one thread is destroying a key,
+      and another one is doing {get,set}specific() on that key
+    <youpi> that's not supposed to happen
+    <pinotree> mmm
+    <youpi> “The effect of calling pthread_getspecific() or
+      pthread_setspecific() with a     key value not obtained from
+      pthread_key_create() or after key has been     deleted with
+      pthread_key_delete() is undefined.”
+    <youpi> undefined -> you are allowed to just blow up
+    <pinotree> but it's not been deleted yet... :)
+    <youpi> it could be, just a matter of time
+    <youpi> you're not supposed to rely on time-luckyness :)
+    <pinotree> mmm
+    <pinotree> bah, you've convinced me ( :) )
diff --git a/open_issues/libpthread_set_stack_size.mdwn b/open_issues/libpthread_set_stack_size.mdwn
new file mode 100644
index 00000000..68f81752
--- /dev/null
+++ b/open_issues/libpthread_set_stack_size.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2011 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_glibc open_issue_libpthread]]
+
+IRC, freenode, #hurd, 2011-10-21:
+
+    <pinotree> maybe i'm missing something... what's the reason for not
+      allowing setting a different stack size in libpthread?
+
+2011-10-23:
+
+    <youpi> pinotree: the threadvars implementations
+    <youpi> which needs to find the variables according to sp value
+    <youpi> of course, since we now have TLS, threadvards can go away
+    <youpi> it's simply on the so-long TODO list
+
+[[glibc/t/tls-threadvar]].
diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn
new file mode 100644
index 00000000..212d65e7
--- /dev/null
+++ b/open_issues/mission_statement.mdwn
@@ -0,0 +1,39 @@
+[[!meta copyright="Copyright © 2011 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_documentation]]
+
+IRC, freenode, #hurd, 2011-10-12:
+
+    <ArneBab> we have a mission statement: http://hurd.gnu.org
+    <Gorodish> yes
+    <Gorodish> but it's quite wishy washy
+    <Gorodish> considering all the elegant capability Hurd potentially has to
+      offer
+    <antrik> Gorodish: it's true that the mission statement is very
+      abstract... but then, it's hard to put anything more specific into 35
+      words
+    <Gorodish> not with some practice
+    <Gorodish> I notice programers tend to speak and write in terms of what
+      something does
+    <Gorodish> not what it is
+    <Gorodish> the "What is Hurd" is a good example
+    <Gorodish> there's a lot of interesting information there
+    <Gorodish> but the way it's ordered is odd
+    <antrik> a mission statement is not primarily a PR instrument; but rather a
+      guide that allows separating things that benefit the common goal from
+      things that don't...
+    <antrik> I agree that some actual marketing material in addition would be
+      nice :-)
+    <Gorodish> yes
+    <Gorodish> the modesty of Developers that work on FOSS projects never
+      ceases to amaze me
+    <Gorodish> I agree that the informational, factual, results oriented
+      documentation is the primary objective of documenting
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
index 359d5fee..d0b8ea7f 100644
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
@@ -27,6 +27,10 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.
 On the idle grubber, this one repeatedly takes a few minutes wall time to
 complete successfully, contrary to a few seconds on a GNU/Linux system.
 
+> On order of slowness may in fact be due to a Xen-specific issue, see
+> [[xen_lseek]].  (But there are probably still one or two orders left, even
+> without Xen.)
+
 While processing the object files, there is heavy interaction with the relevant
 [[hurd/translator/ext2fs]] process.  Running [[hurd/debugging/rpctrace]] on
 the testee shows that (primarily) an ever-repeating series of `io_seek` and
@@ -47,4 +51,6 @@ IRC, freenode, #hurd, 2011-09-01:
     <youpi> (fgetpos actually, but that's the same)
     <youpi> and it is indeed about 10 times slower under Xen for some reason
 
+Also see testcase [[test-lseek.c]] and [[test-mach.c]]
+
 [[!tag open_issue_xen]]
diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/performance/io_system/test-lseek.c
new file mode 100644
index 00000000..667dce66
--- /dev/null
+++ b/open_issues/performance/io_system/test-lseek.c
@@ -0,0 +1,17 @@
+#include <stdio.h>
+#include <math.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/time.h>
+#define N 100000
+int main(void) {
+	int fd = open("test.c", O_RDONLY);
+	struct timeval tv1, tv2;
+	int i;
+	gettimeofday(&tv1, NULL);
+	for (i = 0; i < N; i++)
+		lseek(fd, 0, SEEK_CUR);
+	gettimeofday(&tv2, NULL);
+	printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N);
+	return 0;
+}
diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/performance/io_system/test-mach.c
new file mode 100644
index 00000000..90337346
--- /dev/null
+++ b/open_issues/performance/io_system/test-mach.c
@@ -0,0 +1,19 @@
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <fcntl.h>
+#include <mach/mach.h>
+#define N 1000000
+int main(void) {
+	struct timeval tv1, tv2;
+	int i;
+	task_t task;
+	task = mach_task_self();
+	mach_port_urefs_t refs;
+	gettimeofday(&tv1, NULL);
+	for (i = 0; i < N; i++) {
+		mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs);
+	}
+	gettimeofday(&tv2, NULL);
+	printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N);
+	return 0;
+}
diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn
index 714c8784..513cbc73 100644
--- a/open_issues/pfinet_vs_system_time_changes.mdwn
+++ b/open_issues/pfinet_vs_system_time_changes.mdwn
@@ -17,7 +17,7 @@ IRC, unknown channel, unknown date.
 
 This was very likely a misdiagnosis:
 
-IRC, freenode, #hurd, 2011-03-25
+IRC, freenode, #hurd, 2011-03-25:
 
     <tschwinge> antrik: I suspect it'S some timing stuff in pfinet that perhaps
       uses absolute time, and somehow wildely gets confused?
@@ -40,3 +40,21 @@ IRC, freenode, #hurd, 2011-03-25
     <tschwinge> (The other way round, you might likely get some integer
       wrap-around, and thus the same result.)
     <tschwinge> Yes.
+
+IRC, freenode, #hurd, 2011-10-26:
+
+    <antrik> anyways, when ntpdate adjusts to the past, the connections hang,
+      roughly for the amount of time being adjusted
+    <antrik> they do not die though
+    <antrik> (well, if it's long enough, they probably timeout on the other
+      side...)
+
+IRC, freenode, #hurd, 2011-10-27:
+
+    <antrik> oh, another interesting thing I observed is that the the subhurd
+      pfinet did *not* drop the connection... only the main Hurd one. I thought
+      the clock is system-wide?...
+    <tschwinge> It is.
+    <antrik> it's really fascinating that only the pfinet on the Hurd instance
+      where I set the date is affected, and not the pfinet in the other
+      instance
diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn
index cdd3f322..fe51523b 100644
--- a/open_issues/screen_dead_session.mdwn
+++ b/open_issues/screen_dead_session.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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
@@ -14,7 +14,10 @@ Comparing to GNU/Linux, on GNU/Hurd it happens much more often and easily for
 *screen* sessions to become *dead*.  This is annoying, as it defeats one of
 *screen*'s main purposes.
 
-One reproducible scenario goes like this:
+[[!toc]]
+
+
+# One reproducible scenario goes like this
 
   * `ssh [somewhere]`,
 
@@ -28,7 +31,8 @@ One reproducible scenario goes like this:
   * at some point, *P* will terminate / hang (after having received some kind
     of signal?), and the *screen* session will be reported as *dead*.
 
-Another one, not as often reproduced:
+
+# Another one, not as often reproduced
 
   * `ssh [somewhere]`,
 
@@ -43,3 +47,23 @@ Another one, not as often reproduced:
     (after having received some kind of signal?), and the *screen* session will
     *immediatelly* be reported as *dead*.  (Perhaps the other way round: upon
     re-attaching, the *screen* session goes bonkers and takes *P* with it?)
+
+
+# IRC, freenode, #hurd, 2011-10-19
+
+    <antrik> tschwinge: hm... haven't seen screen dying in a long time
+    <tschwinge> antrik: It's easy, and goes like this: have a session on one
+      system, log in from another, do screen -x and wait some time.
+    <antrik> I do this regularily. haven't had a crash in ages.
+    <antrik> (BTW, I'm not sure I ever had a crash on srceen -x... at that
+      time, I wasn't using -x. I often had crashes with screen -r. my
+      impression back then was that it works better when doing -rd -- in fact,
+      I always do that now, so I can't say whether crashes still happen with
+      only -r...)
+
+2011-10-26:
+
+    <antrik> so I was saying the other day that I haven't had a screen crash in
+      a long time... well, here it was :-(
+    <antrik> this time it didn't crash on reconnect though, but already
+      before. probably when I killed the hanging ssh connection
diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn
new file mode 100644
index 00000000..aa36e020
--- /dev/null
+++ b/open_issues/ti-rpc_then_nfs.mdwn
@@ -0,0 +1,20 @@
+[[!meta copyright="Copyright © 2011 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 open_issue_porting]]
+
+TI-RPC replaces glibc's Sun RPC implementation, [[!message-id
+"4D0632C5.1040107@RedHat.com"]].
+
+It needs some work on our side, [[!message-id
+"20101214213212.GU1095@kepler.schwinge.homeip.net"]].
+
+Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be
+re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]].
diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn
index e0828b28..11793582 100644
--- a/open_issues/translator_stdout_stderr.mdwn
+++ b/open_issues/translator_stdout_stderr.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -13,3 +13,9 @@ License|/fdl]]."]]"""]]
 
 Decide / implement / fix that (all?) running (passive?) translators' output
 should show up on the (Mach / Hurd) console / syslog.
+
+[[!taglink open_issue_documentation]]: [[!message-id
+"87oepj1wql.fsf@becket.becket.net"]]
+
+[[!taglink open_issue_documentation]]: Neal once had written an email on this
+topic.
diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn
index e929f2bf..70c3c6dc 100644
--- a/open_issues/user-space_device_drivers.mdwn
+++ b/open_issues/user-space_device_drivers.mdwn
@@ -97,7 +97,7 @@ IRC, freenode, #hurd, 2011-07-27
 
           * Hurd on L4: deva, fabrica
 
-          * [[DDE]]
+          * [[/DDE]]
 
       * Minix 3
 
@@ -195,7 +195,7 @@ IRC, freenode, #hurd, 2011-07-27
 
 # External Projects
 
-  * [[DDE]]
+  * [[/DDE]]
 
   * <http://ertos.nicta.com.au/research/drivers/uldd/>
 
diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn
new file mode 100644
index 00000000..accc7c8f
--- /dev/null
+++ b/open_issues/xen_lseek.mdwn
@@ -0,0 +1,35 @@
+[[!meta copyright="Copyright © 2011 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_xen]]
+
+IRC, freenode, #hurd, 2011-11-02:
+
+    <youpi> btw, we have a performance issue with xen
+    <youpi> an lseek() call costs a huge lot
+    <youpi> like 1ms
+    <youpi> while the same costs just a few dozens µs with kvm
+    <youpi> there's of course the cost of switching between ring3, ring0,
+      ring1, ring0, ring3, but still
+    <gianluca> oh, nice.
+    <youpi> lseek is supposed to perform only a back&forth
+    <youpi> and I don't observe disk activity, so it's not waiting for the disk
+      to complete whatever atime change & such :)
+    <youpi> it was mentioned that perhaps xen in hvm mode with pv drivers would
+      be faster
+    <youpi> thanks to the ring3/"1" switching  being done by the processor
+    <youpi> (and assuming npt)
+    <gianluca> hm
+    <gianluca> i'll look into that, sounds fun.
+    <gianluca> :)
+    <tschwinge> Here is a testcase:
+      http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html
+
+[[performance/io_system/binutils_ld_64ksec]].