From 016433b123ce4b60eee550dbdb7812ba623d16e7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 30 Aug 2011 12:03:36 +0200 Subject: Minor tweaks. --- open_issues/e2fsck_i_file_acl_hi.mdwn | 5 +- open_issues/libpthread_dlopen.mdwn | 14 +++--- open_issues/perl.mdwn | 13 ++--- open_issues/runit.mdwn | 57 +++++++++------------- open_issues/sync_but_still_unclean_filesystem.mdwn | 5 +- open_issues/virtualbox.mdwn | 30 ++++++------ 6 files changed, 56 insertions(+), 68 deletions(-) (limited to 'open_issues') diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn index f055babe..d03b733c 100644 --- a/open_issues/e2fsck_i_file_acl_hi.mdwn +++ b/open_issues/e2fsck_i_file_acl_hi.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 @@ -34,4 +34,5 @@ IRC, unknown channel, unknown date. k but it's always passive translator nodes -This is due to an erroneous read/write from e2fsck, see http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406 +This is due to an erroneous read/write from e2fsck, see +. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 0cd761f2..0d3628ec 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -15,7 +15,7 @@ IRC, OFTC, #debian-hurd, 2011-07-21. there's one known issue with pthreads you can't dlopen() it -[ if the main application is not already linked against it ] +... if the main application is not already linked against it. which also means you can't dlopen() a module which depends on it if the main application hasn't used -lpthread already @@ -43,12 +43,12 @@ The fix thus being: link the main application with -lpthread. The same symptom appears in an odd case, for instance: -buildd@hurd:~$ ldd /usr/bin/openjade - libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) - libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) - libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) - libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) -... + buildd@hurd:~$ ldd /usr/bin/openjade + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) + libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) + libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) + libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) + [...] openjade links against *both* libthreads and libpthread. The result is that libc early-initializes libthreads only, and thus libpthread is not early-initialized, diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn index c7428cb5..45680328 100644 --- a/open_issues/perl.mdwn +++ b/open_issues/perl.mdwn @@ -10,16 +10,13 @@ License|/fdl]]."]]"""]] [[!meta title="Foster Perl programming"]] -A dependency loop in Debian GNU/Hurd currently leads to +[[!template id=note text="""**2011-08**. A dependency loop in Debian GNU/Hurd +currently leads to: *Could not perform immediate configuration on 'perl'*. +Easy workaround: -`Could not perform immediate configuration on 'perl'` - -Simply use - -`apt-get install perl perl-base -o APT::Immediate-Configure=false` - -to break the loop. + # apt-get install perl perl-base -o APT::Immediate-Configure=false +"""]] Resolve issues uncovered by Perl's test suite, and enable Hurd-specific diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index 6b336ef7..659b81ea 100644 --- a/open_issues/runit.mdwn +++ b/open_issues/runit.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 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 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] @@ -26,36 +27,24 @@ Originally answered by Samuel Thibault: Usual issue with rpctrace: it does not support fork(). -I've checked a backtrace in gdb, got this: - - 0x0105af6c in mach_msg_trap () - at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 - -1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, - timeout=1000020, notify=0) at msg.c:110 - -2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, - timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 - -3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 - -4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 - -5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 - - -and main() shows up as: - - sig_unblock(sig_term); - - sig_unblock(sig_child); - - -> iopause(x, 2 +haslog, &deadline, &now); - - sig_block(sig_term); - - sig_block(sig_child); - + I've checked a backtrace in gdb, got this: + + 0x0105af6c in mach_msg_trap () + at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, + timeout=1000020, notify=0) at msg.c:110 + 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, + timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 + 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 + 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 + 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 + + and main() shows up as: + + sig_unblock(sig_term); + sig_unblock(sig_child); + -> iopause(x, 2 +haslog, &deadline, &now); + sig_block(sig_term); + sig_block(sig_child); So it simply looks like the known "signals don't interrupt select" bug. - diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn index 8a0b1d49..c8a37169 100644 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -33,6 +33,5 @@ Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk synchronization internally upon translator shutdown, but evidently it doesn't in all cases. - Apparently diskfs simply does not set filesystem as readonly: - - http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html +Apparently diskfs simply does not set filesystems as read-only: +. diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn index 246313ff..9440284f 100644 --- a/open_issues/virtualbox.mdwn +++ b/open_issues/virtualbox.mdwn @@ -8,15 +8,16 @@ 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="xattr: extended attributes"]] - [[!tag open_issue_gnumach]] Running GNU Mach in VirtualBox crashes during initialization. IRC, freenode, #hurd, 2011-08-15 - HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once you see the Grub menu, turn off the debian hurd box. 3) Let the box boot normally, and wait for the error/crash/reboot. 4) The error/crash will happen twice and it's reboot automatically. The 3rd boot will success. + HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once + you see the Grub menu, turn off the debian hurd box. 3) Let the box boot + normally, and wait for the error/crash/reboot. 4) The error/crash will + happen twice and it's reboot automatically. The 3rd boot will success. root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54 copyoutmsg @@ -28,8 +29,8 @@ IRC, freenode, #hurd, 2011-08-15 i386/i386/locore.S:1289 is - movl $USER_DS,%eax /* use user data segment for accesses */ -=> mov %ax,%es + movl $USER_DS,%eax /* use user data segment for accesses */ + => mov %ax,%es State is @@ -66,14 +67,14 @@ IRC, freenode, #hurd, 2011-08-15 i386/i386/locore.S:527 is: -_return_from_kernel: -_kret_popl_gs: - popl %gs /* restore segment registers */ -_kret_popl_fs: - popl %fs -_kret_popl_es: -=> popl %es -_kret_popl_ds: + _return_from_kernel: + _kret_popl_gs: + popl %gs /* restore segment registers */ + _kret_popl_fs: + popl %fs + _kret_popl_es: + => popl %es + _kret_popl_ds: cs: 0x8 ds: 0x10 @@ -93,5 +94,6 @@ _kret_popl_ds: efl: 0x10216 looks again like a $USER_DS issue - what's interesting is that that one means that $USER_DS did load in %es fine at least once + what's interesting is that that one means that $USER_DS did load in + %es fine at least once and it's the reload that fails -- cgit v1.2.3