From 63293246d06784612c7dd991eb5575885910b7bb Mon Sep 17 00:00:00 2001 From: "http://jeremie.koenig.myopenid.com/" Date: Fri, 22 Jul 2011 02:09:20 +0200 Subject: recommend sync prior to halt --- hurd/faq/off.mdwn | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'hurd') diff --git a/hurd/faq/off.mdwn b/hurd/faq/off.mdwn index 363436b0..f1749688 100644 --- a/hurd/faq/off.mdwn +++ b/hurd/faq/off.mdwn @@ -19,3 +19,16 @@ will not work. Simply use the equivalent shortcut $ halt which is provided natively on GNU/Hurd, instead of from SYSV runlevels. + +## Unmounting bug + +Sometimes the root file system is not unmounted cleanly +even when the `halt` command is used to shutdown the system. +Therefore we recommend you use the following command: + + $ sync + +and wait a few seconds before issuing the `halt` command. +An `fsck` may still be triggered on the next boot, +and you may encounter the [[open_issues/e2fsck_i_file_acl_hi]] bug, +but these errors are harmless. -- cgit v1.2.3 From d0d1e7f069a370003b1a889b9c6f61822bba44fd Mon Sep 17 00:00:00 2001 From: "http://jeremie.koenig.myopenid.com/" Date: Fri, 22 Jul 2011 02:26:39 +0200 Subject: link to sync_but_still_unclean_filesystem instead --- hurd/faq/off.mdwn | 15 +++------------ 1 file changed, 3 insertions(+), 12 deletions(-) (limited to 'hurd') diff --git a/hurd/faq/off.mdwn b/hurd/faq/off.mdwn index f1749688..64009101 100644 --- a/hurd/faq/off.mdwn +++ b/hurd/faq/off.mdwn @@ -20,15 +20,6 @@ will not work. Simply use the equivalent shortcut which is provided natively on GNU/Hurd, instead of from SYSV runlevels. -## Unmounting bug - -Sometimes the root file system is not unmounted cleanly -even when the `halt` command is used to shutdown the system. -Therefore we recommend you use the following command: - - $ sync - -and wait a few seconds before issuing the `halt` command. -An `fsck` may still be triggered on the next boot, -and you may encounter the [[open_issues/e2fsck_i_file_acl_hi]] bug, -but these errors are harmless. +Note that due to a bug, +we [[recommend you run syncfs|open_issues/sync_but_still_unclean_filesystem]] +prior to issuing the `halt` command. -- cgit v1.2.3 From 088ca85671518ac9033904dae6444d7d532586d4 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 22 Jul 2011 09:41:11 +0200 Subject: IRC. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 18 +++++++++++ .../gnumach_vm_map_entry_forward_merging.mdwn | 11 +++++++ open_issues/libpthread_dlopen.mdwn | 36 ++++++++++++++++++++++ 3 files changed, 65 insertions(+) create mode 100644 open_issues/libpthread_dlopen.mdwn (limited to 'hurd') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index b66af7de..64e3776e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -166,3 +166,21 @@ IRC, freenode, #hurd, 2011-03-28 mentoring the previous procfs implementation (though I never got around to look at his buggy code...) ok + +IRC, freenode, #hurd, 2011-07-22 + + hm, why /proc/$pid/stat is 600 instead of 644 of linux? + pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + (it's available through the ps command which is setuid root) + we discussed at some point making it 644, IIRC. + hm, then why is it not a problem on eg linux? + (btw you can change it with the -s option.) + pinotree, it's not a problem because the information is not that + sensitive, but when rewriting procfs I preferred to play it self and + consider it's not procfs' job to decide what is sensitive or not. + IIRC it's not sensitive but you need the task port to query it. + like, thread times or something. + status is 644 though + but status contains information which anyone can ask to the proc + server anyway, I think. diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index b2b20c5b..f1c8bd6e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -171,6 +171,17 @@ License|/fdl]]."]]"""]] entries) +# IRC, freenode, #hurd, 2011-07-21 + + tschwinge: you may remove the forward map entry merging issue :/ + what did you discover? + tschwinge: it's actually much more complicated than i thought, and + needs major changes in the vm, and about the way anonymous memory is + handled + from what i could see, part of the problem still exists in freebsd + for the same reasons (shadow objects being one of them) + + # Procedure * Analyze. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..f60c81a4 --- /dev/null +++ b/open_issues/libpthread_dlopen.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_libpthread]] + +IRC, OFTC, #debian-hurd, 2011-07-21. + + there's one known issue with pthreads + you can't dlopen() it + which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + (so as to get libpthread initialized early, not at the dlopen() + call) + I get this while building simgrid: + cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + /usr/bin/cmake -E create_symlink + /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so + /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so + cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua + lua: + /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: + __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. + Aborted (core dumped) + that's it, yes + (or at least it has the same symptoms) + it would need fixing in lua, not in SG, then, right? + yes + ok, thanks -- cgit v1.2.3 From 4f090e2d9898e8aa03247a041398e3058983023c Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 22 Jul 2011 22:51:23 +0200 Subject: documentation/translator_primer: Be clearer about the actual meaning of settrans -g... I hope this doesn't make it harder to follow. Considering the non-obvious option semantics of settrans, I think it's crucial for newcomers to get the meaning right from the very beginning! --- hurd/documentation/translator_primer.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn index 4586a8e6..e5c8c160 100644 --- a/hurd/documentation/translator_primer.mdwn +++ b/hurd/documentation/translator_primer.mdwn @@ -41,7 +41,11 @@ Then you setup the translator /hurd/hello in the file/node hello. After that you check the contents of the file, and the translator returns "Hello World!". -To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. +To finish it, +you remove the translator from the file "hello" +(and tell any active running instances to go away) +via "settrans -g hello". +Having done that, verify that now the file is empty again. ### Transparent FTP -- cgit v1.2.3