Another bunch of open issues.

7 files changed, 160 insertions, 0 deletions

diff --git a/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
new file mode 100644
index 00000000..4076d8d0
--- /dev/null
+++ b/open_issues/crashes_vs_system_load_cpu_load_rpc_load.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+IRC, unknown channel, unknown date:
+
+    <antrik> I have a theory
+    <antrik> when the system is under CPU load, the ext2 locking issues are more likely to happen
+    <antrik> I'm under the impression, that when doing something disk-intensive (like a compile job) *considerably* more often causes crashes, when doing *any* other activity in parallel -- be it other compile jobs, or CPU-only activities
+    <antrik> thinking about it, I'm not sure whether CPU-intensive is the decisive criterium, or maybe RPC-intensive...
+    <antrik> CPU load doesn't seem to have any effect -- neither alone, nor in combination with other testcases
diff --git a/open_issues/error_message_disk_full.mdwn b/open_issues/error_message_disk_full.mdwn
new file mode 100644
index 00000000..f72cd66a
--- /dev/null
+++ b/open_issues/error_message_disk_full.mdwn
@@ -0,0 +1,14 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+IRC, unknown channel, unknown date:
+
+    <antrik> /usr/bin/install: writing `/usr/src/gnumach-20060408.dfsg.1/debian/gnumach-dbg/boot/gnumach': (os/kern) memory error
+    <antrik> interesting way to tell that the disk is full ;-)
diff --git a/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn
new file mode 100644
index 00000000..817dac76
--- /dev/null
+++ b/open_issues/libgomp_pthread_attr_setstacksize_pthread_stack_min.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2010 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_libpthread]]
+
+IRC, unknown channel, unknown date:
+
+    <azeem> neal: libgomp (GNU's implementation of OpenMP) uses PTHREAD_STACK_MIN, which we do not define apparently
+    <neal> azeem: We have fixed sized stacks.
+    <neal> so the pthread_attr_setstacksize will fail once you define PTHREAD_STACK_MIN)
diff --git a/open_issues/subhurd_error_messages.mdwn b/open_issues/subhurd_error_messages.mdwn
new file mode 100644
index 00000000..46b58fa4
--- /dev/null
+++ b/open_issues/subhurd_error_messages.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2010 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, unknown channel, unknown date:
+
+    <antrik> BTW, many things in a subhurd print various error messages that are never visible on a normal Hurd...
diff --git a/open_issues/system_crash_nmap.mdwn b/open_issues/system_crash_nmap.mdwn
new file mode 100644
index 00000000..25d9a1c6
--- /dev/null
+++ b/open_issues/system_crash_nmap.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2010 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, unknown channel, unknown date:
+
+    <Casper_> Hmm, `nmap hurd -p 1-` seems to reliably make a hurd machine reboot.
diff --git a/open_issues/system_crash_pflocal_fifo.mdwn b/open_issues/system_crash_pflocal_fifo.mdwn
new file mode 100644
index 00000000..1dddc44e
--- /dev/null
+++ b/open_issues/system_crash_pflocal_fifo.mdwn
@@ -0,0 +1,41 @@
+[[!meta copyright="Copyright © 2010 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, unknown channel, unknown date:
+
+`cat < /dev/zero | cat > /dev/null` will eventually make the system crash,
+likewise when using a FIFO.
+
+    <antrik> hm... VM activity seems much higher when running fifo than pfinet... may be the cause
+    <antrik> "zero filled" and "page faults" are serveral times higher with pipe than with pfinet
+    <antrik> (cow faults however are about the same...)
+    <antrik> pflocal is about the same as fifo
+    
+    <antrik> no, because it usually takes like 20 minutes until it crashes, sometimes much longer
+    
+    <antrik> not sure, but the longest so far was in the range of hours IIRC
+    
+    <antrik> I think I never tested what happens on "cat /dev/zero >/dev/null"... another thing yet to try
+    
+    <antrik> Linux BTW seems to employ some major VM trickery in this case -- dd shows a transfer rate of 10 GB/s...
+    
+    <antrik> no, no anomalies in vmstat
+    <antrik> the only observation I made is that number of page faults and some other number rise pretty quickly with pflocal and fifo, but not with pfinet
+    <antrik> I guess that's somehow related to the fact that pfinet doesn't crash -- though I guess the difference is simply that pfinet is way slower...
+    <antrik> (haven't checked that, though)
+    
+    <antrik> BTW, I'm not sure you got it right: the test case is "cat /dev/zero|cat >/dev/null", *not* "cat /dev/zero >/dev/null"
+    
+    <antrik> OK, "cat /dev/zero|tail -c 1" also crashes, so it's definitely not related to /dev/null
+    <antrik> "dd if=/dev/zero|tail -c 1" crashes as well
+    <antrik> but "tail -c 1 /dev/zero" doesn't seem to
+    <antrik> cool... running multiple instances of the pipe test also considerably speeds up the crash
diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
new file mode 100644
index 00000000..72af3f35
--- /dev/null
+++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
@@ -0,0 +1,41 @@
+[[!meta copyright="Copyright © 2010 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="ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)'"]]
+
+[[!tag open_issue_hurd]]
+
+<http://bugs.debian.org/46859>, <http://bugs.debian.org/195360>
+
+IRC, unknown channel, unknown date:
+
+    <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed
+    <youpi> I actually don't understand this assertion
+    <youpi> it's just before __spin_lock (&ss->critical_section_lock);
+    <youpi> why should one check that a lock is free before taking it ?
+    <youpi> just the same in hurdexec.c
+    <youpi> (no, ss is not our own sigstate, so it's not safe to assume no other path can take it)
+    <youpi> there's another one in sysdeps/mach/hurd/spawni.c
+    <youpi> and jmp-unwind.c
+    <antrik> youpi: why do you think it's nonsense?... the fact that we take the lock (so we can't be interrupted) doesn't mean we are willing to wait for others to release the lock... maybe the code path should never be reached while others have a lock, or something
+    <youpi> then it's useless to take the lock
+    <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_ lock here, it's the lock of the thread we want to cancel
+    <antrik> what exactly is cancelling a thread?... (sorry, I don't really have experience with thread programming)
+    <youpi> ~= killing it
+    <antrik> well, we take the lock so nobody can mess with the thread while we are cancelling it, no?...
+    <youpi> yes
+    <youpi> that is fine
+    <youpi> but checking that the lock is free before taking it doesn't make sense
+    <youpi> why nobody should be able to take the lock ?
+    <youpi> and if nobody is, why do we take it ? (since nobody would be able to take it)
+    <antrik> well, maybe after taking the lock, we do some action that might result in others trying to take it...
+    <youpi> nope: look at the code :)
+    <youpi> or maybe the cancel_hook, but I really doubt it
+