Merge branch 'master' of git.savannah.gnu.org:/srv/git/hurd/web

15 files changed, 353 insertions, 25 deletions

diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn
index 8ed69345..f1811b27 100644
--- a/open_issues/address_space_memory_mapping_entries.mdwn
+++ b/open_issues/address_space_memory_mapping_entries.mdwn
@@ -18,4 +18,5 @@ IRC, freenode, #hurd, 2011-05-07
     <braunr> a bare linked list
     <braunr> which makes faults and page cache lookups even slower
 
-A red-black tree was added to VM maps to speed up lookups.
+A [[red-black tree|gnumach_vm_map_red-black_trees]] was added to VM maps to
+speed up lookups.
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 757ebbe9..5d36d3d1 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -33,14 +33,14 @@ though, as explained below.
 <!--
 
 git checkout reviewed
-git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master
+git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..sourceware/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less
 -i
-/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:
+/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
 
 -->
 
-Last reviewed up to the [[Git mirror's 944a6010b676b9f80f0a16c65183102b187822c5
-(2013-02-08) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's 5c3ec1ded654250e0ac27df79998b32b2403e81f
+(2013-04-29) sources|source_repositories/binutils]].
 
   * Globally
 
@@ -126,7 +126,7 @@ Last reviewed up to the [[Git mirror's 944a6010b676b9f80f0a16c65183102b187822c5
 
 Here's a log of a binutils build run; this is from our [[Git
 repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch,
-commit 944a6010b676b9f80f0a16c65183102b187822c5 (2013-02-08), run on
+commit 5c3ec1ded654250e0ac27df79998b32b2403e81f (2013-04-29), run on
 kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -140,8 +140,8 @@ harmonized.  Debian GCC (which is used in binutils' testsuite) likes to pass
 `--sysroot=/` to `ld`, so we need to configure binutils with support for
 sysroots.
 
-This takes up around 900 MiB, and needs roughly 11 min on kepler.SCHWINGE and
-42 min on coulomb.SCHWINGE.
+This takes up around 950 MiB, and needs roughly 13 min on kepler.SCHWINGE and
+45 min on coulomb.SCHWINGE.
 
 <!--
 
@@ -165,6 +165,12 @@ formats, and more emulation vectors.
 
     Missing [[IFUNC]] support on GNU/Hurd.
 
+  * 944a6010b676b9f80f0a16c65183102b187822c5..a5e5fda5f96d5b881a354bd8666fdbb1496ee8da:
+
+         gcc-4.6 -c -DHAVE_CONFIG_H -g -O2  -I. -I../../Paul_Desmond/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../Paul_Desmond/libiberty/hashtab.c -o hashtab.o
+        +../../Paul_Desmond/libiberty/hashtab.c: In function 'hash_pointer':
+        +../../Paul_Desmond/libiberty/hashtab.c:1001:7: warning: right shift count >= width of type [enabled by default]
+
 
 # Install
 
@@ -187,7 +193,7 @@ min on coulomb.SCHWINGE.
     $ make -k check 2>&1 | tee log_test
     [...]
 
-This needs roughly 6 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE.
+This needs roughly 6 min on kepler.SCHWINGE and 45 min on coulomb.SCHWINGE.
 
 
 ## Analysis
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 5ba6b418..98454d45 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -15,7 +15,7 @@ License|/fdl]]."]]"""]]
 Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel)
 
 It could be a mere matter of extending the
-[[mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]:
+[[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]:
 add it to
 `mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and
 make `clock_gettime` use it.
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index f0f7cae0..65d84886 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -394,7 +394,7 @@ After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
     <youpi> so ZhengDa preferred to make jiffies a macro which calls a function
       which reads the mapped time
 
-[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]].
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
 
     <youpi> however, that break any use of the work "jiffies", e.g. structure
       members & such
diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn
index e9fbf0f1..fb94cb83 100644
--- a/open_issues/gccgo.mdwn
+++ b/open_issues/gccgo.mdwn
@@ -38,6 +38,61 @@ been working on this, has some (unpublished) patches, and this is currently
 blocked on [[`getcontext`/`setcontext`|open_issues/glibc/t/tls-threadvar]].
 
 
+## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
+
+In context of [[glibc/t/tls-threadvar]].  Looking at GCC trunk commit
+f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).
+
+The check in `libgo/configure.ac` *whether setcontext clobbers TLS variables*
+is invalid on GNU Hurd.
+
+The `*context` functions are used in `libgo/runtime/go-signal.c` and
+`libgo/runtime/proc.c`.
+
+`__splitstack_getcontext`, `__splitstack_setcontext`,
+`__splitstack_makecontext`, `__splitstack_resetcontext`,
+`__splitstack_block_signals_context` are to be provided by libgcc.  However, in
+said libgo runtime files, they're used only `#ifdef USING_SPLIT_STACK`.
+[[I|ŧschwinge]] would assume that before we can enable split stacks, first
+[[open_issues/glibc/t/tls-threadvar]] needs to be fixed.
+
+In `libgo/runtime/proc.c`:`runtime_gogo`, `setcontext` is used to *switch
+context to a different goroutine*.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_mcall`, which *save[s] context and call[s]
+fn passing g as a parameter*, `getcontext` and `setcontext` are used; this is
+only called from `libgo/runtime/proc.c`:`runtime_gosched`.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_tracebackothers`, `getcontext` is used to
+*switch context to the goroutine*.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_mstart`, which is *called to start an M*,
+`getcontext` is used.  TODO.
+
+In `libgo/runtime/proc.c`:`runtime_entersyscall`, which is called when *the
+goroutine g is about to enter a system call*, `getcontext` is used to *save the
+registers in the g structure so that any pointers held in registers will be
+seen by the garbage collector*.  Should be fine.
+
+In `libgo/runtime/proc.c`:`__go_go`, `getcontext` and `makecontext` are used.
+TODO.
+
+In `libgo/runtime/thread.c`:`runtime_minit`, which is *[c]alled to initialize a
+new m (including the bootstrap m)*, `ss.ss_sp` is set to a new stack retrieved
+via `libgo/runtime/proc.c:runtime_malg`, which *allocate[s] a new g, with a
+stack [...]*, and then `sigaltstack` is called.  TODO.
+
+    libgo/runtime/go-signal.c:  /* We are now running on the stack registered via sigaltstack.
+    libgo/runtime/go-signal.c:     and sigaltstack when the program starts.)  */
+    
+    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp = vsp;
+    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_sp += vspsize;
+    libgo/runtime/proc.c:         vnewg->context.uc_stack.ss_size = vspsize;
+
+Also, in `libgo/runtime/proc.c`:`runtime_newm`, `pthread_attr_setstacksize` is
+used, which we also can't support yet, for the same reason.
+
+
 ---
 
 
diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn
index 6b9cd135..eddc2fdc 100644
--- a/open_issues/gdb.mdwn
+++ b/open_issues/gdb.mdwn
@@ -27,14 +27,14 @@ Here's what's to be done for maintaining GNU GDB.
 <!--
 
 git checkout reviewed
-git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master
+git diff --patience --stat=$COLUMNS,$COLUMNS --patch --src-prefix=./ --dst-prefix=./ --find-renames --ignore-space-change ..sourceware/master | awk '/^diff/ { c = $0; } /^@@/ { print c; } { print; }' | less
 -i
-/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:|gnu-nat|i386gnu
+/^---.*/([^.]*|.*\.texi.*|[^/]*gnu[^/]*)$|hurd|linux|nacl|nptl|glibc|gs:
 
 -->
 
-Last reviewed up to the [[Git mirror's 6b25dae901ddedb3f330803542d3eac73cdcae4b
-(2013-03-13) sources|source_repositories/gdb]].
+Last reviewed up to the [[Git mirror's 6330ab576e18fb97912839fc116c7babb5fd8c70
+(2013-04-28) sources|source_repositories/gdb]].
 
   * Globally
 
@@ -71,7 +71,7 @@ Last reviewed up to the [[Git mirror's 6b25dae901ddedb3f330803542d3eac73cdcae4b
 
 Here's a log of a GDB build run; this is from our [[Git
 repository|source_repositories/gdb]]'s `tschwinge/Ferry_Tagscherer` branch,
-commit 6b25dae901ddedb3f330803542d3eac73cdcae4b (2013-03-13), run on
+commit 6330ab576e18fb97912839fc116c7babb5fd8c70 (2013-04-28), run on
 kepler.SCHWINGE and coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -194,6 +194,12 @@ formats and more emulation vectors.
         +                 from ../../Ferry_Tagscherer/gdb/gnu-nat.c:56:
         +../../Ferry_Tagscherer/gdb/value.h:729:22: note: expected 'const char **' but argument is of type 'char **'
 
+  * 6b25dae901ddedb3f330803542d3eac73cdcae4b..6330ab576e18fb97912839fc116c7babb5fd8c70:
+
+         gcc-4.7 -c -DHAVE_CONFIG_H -g -O2  -I. -I../../Ferry_Tagscherer/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  ../../Ferry_Tagscherer/libiberty/hashtab.c -o hashtab.o
+        +../../Ferry_Tagscherer/libiberty/hashtab.c: In function 'hash_pointer':
+        +../../Ferry_Tagscherer/libiberty/hashtab.c:1001:7: warning: right shift count >= width of type [enabled by default]
+
 
 # Install
 
@@ -363,4 +369,15 @@ GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown
 
         *stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x00014add",func="??",args=[],from="/lib/ld.so"},thread-id="4",stopped-threads="all"
 
+  * `gdb.arch/i386-float.exp: info float`
+
+        Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.arch/i386-float.exp ...
+        PASS: gdb.arch/i386-float.exp: first stepi
+        FAIL: gdb.arch/i386-float.exp: info float
+        PASS: gdb.arch/i386-float.exp: second stepi
+        PASS: gdb.arch/i386-float.exp: info float
+
+    Only fails for GNU/Hurd: the floating point stack initially is not
+    all-zeroes, which is expected, and which it is on GNU/Linux.
+
 TODO.
diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn
index 8f1b7b48..b9114b69 100644
--- a/open_issues/gdb_attach.mdwn
+++ b/open_issues/gdb_attach.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -54,3 +54,30 @@ License|/fdl]]."]]"""]]
       process
     <tschwinge> That is supposed to work.
     <tschwinge> If the permission match.
+
+
+# `gdb --pid [PID]`
+
+That is, not explicitly specifying an `executable-file`.
+
+
+## IRC, OFTC, debian-hurd, 2013-04-15
+
+    <paravoid> I don't seem to be able to run gdb
+    <paravoid> that happened on the buildd and happens on exodar too
+    <paravoid> #0  0x010c07cc in ?? ()
+    <paravoid> #1  0x010c1078 in ?? ()
+    <paravoid> #2  0x0109eabf in ?? ()
+    <paravoid> [...]
+    <paravoid> Backtrace stopped: previous frame inner to this frame (corrupt
+      stack?)
+    <paravoid> that's pid 24235 on exodar
+    <paravoid> I did gdb -p 24235 and then bt
+    <paravoid> just the output above
+    <youpi> I don't know about gdb -p
+    <youpi> I usually run gdb
+      /home/paravoid/gdnsd-1.8.1/plugins/meta/libgdmaps/t/.libs/lt-t17_extn_empty.bin
+      24235
+    <paravoid> okay, that indeed works 
+    <youpi> I guess the support for finding out the binary automatically wasn't
+      done yet on hurd
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
index a8892876..ceb5ea21 100644
--- a/open_issues/glibc/0.4.mdwn
+++ b/open_issues/glibc/0.4.mdwn
@@ -25,4 +25,6 @@ In context of [[packaging_libpthread]]/[[libpthread]].
       the exec server IIRC...
     <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
       reminding!
-    <tschwinge> pochu: Won't happen today or tomorrow, but "sometime".
+
+[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
+"4BFA500A.7030502@gmail.com"]].
diff --git a/open_issues/gnat.mdwn b/open_issues/gnat.mdwn
index 0f404b8a..84e8f60b 100644
--- a/open_issues/gnat.mdwn
+++ b/open_issues/gnat.mdwn
@@ -103,6 +103,55 @@ know if the port has yet seen any real-world usage, such as using it for any
 bigger Ada code bases, or any Ada testsuites.
 
 
+## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
+
+In context of [[glibc/t/tls-threadvar]].  Looking at GCC trunk commit
+f6568ea476aa52a6e23c6db43b3e240cde55783a (2013-04-26).
+
+    gcc/ada/init.c:  sigaltstack (&stack, NULL);
+    gcc/ada/init.c:      sigaltstack (&stack, NULL);
+    gcc/ada/init.c:  sigaltstack (&stack, NULL);
+    gcc/ada/s-osinte-aix.ads:   function sigaltstack
+    gcc/ada/s-osinte-aix.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-android.ads:   function sigaltstack
+    gcc/ada/s-osinte-android.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-darwin.ads:   function sigaltstack
+    gcc/ada/s-osinte-darwin.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-freebsd.ads:   function sigaltstack
+    gcc/ada/s-osinte-freebsd.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-hpux.ads:   function sigaltstack
+    gcc/ada/s-osinte-hpux.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-kfreebsd-gnu.ads:   function sigaltstack
+    gcc/ada/s-osinte-kfreebsd-gnu.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-linux.ads:   function sigaltstack
+    gcc/ada/s-osinte-linux.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-osinte-rtems.adb:   -- sigaltstack --
+    gcc/ada/s-osinte-rtems.adb:   function sigaltstack
+    gcc/ada/s-osinte-rtems.adb:   end sigaltstack;
+    gcc/ada/s-osinte-rtems.ads:   function sigaltstack
+    gcc/ada/s-osinte-solaris-posix.ads:   function sigaltstack
+    gcc/ada/s-osinte-solaris-posix.ads:   pragma Import (C, sigaltstack, "sigaltstack");
+    gcc/ada/s-taprop-linux.adb:            Result := sigaltstack (Stack'Access, null);
+    gcc/ada/s-taprop-posix.adb:            Result := sigaltstack (Stack'Access, null);
+    gcc/ada/init.c:  stack.ss_sp = __gnat_alternate_stack;
+    gcc/ada/init.c:      stack.ss_sp = __gnat_alternate_stack;
+    gcc/ada/init.c:  stack.ss_sp = __gnat_alternate_stack;
+    gcc/ada/s-osinte-aix.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-android.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-darwin.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-darwin.ads:      uc_stack    : stack_t;          --  Stack Used By This Context
+    gcc/ada/s-osinte-freebsd.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-hpux.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-kfreebsd-gnu.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-linux.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-rtems.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-solaris-posix.ads:      ss_sp    : System.Address;
+    gcc/ada/s-osinte-solaris.ads:      ss_sp        : System.Address;
+    gcc/ada/s-osinte-solaris.ads:      uc_stack     : record_type_2;
+    gcc/ada/s-taprop-linux.adb:            Stack.ss_sp    := Self_ID.Common.Task_Alternate_Stack;
+    gcc/ada/s-taprop-posix.adb:            Stack.ss_sp    := Self_ID.Common.Task_Alternate_Stack;
+
+
 ---
 
 
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index 46454207..60ec7357 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -832,6 +832,8 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> it could also be used to drop the overloaded (and probably over
       imbalanced) page cache hash table
 
+[[gnumach_vm_map_red-black_trees]].
+
 
 # IRC, freenode, #hurd, 2011-05-03
 
@@ -2227,3 +2229,37 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> (i mean, when i made my tests, it looked like there were few
       kernel map entries, but i may have missed corner cases that could cause
       more of them to be needed)
+
+
+# IRC, freenode, #hurd, 2013-04-18
+
+    <braunr> oh nice, i've found a big scalability issue with my slab allocator
+    <braunr> it shouldn't affect gnumach much though
+
+
+## IRC, freenode, #hurd, 2013-04-19
+
+    <ArneBab> braunr: is it fixable?
+    <braunr> yes
+    <braunr> well, i'll do it in x15 for a start
+    <braunr> again, i don't think gnumach is much affected
+    <braunr> it's a scalability issue
+    <braunr> when millions of objects are in use
+    <braunr> gnumach rarely has more than a few hundred thousands
+    <braunr> it's also related to heavy multithreading/smp
+    <braunr> and by multithreading, i also mean preemption
+    <braunr> gnumach isn't preemptible and uniprocessor
+    <braunr> if the resulting diff is clean enough, i'll push it to gnumach
+      though :)
+
+
+### IRC, freenode, #hurd, 2013-04-21
+
+    <braunr> ArneBab_: i fixed the scalability problems btw
+
+
+## IRC, freenode, #hurd, 2013-04-20
+
+    <braunr> well, there is also a locking error in the slab allocator,
+      although not a problem for a non preemptible kernel like gnumach
+    <braunr> non preemptible / uniprocessor
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
index 37ee548b..9f732fbe 100644
--- a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -26,7 +26,7 @@ License|/fdl]]."]]"""]]
     <pinotree> this way we could add inside hurdtime.c the mapped time stuff
       too
 
-[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]].
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
 
     <pinotree> most probably a noobish question, but why does rt link to
       pthread?
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
index 1418bea1..e8160528 100644
--- a/open_issues/libpthread_assertion_thread_prevp.mdwn
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -13,7 +13,8 @@ failed"]]
 
 [[!tag open_issue_libpthread]]
 
-IRC, OFTC, #debian-hurd, 2011-10-21:
+
+# IRC, OFTC, #debian-hurd, 2011-10-21
 
     [Python testsuite]
     <pinotree> [169/340/1] test_logging
@@ -22,7 +23,8 @@ IRC, OFTC, #debian-hurd, 2011-10-21:
       __pthread_enqueue: Assertion `thread->prevp == 0' failed.
     <pinotree> sigh
 
-IRC, freenode, #hurd, 2011-10-21:
+
+## 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?
@@ -33,7 +35,8 @@ IRC, freenode, #hurd, 2011-10-21:
     <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:
+
+## IRC, freenode, #hurd, 2011-10-23
 
     <youpi> pinotree: I don't understand the relation between thread->prevp !=
       0 and the __pthread_threads list
@@ -50,3 +53,37 @@ IRC, freenode, #hurd, 2011-10-21:
     <pinotree> yeah
     <pinotree> apparently prevp/next are used for lists of held
       waitcond/mutex/rwlock and free threads
+
+
+# IRC, freenode, #hurd, 2013-03-20
+
+    <braunr> aw
+    <braunr> i hit the ext2fs.static: ./pthread/pt-internal.h:122:
+      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
+    <braunr> assertion
+    <braunr> looks like there is a deadlock on assert
+    <braunr> which might explain why i never saw progress when i tested that in
+      the past
+
+
+## IRC, freenode, #hurd, 2013-04-21
+
+    <braunr> damn, there still bugs in libpthread
+    <braunr> (about prevp not being null when it should i mean)
+    <pinotree> braunr: found another trigger for that?
+    <braunr> no
+    <braunr> it's so random i wonder if it's not a completely unrelated
+      corruption
+    <braunr> pinotree: also, i'm having more of these issues with my custom
+      hurd packages that let threads exit after some time from managing ports
+    <braunr> (i removed the libports_stability patch)
+    <braunr> i once had this : http://www.sceen.net/~rbraun/darnassus_crash.png
+
+[The assertion failure.]
+
+
+## IRC, freenode, #hurd, 2013-04-23
+
+    <braunr> removing the libports_stability patch exposed bugs in libpthread,
+      triggering assertions when queueing/dequeue threads from a queue (but i
+      don't know which one / in which function)
diff --git a/open_issues/libpthread_cancellation_points.mdwn b/open_issues/libpthread_cancellation_points.mdwn
index af0efa9d..48f1acf5 100644
--- a/open_issues/libpthread_cancellation_points.mdwn
+++ b/open_issues/libpthread_cancellation_points.mdwn
@@ -39,3 +39,101 @@ type to asynchronous permits this testcase to terminate. We do have the
 pthread_setcanceltype glibc/libpthread hook in the forward structure, but we are
 not using it: the LIBC_CANCEL_ASYNC macros are void, and we're not using them in
 the mig msg call either.
+
+
+# Provenance
+
+## IRC, OFTC, #debian-hurd, 2013-04-15
+
+    <paravoid> so, let me say a few things about the bug in the first place
+    <paravoid> the package builds and runs a test suite
+    <paravoid> the second test in the test suite blocks forever
+    <paravoid> a blocked pthread_join is what I see
+    <paravoid> I'm unsure why
+    <paravoid> have you seen anything like it before?
+    <youpi> whenever the thread doesn't actually terminate, sure
+    <youpi> what is the thread usually blocked on when you cancel it?
+    <paravoid> this is a hurd-specific issue
+    <paravoid> works on all other arches
+    <youpi> could be just that all other archs have more relaxed behavior
+    <youpi> thus the question of what exactly is supposed to be happening
+    <youpi> apparently it is inside a select?
+    <youpi> it seems select is not cancellable here
+    <pinotree> wasn't the patch you sent?
+    <youpi> no, my patch was about signals
+    <youpi> not cancellation
+    <pinotree> k
+    <youpi> (even if that could be related, of course)
+    <paravoid> how did you see that?
+    <paravoid> what's the equivalent of strace?
+    <youpi> thread 3 is inside _hurd_select
+    <paravoid> thread 1 is blocked on join
+    <paravoid> but the code is
+    <paravoid>     if(gdmaps->reload_thread_spawned) {
+    <paravoid>         pthread_cancel(gdmaps->reload_tid);
+    <paravoid>         pthread_join(gdmaps->reload_tid, NULL);
+    <paravoid>     }
+    <paravoid> so cancel should have killed the thread
+    <youpi> cancelling a thread is a complex matter
+    <youpi> there are cancellation points
+    <youpi> e.g. a thread performing while(1); can't be cancelled
+    <paravoid> thread 3 is just a libev event loop
+    <youpi> yes, "just" calling poll, the most complex system call of unix :)
+    <youpi> paravoid: anyway, don't look for a bug in your program, it's most
+      likely a bug in glibc, thanks for the report
+    <paravoid> I think it all boils down to a problem cancelling a thread in
+      poll()
+    <youpi> yes
+    <youpi> paravoid: ok, actually with the latest libc it does work
+    <paravoid> oh?
+    <youpi> where latest = not uploaded yet :/
+    <paravoid> did you test this on exodar?
+    <youpi> pinotree: that's the libpthread_cancellation.diff I guess
+    <paravoid> because I commented out the join :)
+    <youpi> paravoid:  in the root, yes
+    <youpi> well, I tried my own program
+    <paravoid> oh, okay
+    <youpi> which is indeed hanging inside select (or just read) in the chroot
+    <youpi> but not in the root
+    <pinotree> ah, richard's patch
+    <paravoid> url?
+    <youpi> I've installed the build-dep in the root, if you want to try
+    <paravoid> strange that root is newer than the chroot :)
+    <youpi> paravoid: it's the usual eglibc debian source
+    <paravoid> tried in root, still fails
+    <youpi> could you keep the process running?
+    <paravoid> done
+    <youpi> Mmm, but the thread running gdmaps_reload_thread never set the
+      cancel type to async?
+    <youpi> that said I guess read and select are supposed to be cancellation
+      points
+    <youpi> thus cancel_deferred should be working, but they are not
+    <youpi> it seems it's cancellation points which have just not been
+      implemented
+    <youpi> (they happen to be one of the most obscure things in posix)
+
+
+## IRC, freenode, #hurd, 2013-04-15
+
+    <youpi> but yes, there is still an issue, with PTHREAD_CANCEL_DEFERRED
+    <youpi> how calls like read() or select() are supposed to test
+      cancellation?
+    <pinotree> iirc there are the LIBC_CANCEL_* macros in glibc
+    <pinotree> eg sysdeps/unix/sysv/linux/pread.c
+    <youpi> yes
+    <youpi> but in our libpthredaD?
+    <pinotree> could it be we lack the libpthread → glibc bridge of
+      cancellation stuff?
+    <youpi> we do have pthread_setcancelstate/type forwards
+    <youpi> but it seems the default LIBC_CANCEL_ASYNC is void
+    <pinotree> i mean, so when you cancel a thread, you can get that cancel
+      status in libc proper, just like it seems done with LIBC_CANCEL_* macros
+      and nptl
+    <youpi> as I said, the bridge is there
+    <youpi> we're just not using it in glibc
+    <youpi> I'm writing an open_issues page
+
+
+### IRC, freenode, #hurd, 2013-04-16
+
+    <braunr> youpi: yes, we said some time ago that it was lacking
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 768dca93..cd39328f 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -1324,7 +1324,7 @@ License|/fdl]]."]]"""]]
       device_map() -- but IIRC the only one that does (besides mem of course)
       is maptime -- which is not a real driver either...
 
-[[Mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]].
+[[Mapped-time_interface|microkernel/mach/gnumach/interface/device/time]].
 
     <braunr> oh btw, i didn't know you had a blog :)
     <antrik> well, it would be possible to replace the device interface by
diff --git a/open_issues/vdso.mdwn b/open_issues/vdso.mdwn
index 2b2d2805..76c43aa8 100644
--- a/open_issues/vdso.mdwn
+++ b/open_issues/vdso.mdwn
@@ -35,7 +35,7 @@ Having vDSO code might be useful for:
 
   * `mach_*_self`: `mach_host_self`, `mach_task_self`, `mach_thread_self`?
 
-  * [[mapped-time_interface|master/microkernel/mach/gnumach/interface/device/time]]
+  * [[mapped-time_interface|microkernel/mach/gnumach/interface/device/time]]
 
     Every application can then use that via the regular
     `gettimeofday`/`clock_gettime` and similar calls instead of using the