diff options
Diffstat (limited to 'open_issues')
301 files changed, 44701 insertions, 163 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn new file mode 100644 index 00000000..2d273ba1 --- /dev/null +++ b/open_issues/64-bit_port.mdwn @@ -0,0 +1,59 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +There is a `master-x86_64` GNU Mach branch. As of 2012-11-20, it only supports +the [[microkernel/mach/gnumach/ports/Xen]] platform. + + +# 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 :) + + +# IRC, freenode, #hurd, 2012-10-03 + + <braunr> youpi: just so you know in case you try the master-x86_64 with + grub + <braunr> youpi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689509 + <youpi> ok, thx + <braunr> the squeeze version is fine but i had to patch the wheezy/sid one + <youpi> I actually hadn't hoped to boot into 64bit directly from grub + <braunr> youpi: there is code in viengoos that could be reused + <braunr> i've been thinking about it for a time now + <youpi> ok + <braunr> the two easiest ways are 1/ the viengoos one (a -m32 object file + converted with objcopy as an embedded loader) + <braunr> and 2/ establishing an identity mapping using 4x1 GB large pages + and switching to long mode, then jumping to c code to complete the + initialization + <braunr> i think i'll go the second way with x15, so you'll have the two :) diff --git a/open_issues/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn new file mode 100644 index 00000000..cbd9b077 --- /dev/null +++ b/open_issues/active_vs_passive_symlink_translator.mdwn @@ -0,0 +1,44 @@ +[[!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 open_issue_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + +Set an *active* (not *passive*) `/hurd/symlink` translator on a node. + + < antrik> that's strange: the file doesn't look like a symlink in ls output + -- but it behaves like one... + < antrik> using firmlink instead of symlink yields less confusing + results... + < gg0> how does it behaves like one? + < antrik> perhaps the symlink mechanism only fully works for a passive + symlink translator, not an active one + < antrik> gg0: if you access it, you actually get the linked file contents + < antrik> it's only ls that's confused + < antrik> it might be because ls -l uses O_NOFOLLOW, which results in + O_NOTRANS, so it sees the original file contents + < gg0> stat says it's still 12264 bytes + < antrik> stat also seems to use NOFOLLOW + < antrik> wc will show the "correct" size + < gg0> ok + < antrik> if you set it as passive translator, it works as expected... but + then you better don't forget removing it, as it won't go away after a + reboot :-) + < antrik> but as I said, you can just ignore the weirdness -- or use + firmlink instead + < antrik> the thing is, if symlink is set as a passive translator, the + filesystem handles it specially, so it really looks like a symlink to + programs using NOFOLLOW. that's not the case with an active symlink... so + programs using NOFOLLOW simply do not see the active symlink at all + < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to + file + + * [[hurd/translator/short-circuiting]] diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn new file mode 100644 index 00000000..caf447dd --- /dev/null +++ b/open_issues/address_space_memory_mapping_entries.mdwn @@ -0,0 +1,19 @@ +[[!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-05-07 + + <braunr> and as a last example: memory mapping is heavily used in the hurd, + but for some reason, the map entries in an address space are still on a + linked list + <braunr> a bare linked list + <braunr> which makes faults and page cache lookups even slower diff --git a/open_issues/adduser.mdwn b/open_issues/adduser.mdwn index 23552301..713a1dd3 100644 --- a/open_issues/adduser.mdwn +++ b/open_issues/adduser.mdwn @@ -13,10 +13,10 @@ is included in the section entitled [[!tag open_issue_porting]] `adduser` does work as expected, the following warnings are spurious, they just -appear when one doesn't have the nscd package. They do not appear on linux boxes -because there posix_spawn doesn't report ENOENT for exec(). Posix indeed says +appear when one doesn't have the nscd package. They do not appear on Linux boxes +because there posix_spawn doesn't report ENOENT for exec(). POSIX indeed says that `if the error occurs after the calling process successfully returns, the -child process shall exit with exit status 127'. The hurd however reports all +child process shall exit with exit status 127'. The Hurd however reports all errors, thus the warning. $ sudo adduser foo @@ -34,3 +34,4 @@ errors, thus the warning. Copying files from `/etc/skel' ... [...] +Reported at [[!debbug 623199]]. diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn new file mode 100644 index 00000000..3255683c --- /dev/null +++ b/open_issues/alarm_setitimer.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 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="alarm/setitimer"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +`setitimer()`, called by `alarm()` when setting a new alarm, it is not able +to disable on its own the timer when the alarm is fired the first time. +On the other hand, manually invoking `alarm(0)` can cancel the running timer +for `SIGALRM`. + +See also the attached file: on other OSes (e.g. Linux) it blocks waiting +for a signal, while on GNU/Hurd it gets a new alarm and exits. + +[[alrm.c]] + + +# IRC, freenode, #hurd, 2012-07-29 + + <braunr> our setitimer is bugged + <braunr> it seems doesn't seem to leave a timer disarmed when the interval + is set to 0 + <braunr> (which means a one shot timer is actually periodic ..) diff --git a/open_issues/alarm_setitimer/alrm.c b/open_issues/alarm_setitimer/alrm.c new file mode 100644 index 00000000..689020ee --- /dev/null +++ b/open_issues/alarm_setitimer/alrm.c @@ -0,0 +1,32 @@ +#include <signal.h> +#include <stdio.h> +#include <stdlib.h> +#include <unistd.h> + +static const char msg[] = "< got alarm\n"; + +static void sighandler(int signo __attribute__((unused))) +{ + write(STDOUT_FILENO, msg, sizeof(msg) - 1); +} + +int main() +{ + struct sigaction sa; + sa.sa_handler = sighandler; + sigemptyset(&sa.sa_mask); + sa.sa_flags = 0; + if (sigaction(SIGALRM, &sa, NULL) == -1) + return 1; + + printf("> alarm in 2 secs...\n"); + alarm(2); + pause(); + + printf("> alarm!\n"); + + pause(); + printf("> got a signal...\n"); + + return 0; +} diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn new file mode 100644 index 00000000..3e585876 --- /dev/null +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -0,0 +1,349 @@ +[[!meta copyright="Copyright © 2011, 2012 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]]."]]"""]] + +[[!taglink open_issue_documentation]] + +A bunch of this should also be covered in other (introductionary) material, +like Bushnell's Hurd paper. All this should be unfied and streamlined. + +[[!toc]] + + +# 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 + dependency relations between those units(roughly, nothing too pedantic + for now) + <antrik> there is GNU Mach (the microkernel); there are the server + libraries in the Hurd package; there are the actual servers in the same; + and there is the POSIX implementation layer in glibc + <antrik> relations are a bit tricky + <antrik> Mach is the base layer which implements IPC and memory management + <foocraft> hmm I'll probably allocate time for dependency graph generation, + in the worst case + <antrik> on top of this, the Hurd servers, using the server libraries, + implement various aspects of the system functionality + <antrik> client programs use libc calls to use the servers + <antrik> (servers also use libc to communicate with other servers and/or + Mach though) + <foocraft> so every server depends solely on mach, and no other server? + <foocraft> s/mach/mach and/or libc/ + <antrik> I think these things should be pretty clear one you are somewhat + familiar with the Hurd architecture... nothing really tricky there + <antrik> no + <antrik> servers often depend on other servers for certain functionality + + +# 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? + <antrik> I/O is presently completely in Mach + <antrik> filesystems are in userspace + <antrik> the root filesystem and exec server are loaded by grub + <dEhiN> o I see + <dEhiN> so in order to start hurd, you would have to start mach and + simultaneously start the root filesystem and exec server? + <antrik> not exactly + <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts + the servers according to the multiboot information passed from GRUB + <dEhiN> ok, so does GRUB load them into ram? + <dEhiN> I'm trying to figure out in my mind how hurd is initially started + up from a low-level pov + <antrik> yes, as I said, GRUB loads them + <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a + veteran of monolithic kernels + <dEhiN> although I just learned that windows nt is a hybrid kernel which I + never knew! + <rm> note there's a /hurd/ext2fs.static + <rm> I belive that's what is used initially... right? + <antrik> yes + <antrik> loading the shared libraries in addition to the actual server + would be unweildy + <antrik> so the root FS server is linked statically instead + <dEhiN> what does the root FS server do? + <antrik> well, it serves the root FS ;-) + <antrik> it also does some bootstrapping work during startup, to bring the + rest of the system up + + +# Source Code Documentation + +Provide a cross-linked sources documentation, including generated files, like +RPC stubs. + + * <http://www.gnu.org/software/global/> + + +# [[Hurd_101]] + + +# [[hurd/IO_path]] + +Need more stuff like that. + + +# 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 + + +# IRC, OFTC, #debian-hurd, 2011-11-02 + + <sekon_> is __dir_lookup a RPC ?? + <sekon_> where can i find the source of __dir_lookup ?? + <sekon_> grepping most gives out rvalue assignments + <sekon_> -assignments + <sekon_> but in hurs/fs.h it is used as a function ?? + <pinotree> it should be the mig-generated function for that rpc + <sekon_> how do i know how its implemented ?? + <sekon_> is there any way to delve deeprer into mig-generated functions + <tschwinge> sekon_: The MIG-generated stuff will either be found in the + package's build directory (if it's building it for themselves), or in the + glibc build directory (libhurduser, libmachuser; which are all the + available user RPC stubs). + <tschwinge> sekon_: The implementation can be found in the various Hurd + servers/libraries. + <tschwinge> sekon_: For example, [hurd]/libdiskfs/dir-lookup.c. + <tschwinge> sekon_: What MIG does is provide a function call interface for + these ``functions'', and the Mach microkernel then dispatches the + invocation to the corresponding server, for example a /hurd/ext2fs file + system (via libdiskfs). + <tschwinge> sekon_: This may help a bit: + http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html + + +# IRC, freenode, #hurd, 2012-01-08 + + <abique> can you tell me how is done in hurd: "ls | grep x" ? + <abique> in bash + <youpi> ls's standard output is a port to the pflocal server, and grep x's + standard input is a port to the pflocal server + <youpi> the connexion between both ports inside the pflocal server being + done by bash when it calls pipe() + <abique> youpi, so STDOUT_FILENO, STDIN_FILENO, STDERR_FILENO still exists + ? + <youpi> sure, hurd is compatible with posix + <abique> so bash 1) creates T1 (ls) and T2 (grep), then create a pipe at + the pflocal server, then connects both ends to T1 and T2, then start(T1), + start(T2) ? + <youpi> not exactly + <youpi> it's like on usual unix, bash creates the pipe before creating the + tasks + <youpi> then forks to create both of them, handling them each side of the + pipe + <abique> ok I see + <youpi> s/handling/handing/ + <abique> but when you do pipe() on linux, it creates a kernel object, this + time it's 2 port on the pflocal ? + <youpi> yes + <abique> how are spawned tasks ? + <abique> with fork() ? + <youpi> yes + <youpi> which is just task_create() and duplicating the ports into the new + task + <abique> ok + <abique> so it's easy to rewrite fork() with a good control of duplicated + fd + <abique> about threading, mutexes, conditions, etc.. are kernel objects or + just userland objects ? + <youpi> just ports + <youpi> (only threads are kernel objects) + <abique> so, about efficiency, are pipes and mutexes efficient ? + <youpi> depends what you call "efficient" + <youpi> it's less efficient than on linux, for sure + <youpi> but enough for a workable system + <abique> maybe hurd is the right place for a userland thread library like + pth or any fiber library + <abique> ? + <youpi> hurd already uses a userland thread library + <youpi> libcthreads + <abique> is it M:N ? + <youpi> libthreads, actually + <youpi> yes + <abique> nice + <abique> is the task scheduler in the kernel ? + <youpi> the kernel thread scheduler, yes, of course + <youpi> there has to be one + <abique> are the posix open()/readdir()/etc... the direct vfs or wraps an + hurd layer libvfs ? + <youpi> they wrap RPCs to the filesystem servers + <antrik> the Bushnell paper is probably the closest we have to a high-level + documentation of these concepts... + <antrik> the Hurd does not have a central VFS component at all. name + lookups are performed directly on the individual FS servers + <antrik> that's probably the most fundamental design feature of the Hurd + <antrik> (all filesystem operations actually, not only lookups) + + +## IRC, freenode, #hurd, 2012-01-09 + + <braunr> youpi: are you sure cthreads are M:N ? i'm almost sure they're 1:1 + <braunr> and no modern OS is a right place for any thread userspace + library, as they wouldn't have support to run threads on different + processors (unless processors can be handled by userspace servers, but + still, it requires intimate cooperation between the threading library and + the kernel/userspace server in any case + <youpi> braunr: in libthreads, they are M:N + <youpi> you can run threads on different processors by using several kernel + threads, there's no problem in there, a lot of projects do this + <braunr> a pure userspace library can't use kernel threads + <braunr> at least pth was explacitely used on systems like bsd at a time + when they didn't have kernel threads exactly for that reason + <braunr> explicitely* + <braunr> and i'm actually quite surprised to learn that we have an M:N + threading model :/ + <youpi> why do you say "can't" ? + <braunr> but i wanted to reply to abique and he's not around + <youpi> of course you need kernel threads + <youpi> but all you need is to bind them + <braunr> well, what i call a userspace threading library is a library that + completely implement threads without the support of the kernel + <braunr> or only limited support, like signals + <youpi> errr, you can't implement anything with absolutely no support of + the kernel + <braunr> pth used only SIGALRM iirc + <youpi> asking for more kernel threads to use more processors doesn't seem + much + <braunr> it's not + <braunr> but i'm refering to what abique said + <braunr> 01:32 < abique> maybe hurd is the right place for a userland + thread library like pth or any fiber library + <youpi> well, it's indeed more, because the glibc lets external libraries + provide their mutex + <youpi> while on linux, glibc doesn't + <braunr> i believe he meant removing thread support from the kernel :p + <youpi> ah + <braunr> and replying "nice" to an M:N threading model is also suspicious, + since experience seems to show 1:1 models are better + <youpi> "better" ???? + <braunr> yes + <youpi> well + <youpi> I don't have any time to argue about that + <youpi> because that'd be extremely long + <braunr> simpler, so far less bugs, and also less headache concerning posix + conformance + <youpi> but there's no absolute "better" here + <youpi> but less performant + <youpi> less flexible + <braunr> that's why i mention experience :) + <youpi> I mean experience too + <braunr> why less performant ? + <youpi> because you pay kernel transition + <youpi> because you don't know anything about the application threads + <youpi> etc. + <braunr> really ? + <youpi> yes + <braunr> i fail to see where the overhead is + <youpi> I'm not saying m:n is generally better than 1:1 either + <youpi> thread switch, thread creation, etc. + <braunr> creation is slower, i agree, but i'm not sure it's used frequently + enough to really matter + <youpi> it is sometimes used frequently enough + <youpi> and in those cases it would be a headache to avoid it + <braunr> ok + <braunr> i thought thread pools were used in those cases + <youpi> synchronized with kernel mutexes ? + <youpi> that's still slow + <braunr> it reduces to the thread switch overhead + <braunr> which, i agree is slightly slower + <braunr> ok, i's a bit less performant :) + <braunr> well don't futexes exist just for that too ? + <youpi> yes and no + <youpi> in that case they don't help + <youpi> because they do sleep + <youpi> they help only when the threads are living + <braunr> ok + <youpi> now as I said I don't have to talk much more, I have to leave :) + + +# IRC, freenode, #hurd, 2012-12-06 + + <braunr> spiderweb: have you read + http://www.gnu.org/software/hurd/hurd-paper.html ? + <spiderweb> I'll have a look. + <braunr> and also the beginning of + http://ftp.sceen.net/mach/mach_a_new_kernel_foundation_for_unix_development.pdf + <braunr> these two should provide a good look at the big picture the hurd + attemtps to achieve + <Tekk_> I can't help but wonder though, what advantages were really + achieved with early mach? + <Tekk_> weren't they just running a monolithic unix server like osx does? + <braunr> most mach-based systems were + <braunr> but thanks to that, they could provide advanced features over + other well established unix systems + <braunr> while also being compatible + <Tekk_> so basically it was just an ease of development thing + <braunr> well that's what mach aimed at being + <braunr> same for the hurd + <braunr> making things easy + <Tekk_> but as a side effect hurd actually delivers on the advantages of + microkernels aside from that, but the older systems wouldn't, correct? + <braunr> that's how there could be network file systems in very short time + and very scarce resources (i.e. developers working on it), while on other + systems it required a lot more to accomplish that + <braunr> no, it's not a side effect of the microkernel + <braunr> the hurd retains and extends the concept of flexibility introduced + by mach + <Tekk_> the improved stability, etc. isn't a side effect of being able to + restart generally thought of as system-critical processes? + <braunr> no + <braunr> you can't restart system critical processes on the hurd either + <braunr> that's one feature of minix, and they worked hard on it + <Tekk_> ah, okay. so that's currently just the domain of minix + <Tekk_> okay + <Tekk_> spiderweb: well, there's 1 advantage of minix for you :P + <braunr> the main idea of mach is to make it easy to extend unix + <braunr> without having hundreds of system calls + <braunr> the hurd keeps that and extends it by making many operations + unprivileged + <braunr> you don't need special code for kernel modules any more + <braunr> it's easy + <braunr> you don't need special code to handle suid bits and other ugly + similar hacks, + <braunr> it's easy + <braunr> you don't need fuse + <braunr> easy + <braunr> etc.. + + +# IRC, freenode, #hurd, 2012-12-06 + + <spiderweb> what is the #1 feature that distinguished hurd from other + operating systems. the concept of translators. (will read more when I get + more time). + <braunr> yes, translators + <braunr> using the VFS as a service directory + <braunr> and the VFS permissions to control access to those services + + +# IRC, freenode, #hurd, 2012-12-10 + + <spiderweb> I want to work on hurd, but I think I'm going to start with + minix, I own the minix book 3rd ed. it seems like a good intro to + operating systems in general. like I don't even know what a semaphore is + yet. + <braunr> well, enjoy learning :) + <spiderweb> once I finish that book, what reading do you guys recommend? + <spiderweb> other than the wiki + <braunr> i wouldn't recommend starting with a book that focuses on one + operating system anyway + <braunr> you tend to think in terms of what is done in that specific + implementation and compare everything else to that + <braunr> tannenbaum is not only the main author or minix, but also the one + of the book http://en.wikipedia.org/wiki/Modern_Operating_Systems + <braunr> + http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems + should be a pretty good list :) diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn new file mode 100644 index 00000000..2d8b9038 --- /dev/null +++ b/open_issues/arm_port.mdwn @@ -0,0 +1,238 @@ +[[!meta copyright="Copyright © 2012 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]]."]]"""]] + +Several people have expressed interested in a port of GNU/Hurd for the ARM +architecture. + + +# IRC, freenode, #hurd, 2012-10-09 + + <mcsim> bootinfdsds: There was an unfinished port to arm, if you're + interested. + <tschwinge> mcsim: Has that ever been published? + <mcsim> tschwinge: I don't think so. But I have an email of that person and + I think that this could be discussed with him. + + +## IRC, freenode, #hurd, 2012-10-10 + + <tschwinge> mcsim: If you have a contact to the ARM porter, could you + please ask him to post what he has? + <antrik> tschwinge: we all have the "contact" -- let me remind you that he + posted his questions to the list... + + +## IRC, freenode, #hurd, 2012-10-17 + + <mcsim> tschwinge: Hello. The person who I wrote regarding arm port of + gnumach still hasn't answered. And I don't think that he is going to + answer. + + +# IRC, freenode, #hurd, 2012-11-15 + + <matty3269> Well, I have a big interest in the ARM architecture, I worked + at ARM for a bit too, and I've written my own little OS that runs on + qemu. Is there an interest in getting hurd running on ARM? + <braunr> matty3269: not really currently + <braunr> but if that's what you want to do, sure + <tschwinge> matty3269: Well, interest -- sure!, but we don't really have + people savvy in low-level kernel implementation on ARM. I do know some + bits about it, but more about the instruction set than about its memory + architecture, for example. + <tschwinge> matty3269: But if you're feeling adventurous, by all means work + on it, and we'll try to help as we can. + <tschwinge> matty3269: There has been one previous attempt for an ARM port, + but that person never published his code, and apparently moved to a + different project. + <tschwinge> matty3269: I can help with toolchains (GCC, etc.) things for + ARM, if there's need. + <matty3269> tschwinge: That sounds great, thanks! Where would you recommend + I start (at the moment I've got Mach checked out and am trying to get it + compiled for i386) + <matty3269> I'm guessing that the Mach micro-kernel is all that would need + to be ported or are there arch-dependant bits of code in the server + processes? + <tschwinge> matty3269: + http://www.gnu.org/software/hurd/faq/system_port.html has some + information. Mach is the biggest part, yes. Then some bits in glibc and + libpthread, and even less in the Hurd libraries and servers. + <tschwinge> matty3269: Basically, you'd need equivalents for the i386 (and + similar) directories, yep. + <tschwinge> Though, you may be able to avoid some cruft in there. + <tschwinge> Does building for x86 have any issues? + <tschwinge> matty3269: How is generally your understanding of the Hurd on + Mach system architecture, and on microkernel-based systems generally, and + on Mach in particular? + <matty3269> tschwinge: yes, it seems to be progressing... I've got mig + installed and it's just compiling now + <matty3269> hmm, not too great if I'm honest, I've done mostly monolithic + kernel development so having such low-level processes, such as + scheduling, done in user-space seems a little strinage + <tschwinge> Ah, yes, MIG will need a little bit of porting, too. I can + help with that, but that's not a priority -- first you have to get Mach + to boot at all; MIG will only be needed once you need to deal with RPCs, + so user-land/kernel interaction, basically. Before, you can hack around + it. + <matty3269> tschwinge: I have been running a GNU/Hurd system for a while + now though + <tschwinge> I'm happy to tell you that the schedules is still in the + kernel. ;-) + <tschwinge> OK, good, so you know about the basic ideas. + <braunr> matty3269: there has to be machine specific stuff in user space + <braunr> for initial thread contexts for example + <matty3269> tschwinge: Ok, just got gnumach built + <braunr> but there isn't much and you can easily base your work from the + x86 implementation + <tschwinge> Yes. Mach itself is the more difficult one. + <matty3269> braunr: Yeah, looking around at things, it doesn't seem that + there will be too much work involoved in the user-space stuff + <tschwinge> braunr: Do you know off-hand whether there are some old Mach + research papers describing architecture ports? + <tschwinge> I know there are some describing the memory system (obviously), + and I/O system -- which may help matty3269 to understand the general + design/structure. + <tschwinge> We might want to identify some documents, and make a list. + <braunr> all mach related documentation i have is available here: + ftp://ftp.sceen.net/mach/ + <braunr> (also through http://) + <tschwinge> matty3269: Oh, definitely I'd suggest the Mach 3 Kernel + Principles book. That gives a good description of the Mach architecture. + <matty3269> Great, that's my weekends reading then! + <braunr> you don't need all that for a port + <matty3269> Is it possible to run the gnumach binary standalone with qemu? + <braunr> you won't go far with it + <braunr> you really need at least one program + <braunr> but sure, for a port development, it can easily be done + <braunr> i'd suggest writing a basic static application for your tests once + you reach an advanced state + <braunr> the critical parts of a port are memory and interrupts + <braunr> and memory can be particularly difficult to implement correctly + <tschwinge> matty3269: I once used QEMU's + virtual-FAT-filesystem-from-a-directory-on-the-host, and configured GRUB + to boot from that one, so it was easy to quickly reboot for kernel + development. + <braunr> but the good news is that almost every bsd system still uses a + similar interface + <tschwinge> matty3269: And, you may want to become familiar with QEMU's + built-in gdbserver, and how to connect to and use that. + <braunr> so, for example, you could base your work from the netbsd/arm pmap + module + <tschwinge> matty3269: I think that's better than starting on real + hardware. + <braunr> tschwinge: you can use -kernel with a multiboot binary now + <braunr> tschwinge: and even creating iso images is so fast it's not any + slower + <tschwinge> braunr: Yeah, I thought so, but never checked this out -- + recently I saw in qemu --help's output some »multiboot« thing flashing + by. :-) + <braunr> i think it only supports 32-bits executables though + <matty3269> braunr: Yeah, I just tried passing gnumach as the -kernel + parameter to qemu, but it segged qemu :S + <braunr> otherwise i'd be using it for x15 + <matty3269> qemu: fatal: Trying to execute code outside RAM or ROM at + 0xc0100000 + <braunr> how much ram did you give qemu ? + <matty3269> I used '-m 512' + <braunr> hum, so the -kernel option doesn't correctly implement elf loading + or something like that + <braunr> anyway, i'm not sure how well building gnumach on a non-hurd + system is supported + <braunr> so you may want to simply develop inside your VM for the time + being, and reboot + <matty3269> doing an objdump of it seems fine... + <braunr> ? + <braunr> ah, the gnumach executable is a correct elf image + <braunr> that's not the point + <matty3269> Is there particular reason that mach is linked at 0xc0100000? + <matty3269> or is that where it is expected to be in VM> + <tschwinge> That's my understanding. + <braunr> kernels commmonly sti at high addresses + <braunr> that's the "standard" 3G/1G split for user/kernel space + <matty3269> I think Linux sits at a similar VA for 32-bit + <braunr> no + <matty3269> Oh, I thought it did, I know it does on ARM, the kernel is + mapped to 0xc000000 + <braunr> i don't know arm, but are you sure about this number ? + <braunr> seems to lack a 0 + <matty3269> Ah, yes sorry + <matty3269> so 0xC0000000 + <braunr> 0xc0100000 is just 1 MiB above it + <braunr> the .text section of linux on x86 actually starts at c1000000 + (above 16 MiB, certainly to preserve as much dma-able memory since modern + machines now have a lot more) + <tschwinge> Surely the GRUB multiboot loader is not that much used/tested? + <braunr> unfortunately, no + <braunr> matty3269: FYI, my kernel starts at 0xfff00000 :p + <matty3269> braunr: hmm, you could be right, I know it's arround there + someone + <matty3269> somewhere* + <matty3269> braunr: that's an interesting address :S + <matty3269> braunr: is that the PA address of the kernel or the VA inside a + process? + <braunr> the VA + <matty3269> hmm + <braunr> it can't be a PA + <braunr> such high addresses are normally device memory + <braunr> but don't worry, i have good reasons to have chosen this address + :) + <matty3269> so with gnumach, does the boot-up sequence use PIC until VM is + active and the kernel mapped to the linking address? + <braunr> no + <braunr> actually i'm not certain of the details + <braunr> but there is no PIC + <braunr> either special sections are linked at physical addresses + <braunr> or it relies on the fact that all executable code uses near jumps + <braunr> and uses offsets when accessing data + <braunr> (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB) + <matty3269> hmm, + <matty3269> gah, I need to learn x86 + <braunr> that would certainly help + <matty3269> I've just had a look at boothdr.S; I presume that there must be + something else that is executed before this to setup VM, switch to 32-bit + more etc...? + <matty3269> mode* + <braunr> have a look at the multiboot specification + <braunr> it sets protected mode + <braunr> but not paging + <braunr> (i mean, the boot loader does, before passing control to the + kernel) + <matty3269> Ah, I see + <tschwinge> matty3269: Multiboot should be documented in the GRUB package. + <matty3269> tschwinge: yep, got that, thanks + <matty3269> hmm, I can't find any reference to CR0 in gnumach so paging + must be enabled elsewhere + <matty3269> oh wait, found it + <braunr> $ git grep -i '\<cr0\>' + <braunr> i386/i386/proc_reg.h, linux/dev/include/asm-i386/system.h + <braunr> although i suspect only the first one is relevant to us :) + <matty3269> Yeah, that seems to have the setup code for paging :) + <matty3269> I'm still confused how it could run that without paging or PIC + though + <matty3269> I think I need to watch the boot sequence with qemu + <braunr> it's a bit tricky + <braunr> but actually simple + <braunr> 00:44 < braunr> either special sections are linked at physical + addresses + <braunr> 00:44 < braunr> or it relies on the fact that all executable code + uses near jumps + <braunr> that's really all there is + <braunr> but you shouldn't worry about that i suppose, as the protocol + between the boot loader and an arm kernel will certainly not be the saem + <braunr> same* + <matty3269> indeed, ARM is tricky because memory maps are vastly differnt + on every platform + + +## IRC, freenode, #hurd, 2012-11-21 + + <matty3269> Well, I have a ARM gnumach kernel compiled. It just doesn't + run! :) + <braunr> matty3269: good luck :) diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn new file mode 100644 index 00000000..df7294e9 --- /dev/null +++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn @@ -0,0 +1,79 @@ +[[!meta copyright="Copyright © 2010, 2012 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, unknown channel, unknown date + + <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. + <youpi> it'd be great if we could have backtraces in such case + <youpi> at least just the function names + <youpi> and in this case (static), just addresses would be enough + + +# IRC, freenode, #hurd, 2012-07-19 + +In context of the [[ext2fs_libports_reference_counting_assertion]]. + + <braunr> pinotree: tschwinge: do you know if our packages are built with + -rdynamic ? + <pinotree> braunr: debian's cflags don't include it, so unless the upstream + build systems do, -rdynamic is not added + <braunr> i doubt glibc' backtrace() is able to find debugging symbol files + on its own + <pinotree> what do you mean? + <braunr> the port reference bug youpi noticed is rare + <pinotree> even on linux, a program compiled with normal optimizations (eg + -O2 -g) can give just pointer values in backtrace()'s output + <braunr> core dumps are unreliable at best + +[[crash_server]]. + + <braunr> uh, no, backtrace does give names + <braunr> but not with -fomit-frame-pointer + <braunr> unless the binary is built with -rdynamic + <braunr> at least it used to + <pinotree> not really, when being optimized some steps can be optimized + away (eg inlines) + <braunr> that's ok + <braunr> anyway, the point is i'd like a way that can give us as much + information as possible when the problem happens + <braunr> the stack trace being the most useful imo + <pinotree> do you face issues currently with backtrace()? + <braunr> not tried yet + <braunr> i guess i could make the application trap in the kernel, and fault + there, so we can attach gdb while still in the pager address space :> + <pinotree> that would imply the need for interactivity when the fault + happens, wouldn't it? + <braunr> no + <braunr> it would remain this way until someone comes, hours, days later + <braunr> pinotree: well ok, it would require interactivity, but not *when* + it happens ;p + <braunr> pinotree: right, it needs -rdynamic + + +## IRC, freenode, #hurd, 2012-07-21 + + <braunr> tschwinge: my current "approach" is to introduce an infinite loop + <braunr> it makes the faulting task mapped in often enough to use gdb + through qemu + <braunr> ... :) + <tschwinge> My understanding is that glibc already does have some mechanism + for that: I have seen it print backtraces whendetecting malloc + inconsistencies (double free and the lite). + <braunr> yes, i thought it used the backtrace functions internally though + <braunr> that is, execinfo + <braunr> but this does require -rdynamic + + +# GCC's libbacktrace + +Introduced in GCC commit ecd3459e7bb829202601e3274411135a15c64dde. diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn new file mode 100644 index 00000000..fb8cfd01 --- /dev/null +++ b/open_issues/automatically_checking_port_deallocation.mdwn @@ -0,0 +1,22 @@ +[[!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. + + <youpi> we really need something that is able to automatically check port deallocation + <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing... + <pochu> test suite? :) + <pochu> won't magically find them though, so not what you've asked for... + <youpi> test suites can trigger some of the bugs yes + <youpi> which is already a good thing + <youpi> of course the coverage can't be perfect + <youpi> one of the bugs I fixed happened only for setuid binaries for instance diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn new file mode 100644 index 00000000..47598071 --- /dev/null +++ b/open_issues/bash.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2009 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_porting]] + +# *bash* 4.0 vs. typing `C-c` (*SIGINT*) + +Will show `-bash: echo: write error: (ipc/mig) wrong reply message ID` unter +certain conditions. + +After having noticed that this error doesn't occur if starting *bash* with +`--norc`, I isolated it to the following command in `.bashrc`: + + case $TERM in + xterm* | rxvt*) + PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007"';; + esac + +... and indeed: + + tschwinge@flubber:~ $ echo "$TERM" -- "$PROMPT_COMMAND" + xterm -- echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD}\007" + tschwinge@flubber:~ $ ^C + -bash: echo: write error: (ipc/mig) wrong reply message ID + tschwinge@flubber:~ $ PROMPT_COMMAND= + tschwinge@flubber:~ $ ^C + tschwinge@flubber:~ $ + + bash-4.0$ PROMPT_COMMAND='echo >&2 -n foo\ ' + foo bash-4.0$ ^C + + bash-4.0$ PROMPT_COMMAND='echo >&1 -n foo\ ' + foo bash-4.0$ ^C + bash: echo: write error: (ipc/mig) wrong reply message ID + + bash-4.0$ PROMPT_COMMAND='/bin/echo >&1 -n foo\ ' + foo bash-4.0$ ^C + bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID + +So, there's something different with stdout in / after the SIGINT handler. diff --git a/open_issues/bash_busy-loop.mdwn b/open_issues/bash_busy-loop.mdwn new file mode 100644 index 00000000..5228ba33 --- /dev/null +++ b/open_issues/bash_busy-loop.mdwn @@ -0,0 +1,33 @@ +[[!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]]."]]"""]] + +I've first seen this problem after having had the following command line run +for a week, or two, or three: + +Start `screen`. Find PID of pfinet. + + $ while sleep 66; do echo "$(date)" " $(ps --no-header --format=hurd -p [PID])"; done | tee ps-pfinet + +Leave it running, detach from `screen`. + +Eventually, the main `bash` process will go bonkers and eat 100 % CPU time. +Reproduced on four different systems. + +A faster way to reproduce this, again inside `screen`; every three seconds, +write text in 10 MiB bursts to the terminal: + + $ while sleep 3; do date > tmp/tmp && yes "$(date)" | dd bs=1M count=10; done + +This one only needs like ten hours, before `bash` starts its busy-loop, from +which it can only be terminated with `SIGKILL`. At this point, the `term`, +`screen`, `fifo` processes also have used 40, 52, 25 minutes of CPU time, +respectively, but appear to be still working fine. + +I did not yet start debugging this. diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn new file mode 100644 index 00000000..9feab6ff --- /dev/null +++ b/open_issues/bash_interrupted_system_call.mdwn @@ -0,0 +1,19 @@ +[[!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. + + <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call" + <virtuoso015> is it significant ? + <youpi> I've seen this issue already yes + <youpi> it's not + <youpi> it's bash not handling EINTR properly + <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error? + <youpi> well, it's Hurd generating an error which bash doesn't expect to see diff --git a/open_issues/bash_vs_screen_vs_sigint.mdwn b/open_issues/bash_vs_screen_vs_sigint.mdwn new file mode 100644 index 00000000..9672041c --- /dev/null +++ b/open_issues/bash_vs_screen_vs_sigint.mdwn @@ -0,0 +1,12 @@ +[[!meta copyright="Copyright © 2009 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]]."]]"""]] + + * [[bash]] + * [[screen]] diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn new file mode 100644 index 00000000..afdcfb73 --- /dev/null +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -0,0 +1,132 @@ +[[!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 +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]] + +What are the benefits of a native GNU/Hurd system, now that Linux et al. can do +so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux +and other virtualization techiques, and so on. + +It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... + +IRC, #hurd, August / September 2010 + + <marcusb> ArneBab: but Neal and I were not happy with that alone. We were + looking for deeper improvements to the system, for, I think, sound + reasons. That is what brought us to the L4/Coyotos technologies + <marcusb> ArneBab: as you are writing a kernel in user space, you can still + do kernel improvements there + <marcusb> ArneBab: if you take it very far, you end up with a kernel that + 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]]. + + <marcusb> ArneBab: so, with these different cuts, there are different + opportunities. on the one end, you can run Linux as normal and get some + of the Hurd features such as translators in some programs. At the other + end, you can do whatever you want and run some linux code for the drivers + or none at all. + <marcusb> ArneBab: one of the big questions then becomes: at which point + can the advantages offered by the Hurd be realized? + <marcusb> ArneBab: and that's not entirely clear to me + <marcusb> when I worked on this with Neal, we pushed further and further + into need-to-change-everything land + <marcusb> while the current efforts on the Hurd seem to be more equivalent + to the could-run-it-in-userspace-on-top-of-Linux camp + <ArneBab> marcusb: for that I think we need a way to move towards them step + by step. Would it be possible to get the advantages of better resource + allocation with a Viengoos in userspace, too? + <ArneBab> and when that is stable, just switch over? + <marcusb> ArneBab: I don't know. I suspect these people will know before + us: http://lxc.sourceforge.net/ + <ArneBab> something like implementing flip points: flip Linux with Hurd to + Hund with Linux. Flip Mach with L4 to L4 with Mach. + <ArneBab> lxc sounds interesting. + <marcusb> note that these efforts address security concerns more than other + concerns + <marcusb> so they will get isolation long before sharing is even considered + <marcusb> but some of the issues are the same + <marcusb> once you allow malware to do what it wants, it's a small step to + also allow the user to what he wants :) + <ArneBab> it kinda looks like hacking it where it doesn’t really fit again… + <ArneBab> there I ask myself when the point comes that doing a cleaner + design offsets the popularity + <ArneBab> they are pushing more and more stuff into userspace + <ArneBab> which is a good thing (to me) + <ArneBab> it’s hard to clearly describe how, but even though I like having + more stuff in userspace, the way it is bolted onto Linux doesn’t feel + good for me. + <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to + a non-fuse user + <ArneBab> while in the Hurd, these additional options are on eqal footing. + <marcusb> ArneBab: are they pushing more and more into user space? I don't + think so. I see more of the reverse, actually + <marcusb> or maybe both + <ArneBab> FUSE, lxd and scheduling in userspace move to userspace + <ArneBab> well, KMS moved to the kernel + <ArneBab> to avoid flickering when switching between X and the console? + <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in + Linux, too, or is that just a strange feeling of me? + <ArneBab> marcusb: and that splits the users into those who can get stuff + into the kernel and those who can only work in userspace – which I don’t + really like. + <ArneBab> That’s one more advantage of the Hurd: eqal footing for all + (except the Mach hackers, but they have a very limited terrain) + <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have + a principled objection to it (but just wanted a more general solution) + <marcusb> ArneBab: as a side note, although people keep complaining, the + linux kernel seems to be growing steadily, so getting stuff into the + kernel doesn't seem too hard. 8-O + +--- + +IRC, #hurd, 2010-12-28 + + <tim> but is monolithic so bad? + <sartakov> yep + <braunr> no it's not + <braunr> proof: it works very well for most people + [...] + <braunr> the real problem is extensibility and interfaces + <tim> :/ whats the huge advantage of micro-k + <braunr> extensibility + <tim> over? + <braunr> you can add a whole lot of new services for new purposes with new + interfaces without changing the kernel + <tim> oright + <braunr> it basically boils down to the original Unix idea: everything does + one thing well + [...] + <kilobug> well, I would say extensibility and fault-tolerance are the two + key advantages + <braunr> taht's a side effect + <braunr> there are fault taulerant monolithic kernels + [...] + <braunr> tolerant* + <braunr> and the hurd is for now a non fault-tolerant microkernel based OS + :/ + [...] + <kilobug> braunr: not really; you can't ensure fault tolerance for code + running in kernel space, code running in kernel space can do everything, + including reboot, crash, ... + [...] + <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a + well designed/implemented microkernel based os + <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an + ext2fs translator doing a segfault and being restarted is a + fault-tolerance that would be almost impossible to have in Linux + <kilobug> braunr: sure, you can have fault-tolerance with FUSE, but FUSE is + applying micro-kernel paradigm to Linux + [...] + <braunr> the reason i don't care that much about fault tolerance is that + Linux obviously shows a monolithic kernel can run almost flawlessly if + well written + <braunr> but extensibility is really another matter diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn new file mode 100644 index 00000000..5c309d47 --- /dev/null +++ b/open_issues/binutils.mdwn @@ -0,0 +1,255 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 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 stable_URL open_issue_binutils]] + +Here's what's to be done for maintaining GNU Binutils. + +As these tools primarily deal with low-level parts of the target architecture +and the object file format (ELF ABI), which are essentially (at least meant to +be) the same, there shouldn't be many differences comparing the binutils +between the GNU/Hurd and GNU/Linux ports, for example. There are a few, +though, as explained below. + +[[!toc levels=2]] + + +# [[General information|/binutils]] + + +# [[Sources|source_repositories/binutils]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master +-i +/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs: + +--> + +Last reviewed up to the [[Git mirror's 7c102198e4a1ecee9cf175bd4ad87ee435956cae +(2012-12-16) sources|source_repositories/binutils]]. + + * Globally + + * a.out (such as `ld/emulparams/i386linux.sh`, `ld/emultempl/linux.em`, + etc.), COFF, PE image support and 64-bit support are not interesting. + + * In the testsuites, `.exp` and `.d` files very likely should not only + care for `*-*-linux*`, but also `*-*-gnu*`. (If they need to be + conditionalized like this at all.) + + * `bfd/` + + * `config.bfd` + + * `i[3-7]86-*-gnu*` + + Comparing to `i[3-7]86-*-linux-*`: + + * `i386linux_vec` -- a.out. + + * `i386pei_vec` -- PE. + + * 64 bit. + + * `configure.host` + + Souldn't need anything. x86 Linux neither. + + * `configure.in` + + Linux: + + * `COREFILE=trad-core.lo` with `TRAD_HEADER='"hosts/i386linux.h"'` + + We don't have any such core file support configured. TODO: should + we? Where is this core file reading exactly used? GDB? + + * `i386linux_vec` -- a.out. + + * `i386pei_vec` -- PE. + + * `binutils/` + + * `configure.tgt` + + * `gas/` + + * `config/te-gnu.h` + + C.f. `te-linux.h`; search tree for `TE_LINUX` vs. `TE_GNU` usage. + + * `tc-i386.h` + + Sole `TE_LINUX` usage is for a.out. + + * `configure.tgt` + + * `ld/` + + * `configure.host` + + * `*-*-gnu*` + + TODO: resolve `crt0.o` vs. `crt1.o` issue. [[Testsuite + failures|binutils#static]]. + + * `configure.tgt` + + * `i[3-7]86-*-gnu*` + + Compare to `i[3-7]86-*-linux-*`, but don't need a.out (`i386linux`) + and 64 bit support. + + * `__ehdr_start symbol`, c84ed8d89d0b8bf5a2968d465f77ac24bcfc40c2 -- can this + be helpful in the exec server, glibc, or elsewhere? Used in GDB (BFD) + commit bdbd9758806ed855af89244870fdc52cf3ff09bc. + + +# Build + +Here's a log of a binutils build run; this is from our [[Git +repository|source_repositories/binutils]]'s `tschwinge/Paul_Desmond` branch, +commit 7c102198e4a1ecee9cf175bd4ad87ee435956cae (2012-12-16), run on +kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../Paul_Desmond/configure --prefix="$PWD".install --enable-gold --with-sysroot=/ SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +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. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test + +--> + + +## Analysis + +x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask +out most of the differences that are due to GNU/Linux supporting more core file +formats, and more emulation vectors. + + $ toolchain/logs/process binutils build + + * gold GNU/Linux vs. GNU/Hurd + + -checking for glibc ifunc support... both + +checking for glibc ifunc support... dyn + + Missing [[IFUNC]] support on GNU/Hurd. + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 150 MiB, and needs roughly 1 min on kepler.SCHWINGE and 3 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process binutils install + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + +# Testsuite + + $ make -k check 2>&1 | tee log_test + [...] + +This needs roughly 6 min on kepler.SCHWINGE and 42 min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process binutils test + + * <a name="static"><!-- stable_URL -->`FAIL: static [...]`</a> + + The testsuite isn't prepared for using `crt0.o` instead of `crt1.o` + depending on whether a static or dynamic executable is created. Documented + in `ld/configure.host`. Perhaps we should finally rewrite this messy code + in glibc? + + * <a name="64ksec">`FAIL: ld-elf/64ksec`</a> + + On the idle grubber, this one takes a few minutes wall time to complete + successfully ([[I/O system + weakness|performance/io_system/binutils_ld_64ksec]]), so assuming some + system load variation, the testsuite's timeout may trigger. + + * <a name="weak"><!-- stable_URL -->`FAIL: ELF weak [...]`</a> + + [[I|tschwinge]] suppose this is due to us having an override w.r.t. weak + symbol handling in glibc, needed for our external [[/libpthread]]. TODO: + document properly. + + * `FAIL: gas/i386/rept` + + Added in commit 06f1247c54126b9f1e6acb8ff8c7be35aec6f44c (2012-06-07) as + part of the fix for [[!sourceware_PR 14201]], renamed in commit + d654e24bbc2f601df4dc43b26049b0339528b93a (2012-06-07): + + WARNING: program timed out. + FAIL: gas/i386/rept + + * ld IFUNC execution tests + + Missing [[IFUNC]] support on GNU/Hurd. + + Added in commit 82c5587db078581cfe94a4385ed99de1d1fa6657 (2012-09-19): + + FAIL: Common symbol override ifunc test 1a + FAIL: Common symbol override ifunc test 1b + + * gold GNU/Linux vs. GNU/Hurd + + -FAIL: relro_test.sh + +PASS: relro_test.sh + + -PASS: ver_matching_test.sh + +FAIL: ver_matching_test.sh + + -PASS: script_test_3 + +FAIL: script_test_3 + + -PASS: tls_phdrs_script_test + +FAIL: tls_phdrs_script_test + + -PASS: ifuncmain1static + -PASS: ifuncmain1picstatic + -PASS: ifuncmain2static + -PASS: ifuncmain2picstatic + -PASS: ifuncmain4static + -PASS: ifuncmain4picstatic + -PASS: ifuncmain5static + -PASS: ifuncmain5picstatic + -PASS: ifuncmain7static + -PASS: ifuncmain7picstatic diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn new file mode 100644 index 00000000..7f860bba --- /dev/null +++ b/open_issues/boehm_gc.mdwn @@ -0,0 +1,435 @@ +[[!meta copyright="Copyright © 2010, 2012 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]]."]]"""]] + +Here's what's to be done for maintaining Boehm GC. + +This one does need Hurd-specific configuration. + +It is, for example, used by [[/GCC]] (which has its own fork), so any changes +committed upstream should very like also be made there. + +[[!toc levels=2]] + + +# [[General information|/boehm_gc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/master +-i +/^commit |^---$|hurd|linux|glibc + +--> + +Last reviewed up to the 5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) +sources, and for `libatomic_ops` to the +6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) sources. + + * `configure.ac` + + * `PARALLEL_MARK` is not enabled; doesn't make sense so far. + + * `*-*-kfreebsd*-gnu` defines `USE_COMPILER_TLS`. What's this, and + why does not other config? + + * TODO + + [ if test "$enable_gc_debug" = "yes"; then + AC_MSG_WARN("Should define GC_DEBUG and use debug alloc. in clients.") + AC_DEFINE([KEEP_BACK_PTRS], 1, + [Define to save back-pointers in debugging headers.]) + keep_back_ptrs=true + AC_DEFINE([DBG_HDRS_ALL], 1, + [Define to force debug headers on all objects.]) + case $host in + x86-*-linux* | i586-*-linux* | i686-*-linux* | x86_64-*-linux* ) + AC_DEFINE(MAKE_BACK_GRAPH) + AC_MSG_WARN("Client must not use -fomit-frame-pointer.") + AC_DEFINE(SAVE_CALL_COUNT, 8) + ;; + AM_CONDITIONAL([KEEP_BACK_PTRS], [test x"$keep_back_ptrs" = xtrue]) + + * `configure.host` + + Nothing. + + * `Makefile.am`, `include/include.am`, `cord/cord.am`, `doc/doc.am`, + `tests/tests.am` + + Nothing. + + * `include/gc_config_macros.h` + + Should be OK. + + * `include/private/gcconfig.h` + + Hairy. But should be OK. Search for *HURD*, compare to *LINUX*, + *I386* case. + + See `doc/porting.html` and `doc/README.macros` (and others) for + documentation. + + *LINUX* has: + + * `#define LINUX_STACKBOTTOM` + + Defined instead of `STACKBOTTOM` to have the value read from `/proc/`. + + * `#define HEAP_START (ptr_t)0x1000` + + May want to define it for us, too? + + * `#ifdef USE_I686_PREFETCH`, `USE_3DNOW_PREFETCH` --- [...] + + Apparently these are optimization that we also could use. Have a + look at *LINUX* for *X86_64*, which uses `__builtin_prefetch` + (which Linux x86 could use, too?). + + * TODO + + #if defined(LINUX) && defined(USE_MMAP) + /* The kernel may do a somewhat better job merging mappings etc. */ + /* with anonymous mappings. */ + # define USE_MMAP_ANON + #endif + + * TODO + + #if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) + /* Nptl allocates thread stacks with mmap, which is fine. But it */ + /* keeps a cache of thread stacks. Thread stacks contain the */ + /* thread control blocks. These in turn contain a pointer to */ + /* (sizeof (void *) from the beginning of) the dtv for thread-local */ + /* storage, which is calloc allocated. If we don't scan the cached */ + /* thread stacks, we appear to lose the dtv. This tends to */ + /* result in something that looks like a bogus dtv count, which */ + /* tends to result in a memset call on a block that is way too */ + /* large. Sometimes we're lucky and the process just dies ... */ + /* There seems to be a similar issue with some other memory */ + /* allocated by the dynamic loader. */ + /* This should be avoidable by either: */ + /* - Defining USE_PROC_FOR_LIBRARIES here. */ + /* That performs very poorly, precisely because we end up */ + /* scanning cached stacks. */ + /* - Have calloc look at its callers. */ + /* In spite of the fact that it is gross and disgusting. */ + /* In fact neither seems to suffice, probably in part because */ + /* even with USE_PROC_FOR_LIBRARIES, we don't scan parts of stack */ + /* segments that appear to be out of bounds. Thus we actually */ + /* do both, which seems to yield the best results. */ + + # define USE_PROC_FOR_LIBRARIES + #endif + + * TODO + + # if defined(GC_LINUX_THREADS) && defined(REDIRECT_MALLOC) \ + && !defined(INCLUDE_LINUX_THREAD_DESCR) + /* Will not work, since libc and the dynamic loader use thread */ + /* locals, sometimes as the only reference. */ + # define INCLUDE_LINUX_THREAD_DESCR + # endif + + * TODO + + # if defined(UNIX_LIKE) && defined(THREADS) && !defined(NO_CANCEL_SAFE) \ + && !defined(PLATFORM_ANDROID) + /* Make the code cancellation-safe. This basically means that we */ + /* ensure that cancellation requests are ignored while we are in */ + /* the collector. This applies only to Posix deferred cancellation;*/ + /* we don't handle Posix asynchronous cancellation. */ + /* Note that this only works if pthread_setcancelstate is */ + /* async-signal-safe, at least in the absence of asynchronous */ + /* cancellation. This appears to be true for the glibc version, */ + /* though it is not documented. Without that assumption, there */ + /* seems to be no way to safely wait in a signal handler, which */ + /* we need to do for thread suspension. */ + /* Also note that little other code appears to be cancellation-safe.*/ + /* Hence it may make sense to turn this off for performance. */ + # define CANCEL_SAFE + # endif + + * `CAN_SAVE_CALL_ARGS` vs. -fomit-frame-pointer now being on by + default for Linux x86 IIRC? (Which is an [[!taglink + open_issue_gcc]] for not including us.) + + * TODO + + # if defined(REDIRECT_MALLOC) && defined(THREADS) && !defined(LINUX) + # error "REDIRECT_MALLOC with THREADS works at most on Linux." + # endif + + + *HURD* has: + + * `#define STACK_GROWS_DOWN` + + * `#define HEURISTIC2` + + Defined instead of `STACKBOTTOM` to have the value probed. + + Linux also has this: + + #if defined(LINUX_STACKBOTTOM) && defined(NO_PROC_STAT) \ + && !defined(USE_LIBC_PRIVATES) + /* This combination will fail, since we have no way to get */ + /* the stack base. Use HEURISTIC2 instead. */ + # undef LINUX_STACKBOTTOM + # define HEURISTIC2 + /* This may still fail on some architectures like IA64. */ + /* We tried ... */ + #endif + + Being on [[glibc]], we could perhaps do similar as `USE_LIBC_PRIVATES` + instead of `HEURISTIC2`. Pro: avoid `SIGSEGV` (and general fragility) + during probing at startup (if I'm understanding this correctly). Con: + rely on glibc internals. Or we instead add support to parse + [[`/proc/`|hurd/translator/procfs]] (can even use the same as Linux?), + or use some other interface. [[!tag open_issue_glibc]] + + * `#define SIG_SUSPEND SIGUSR1`, `#define SIG_THR_RESTART SIGUSR2` + + * We don't `#define MPROTECT_VDB` (WIP comment); but Linux neither. + + * Where does our `GETPAGESIZE` come from? Should we `#include + <unistd.h>` like it is done for *LINUX*? + + * `include/gc_pthread_redirects.h` + + * TODO + + Cancellation stuff is Linux-only. In other places, too. + + * `mach_dep.c` + + * `#define NO_GETCONTEXT` + + [[!taglink open_issue_glibc]], but this is not a real problem here, + because we can use the following GCC internal function without much + overhead: + + * `GC_with_callee_saves_pushed` + + The `HAVE_BUILTIN_UNWIND_INIT` case is ours. + + * `os_dep.c` + + * `read` + + Sure that it doesn't internally (in [[glibc]]) use `malloc`. Probably + only / mostly (?) a problem for `--enable-redirect-malloc` + configurations? Linux with threads uses `readv`. + + * TODO. + + * `dyn_load.c` + + For `DYNAMIC_LOADING`. TODO. + + * `pthread_support.c`, `pthread_stop_world.c` + + TODO. + + * TODO. + + Other files also contain *LINUX* and other conditionals. + + * `libatomic_ops/` + + * `configure.ac` + + Nothing. + + * `Makefile`, `src/Makefile`, `src/atomic_ops/Makefile`, + `src/atomic_ops/sysdeps/Makefile`, `doc/Makefile`, `tests/Makefile` + + Nothing. + + * `src/atomic_ops/sysdeps/gcc/x86.h` + + Nothing. + + * b8b65e8a5c2c4896728cd00d008168a6293f55b1 configure.ac probably not all + correct. + + * `mmap`, b64dd3bc1e5a23e677c96b478d55648a0730ab75 + + * `parallel mark`, 07c2b8e455c9e70d1f173475bbf1196320812154, pass + `--disable-parallel-mark` or enable for us, too? + + * `HANDLE_FORK`, e9b11b6655c45ad3ab3326707aa31567a767134b, + 806d656802a1e3c2b55cd9e4530c6420340886c9, + 1e882b98c2cf9479a9cd08a67439dab7f9622924 + + * Check `include/private/thread_local_alloc.h` re + `USE_COMPILER_TLS`/`USE_PTHREAD_SPECIFIC`. + + +# Build + +Here's a log of a binutils build run; this is from the +5f492b98dd131bdd6c67eb56c31024420c1e7dab (2012-06-08) sources, and for +`libatomic_ops` for the 6a0afde033f105c6320f1409162e3765a1395bfd (2012-05-15) +sources, run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && ln -sfn ../libatomic_ops/master libatomic_ops) + $ (cd ../master/ && autoreconf -vfi) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/bash CC=gcc-4.6 CXX=g++-4.6 --enable-cplusplus --enable-gc-debug --enable-gc-assertions --enable-assertions 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. Using bash instead of dash as otherwise libtool explodes. + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and +X min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-check) 2>&1 | tee log_install && test -f .go-check && { make -k check 2>&1 | tee log_check; (cd libatomic_ops/ && make -k check) 2>&1 | tee log_check_; } + +--> + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_build + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_build* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_build + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_build.sed < toolchain/logs/boehm-gc/linux/log_build) <(sed -f toolchain/logs/boehm-gc/hurd/log_build.sed < toolchain/logs/boehm-gc/hurd/log_build) > toolchain/logs/boehm-gc/log_build.diff + + * only GNU/Linux: `configure: WARNING: "Explicit GC_INIT() calls may be + required."` + + * only GNU/Linux: `configure: WARNING: "Client must not use + -fomit-frame-pointer."` + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around X MiB, and needs roughly X min on kepler.SCHWINGE and X +min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_install + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_install | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_install + $ diff -wu toolchain/logs/boehm-gc/linux/log_install toolchain/logs/boehm-gc/hurd/log_install > toolchain/logs/boehm-gc/log_install.diff + + +# Testsuite + + $ make -k check + [...] + $ (cd libatomic_ops/ && make -k check) + [...] + +This needs roughly X min on kepler.SCHWINGE and X min on coulomb.SCHWINGE. + + +## Analysis + + $ ssh kepler.SCHWINGE 'cd tmp/source/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/linux/log_check + $ ssh coulomb.SCHWINGE 'cd tmp/boehm-gc/ && cat master.build/log_check* | sed -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > toolchain/logs/boehm-gc/hurd/log_check + $ diff -wu <(sed -f toolchain/logs/boehm-gc/linux/log_check.sed < toolchain/logs/boehm-gc/linux/log_check) <(sed -f toolchain/logs/boehm-gc/hurd/log_check.sed < toolchain/logs/boehm-gc/hurd/log_check) > toolchain/logs/boehm-gc/log_check.diff + +There are different configurations possible, but in general, the testsuite +restults of GNU/Linux and GNU/Hurd look very similar. + + * GNU/Hurd is missing `Call chain at allocation: [...]` output. + + `os_dep.c`:`GC_print_callers` + + +# TODO + + * What are other applications to test Boehm GC? Also especially in + combination with [[/libpthread]] and dynamic loading of shared libraries? + + * There are patches (apparently not committed) that GCC itself can use + it, too: <http://gcc.gnu.org/wiki/Garbage_collection_tuning>. + + * There's been some talking about it on GNU guile mailing lists, and two + Git branches (2010-12-15: last change 2009-09). + + * <http://www.hpl.hp.com/personal/Hans_Boehm/gc/#users> + + +## IRC, OFTC, #debian-hurd, 2012-02-05 + +[[!tag open_issue_porting]] + + <pinotree> youpi: i think i found out the possible cause of the ecl and + mono issuess + <pinotree> -s + <youpi> oh + <pinotree> basically, we don't have the realtime signals (so no + SIGRTMIN/SIGRTMAX defined), hence things use either SIGUSR1 or + SIGUSR2... which are used in libgc to resp. stop/resume threads when + "collecting" + <pinotree> i just patched ecl to use SIGINFO instead of SIGUSR1 (used when + no SIGRTMIN+2 is available), and it seems going on for a while + <youpi> uh, why would SIGINFO work better than SIGUSR1? + <pinotree> it was a test, i tried the first "not common" signal i saw + <pinotree> my test was, use any signal different than USR1/2 + <youpi> ah, sorry, I hadn't understood + <youpi> you mean there's a conflict between ecl and mono using SIGUSR1, as + well as libgc? + <pinotree> yes + <pinotree> for example, in ecl sources see src/c/unixint.d, + install_process_interrupt_handler() + <youpi> SIGINFO seems a sane choice + <youpi> SIGPWR could have been a better choice if it was available :) + <pinotree> i would have chose an "unassigned" number, say SIGLOST (the + bigger one) + 10, but it would be greater than _NSIG (and thus discarded) + <youpi> not a good idea indeed + <pinotree> it seems that linux, beside the range for rt signals, has some + "free space" + <pinotree> i'll start now another ecl build, from scratch this time, with + s/SIGUSR1/SIGINFO/ (making sure ctags won't bother), and if it works i'll + update svante's bug + + <pinotree> mmap(...PROT_NONE...) failed + <pinotree> hmm... + <pinotree> apparently enabling MMAP_ANON in mono's libgc copy was a good + step, let's see + + +### IRC, OFTC, #debian-hurd, 2012-03-18 + + <pinotree> youpi: mono is afflicted by the SIGUSR1/2 conflict with libgc + <youpi> pinotree: didn't we have a solution for that? + <pinotree> well, it works just for one signal + <pinotree> the ideal solution would be having a range for RT signals, and + make libgc use RTMIN+5/6, like done on most of other OSes + <youpi> but we don't have RT signals, do we? + <pinotree> right :( + + +### IRC, freenode, #hurd, 2012-03-21 + + <pinotree> civodul: given we have to realtime signals (so no range of + signals for them), libgc uses SIGUSR1/2 instead of using SIGRTMIN+5/6 for + its thread synchronization stuff + <pinotree> civodul: which means that if an application using libgc then + sets its own handlers for either of SIGUSR1/2, hell breaks + <civodul> pinotree: ok + <civodul> pinotree: is it a Debian-specific change, or included upstream? + <pinotree> libgc using SIGUSR1/2? upstream + <civodul> ok diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn new file mode 100644 index 00000000..02dc7f87 --- /dev/null +++ b/open_issues/bpf.mdwn @@ -0,0 +1,595 @@ +[[!meta copyright="Copyright © 2009, 2012 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=BPF]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +This is a collection of resources concerning *Berkeley Packet Filter*s. + + +# Documentation + + * Wikipedia: [[!wikipedia "Berkeley Packet Filter"]] + + * [The Packet Filter: An Efficient Mechanism for User-level Network + Code](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8755), + 1987, Jeffrey C. Mogul, Richard F. Rashid, Michael J. Accetta + + * [The BSD Packet Filter: A New Architecture for User-level Packet + Capture](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.7849), + 1992, Steven Mccanne, Van Jacobson + + * [Protocol Service Decomposition for High-Performance + Networking](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.30.8387), + 1993, Chris Maeda, Brian N. Bershad + + * [Efficient Packet Demultiplexing for Multiple Endpoints and Large + Messages](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.46.44), + 1994, Masanobu Yuhara Fujitsu, Masanobu Yuhara, Brian N. Bershad, Chris + Maeda, J. Eliot, B. Moss + + * ... and many more + + +# Implementation + + * [[community/HurdFr]] + + * <http://wiki.hurdfr.org/index.php/BPF> + + * <http://wiki.hurdfr.org/index.php/Reseau_dans_gnumach> + + * Git repository: <http://rcs-git.duckcorp.org/hurdfr/bpf.git/> + + The patch for [[GNU Mach|microkernel/mach/gnumach]] is expected to be + complete and functional, the [[hurd/translator]] less so -- amongst others, + there are unresolved issues concerning support of [[hurd/glibc/IOCTL]]s. + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html> + + * [[zhengda]] + + * [[!GNU_Savannah_bug 25054]] -- Kernel panic with eth-multiplexer + + * [[!GNU_Savannah_patch 6619]] -- pfinet uses the virtual interface + + * [[!GNU_Savannah_patch 6620]] -- pfinet changes its filter rules with + its IP address + + * [[!GNU_Savannah_patch 6621]] -- pfinet sets the mach device into the + promiscuous mode + + * [[!GNU_Savannah_patch 6622]] -- pfinet uses the BPF filter + + * [[!GNU_Savannah_patch 6851]] -- fix a bug in BPF + + +# IRC + +## IRC, freenode, #hurd, 2012-01-13 + + <braunr> hm, i think the bpf code needs a complete redesign :p + <braunr> unless it's actually a true hurdish way to do things + <braunr> antrik: i need your help :) + <braunr> antrik: I need advice on the bpf "architecture" + <braunr> the current implementation uses a translator installed at /dev/bpf + <braunr> which means packets from the kernel are copied to that translator + and then to client applications + <braunr> does that seem ok to you ? + <braunr> couldn't the translator be used to set a direct link between the + kernel and the client app ? + <braunr> which approach seems the more Hurdish to you ? (<= this is what I + need your help on) + <pinotree> braunr: so there would be a roundtrip like kernel → bpf + translator → pfinet? + <antrik> braunr: TBH, I don't see why we need a BPF translator at all... + <braunr> antrik: it handles the ioctls + <braunr> pinotree: pfinet isn't involved (it was merely modified to use the + "new" filter format to specify it used the old packet filter, and not + bpf) + <antrik> braunr: do we really need to emulate the ioctl()s? can't we assume + that all packages using BPF will just use libpcap? + <antrik> (and even if we *do* want to emulate ioctl()s, why can't we handle + this is libc?) + <braunr> antrik: that's what i'm wondering actually + <braunr> even if assuming all packages use libpcap, i'd like our bpf + interface to be close to what bsds have, and most importantly, what + libpcap expects from a bpf interface + <antrik> well, why? if we already have a library handling the abstraction, + I don't see much point in complicating the design and use by adding + another layer :-) + <braunr> so you would advise adapting libpcap to include a hurd specific + module ? + <antrik> there are two reasons for adding translators: more robustness or + more flexibility... so far I don't see how a BPF translator would add + either + <braunr> right + <antrik> yes + <braunr> so we'd end up with a bpf-like interface, the same instructions + and format, with different control calls + <antrik> right + <antrik> note that I had more or less the same desicion to make for KGI + (emulate Linux/BSD ioctl()s, or implement a backend in libggi for + handling Hurd-specific RPC; and after much consideration, I decided on + the latter) + + +## IRC, freenode, #hurd, 2012-01-16 + + <braunr> antrik: is there an existing facility to easily give a send right + to the device master port to a task ? + <braunr> another function of the bpf translator is to handle the /dev/bpf + node, and most importantly its permissions + <braunr> so that users which have read/write access to the node have access + to the packet filter + <braunr> i guess the translator could limit itself to that functionality + <braunr> and then provide a device port on which libpcap operates directly + by means of device_{g,s}et_status/device_set_filter + <antrik> braunr: I don't see the point in seperating permissions for filter + from permissions from general network device access... + <antrik> as for device master port, all root tasks can obtain it from proc + IIRC + <braunr> antrik: yes, but how do we allow non-root users to access that + facility ? + <braunr> on a unix like system, it's a matter of changing the permissions + of /dev/bpf + <antrik> with devnode, non-root users can get access to specific device + nodes, including network devices + <braunr> i can't imagine the hurd being less flexible for that + <braunr> ah devnode + <braunr> good + <antrik> so we can for example make /dev/eth0 accessible by users of some + group + <braunr> what's devnode exactly ? + <antrik> it's a very simple translator that implements an FS node that + looks somewhat like a file, but the only operation it supports is + obtaining a pseudo device master port, giving access to a specific Mach + device + <braunr> is it already part of the hurd ? + <braunr> or hurdextras maybe ? + <antrik> it's only in zhengda's branch + <braunr> ah + <antrik> needed for both eth-multipexer and DDE + <braunr> and bpf soon i guess + <antrik> indeed :-) + <braunr> "obtaining a pseudo device master port", i believe you meant a + pseudo device port + <antrik> I must admit that I don't remember exactly whether devnode proxies + device_open(), so clients direct get a port to the device in question, or + whether it implements a pseudo device master port... + <antrik> but definitely not a pseudo device port :-) + <braunr> i'm almost positive it gives the target device port, otherwise i + don't see the point + <braunr> i don't understand the user of the "pseudo" word here either + <braunr> s/user/use/ + <braunr> aiui, devnode should be started as root (or in any way which gives + it the device master port) + <antrik> the point is that the client doesn't need to know the Mach device + name, and also is not bound to actual kernel devices + <braunr> and when started, implement the required permissions before giving + clients a device port to the specific device it was installed for + <braunr> right + <braunr> but it mustn't be a proxy + <antrik> yes, devnode needs access to either the real master device port + (for kernel devices), or one provided by eth-multiplexer or the DDE + network driver + <braunr> well, a very simple proxy for deviceopen + <braunr> ok + <braunr> that seems exactly what i wanted to do + <braunr> we now need to see if we can integrate it separately + <braunr> create a separate branch that works for the current gnumach code, + and merge dde/other specific code later on + <antrik> you mean independent of eth-multiplexer or DDE? yes, it was + generally agreed that devnode is a good idea in any case. I have no idea + why there are no device nodes for network devices on other UNIX + systems... + <braunr> i've been wondering that for years too :) + <antrik> zhengda's branch has a pfinet modified to a) use devnode, and b) + use BPF + <braunr> why bpf ? + <braunr> for more specific filters maybe ? + <antrik> hm... don't remember whether there was any technical reason for + going with BPF; I guess it just seemed more reasonable to invest new work + in BPF rather than obsolete Mach-specific NPF... + <braunr> cspf could be removed altogether, i agree + <antrik> another plus side of his modified pfinet is that it actually sets + an appropriate filter for TCP/IP and the IP in use, rather than just + setting a dummy filter catching app packets (including those irrelevant + to the specific pfinet instance) + <antrik> err... catching all packets + <braunr> that's what i meant by "for more specific filters maybe ?" + <braunr> he was probably more comfortable with the bpf interface to write + his filter rules + <antrik> well, it would probably be doable with NPF too :-) so by itself + it's not a reason for switching to BPF... + <antrik> it's rather the other way around: as it was necessary to implement + filters in eth-multiplexer, and implementing BPF seemed more reasoable, + pfinet had to be changed to use BPF... + <braunr> antrik: where is zhengda's branch btw ? + <antrik> (I guess using proper filters with eth-multiplexer is not strictly + necessary; but it would be a major performance hit not to) + <antrik> it's in incubator.git + <antrik> but it's very messy + <braunr> ok + <antrik> at some point I asked him to provide cleaned up branches, and I'm + pretty sure he said he did, but I totally fail to remember where he + published them :-( + <braunr> hm, i don't like how devnode is "architectured" :/ + <braunr> but it makes things a little more easy to get working i guess + <LarstiQ> antrik: any idea what to grep the logs on for that? + <braunr> ok never mind, devnode is fine + <braunr> exactly what i need + <braunr> i wonder however if it shouldn't be improved to better handle + permissions + <braunr> ok, never mind either, permission handling is fine + <braunr> so what are we waiting for ? :) + <antrik> I remember that there were some issues with permission handling, + but I don't remember whether all were fixed :-( + <antrik> LarstiQ: hm... good question... + <braunr> ah ? + <braunr> hm actually, there could be issues for packet filters, yes + <braunr> i guess we want to allow e.g. read-only opens for capture only + <antrik> braunr: that would have to be handled by the actual BPF + implementation I'd say + <braunr> it should already be the case + <antrik> what's the problem then? + <braunr> but when the actual device_open() is performed, the appropriate + permissions must be provided + <braunr> and checking those is the responsibility of the proxy, devnode in + this case + <antrik> and it doesn't do that? + <braunr> apparently not + <braunr> the only check is against the device name + <braunr> i'll begin playing with that first + <antrik> I vaguely remember that there has been discussion about the + relation of underlying device open mode and devnode open mode... but I + don't remember the outcome. in fact it was probably one of the + discussions I never got around to follow up on... :-( + <antrik> before you begin playing, take a look at the relevant messages in + the ML archive :-) + <antrik> must have been around two years ago + <braunr> ok + <antrik> some thread with me and scolobb (Sergiu Ivanov +- spelling) and + probably zhengda + <antrik> there might also be some outstanding patch(es) from scolobb, not + sure + + +## IRC, freenode, #hurd, 2012-01-17 + + <braunr> antrik: i think i found the thread you mentioned about devnode + <braunr> neither sergiu nor zhengda considered the use of a read-only + device for packet filtering + <braunr> leading to assumptions such as "only receiving packets + <braunr> is not terribly useful, in view of the fact that you have to at + least + <braunr> request them, which implies *sending* packets :-) + <braunr> " + <braunr> IMO, devnode should definitely check its node permissions to build + the device open flags + <braunr> good news is that it doesn't depend on anything specific to other + incubator projects + <braunr> making it almost readily mergeable in the hurd + <braunr> i'm not sure devnode is an appropriate name though + <braunr> maybe something like device, or devproxy + <braunr> proxy-devopen maybe + <antrik> braunr: well, I don't remember the details of the disucssion; but + as I mentioned in some mail, I did actually want to write a followup, + just didn't get around to it... so I was definitely not in agreement with + some of the statements made by others. I just don't remember on which + point :-) + <antrik> which thread was it? + <antrik> anyways, this should in no way be specific to network + devices... the idea is simply that if the client has only read + permissions on the device node, it should only get to open the underlying + device for read. it's up to the kernel to handle the read-only status for + the device once it's opened + <antrik> as for the naming, the idea is that devnode simply makes Mach + devices accessible through FS nodes... so the name seemed appropriate + <antrik> you may be right though that just "device" might be more + straightforward... I don't agree on the other variants + <braunr> antrik: + http://lists.gnu.org/archive/html/bug-hurd/2009-12/msg00155.html + <braunr> antrik: i agree with the general idea behind permission handling, + i was just referring to their thoughts about it, which probably led to + the hard coded READ | WRITE flags + <antrik> braunr: unfortunately, I don't remember the context of the + discussion... would take me a while to get into this again :-( + <antrik> the discussion seems to be about eth-multiplexer as much as about + devnode (if not more), and I don't remember the exact interaction + + +## IRC, freenode, #hurd, 2012-01-18 + + <braunr> so, does anyone have an objection to getting devnode into the hurd + and calling it something else like e.g. device ? + <youpi> braunr: it's Zhengda's work, right? + <braunr> yes + <youpi> I'm completely for it, it just perhaps needs some cleanup + <braunr> i have a few changes to add to what already exists + <braunr> ok + <braunr> well i'm assigning myself to the task + <antrik> braunr: I'm still not convinced just "device" is preferable + <antrik> perhaps machdevice ;-) + <antrik> but otherwise, I'd LOVE to see it in :-) + <braunr> i don't know .. what if the device is actually eth-multiplexer or + a dde one ? + <braunr> it's not really "mach", is it ? + <braunr> or do we only refer to the interface ? + <youpi> that translator is only for mach devices + <braunr> so you consider dde devices as being mach devices too ? + <braunr> it's a simple proxy for device_open really + <youpi> will these devices use that translator? + <youpi> ah + <youpi> I thought it was using a mach-specific RPC + <braunr> so we can consider whatever we want + <antrik> braunr: yes, the translator is for Mach device interface only. it + might be provided by other servers, but it's still Mach devices + <youpi> then drop the mach, yes + <braunr> i'd tend to agree with antrik + <youpi> antrik: I'd say the device interface is part of the hur dinterfaces + <braunr> then machdev :p + <braunr> no, it's really part of the mach interface + <youpi> it's part of the mach interface, yes + <youpi> but also of the Hurd, no? + <antrik> DDE network servers also use the Mach device interface + <braunr> no + <youpi> can't we say it's part of it? + <youpi> I mean + <youpi> even if we change the kernel + <braunr> dde is the only thing that implements it besides the kernel that i + know of + <youpi> we will probably want to keep the same interface + <braunr> yes but that's a mach thing + <youpi> what we have now is not necessarily a reason + <antrik> as for other DDE drivers, I for my part believe they should export + proper Hurd (UNIX) device nodes directly... but for some reason zhengda + insisted on implementing it as Mach devices too :-( + <braunr> antrik: i agree with you on that too + <braunr> i was a bit surprised to see the same interface was reused + <braunr> youpi: we can, we just have to agree on what we'll do + <braunr> what do you mean by "even if we change the kernel" ? + <antrik> the problem with "machdev" is that it might suggest the translator + actually implements the device... not sure whether this would cause + serious confusion + <antrik> "devopen" might be another option + <antrik> or "machdevopen" to be entirely verbose ;-) + <braunr> an option i suggested earlier which you disagreed on :p + <braunr> but devopen is the one i'd choose + <antrik> youpi: as I already mentioned in the libburn thread, I don't + actually think the Mach device interface is very nice; IMHO we should get + rid of it as soon as we can, rather than port it to other + architectures... + <antrik> but even *if* we decided to reuse it after all, it would still be + the Mach device interface :-) + <braunr> actually, zheng da already suggested that name a long time ago + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00005.html + <braunr> no actually antrik did eh + <braunr> ok let's use devopen + <antrik> braunr: you suggested proxy-devopen, which I didn't like because + of the "proxy" part :-) + <braunr> not only, but i don't have the logs any more :p + <antrik> oh, I already suggested devopen once? didn't expect myself to be + that consistent... ;-) + <antrik> braunr: you suggested device, devproxy or proxy-devopen + <braunr> ah, ok + <braunr> devopen is better + <antrik> I wonder whether it's more important for clarity to have "mach" in + there or "open"... or whether it's really too unweildy to have both + + +## IRC, freenode, #hurd, 2012-01-21 + + <braunr> oh btw, i made devopen run today, it shouldn't be hard getting it + in properly + <braunr> patching libpcap will be somewhat trickier + <braunr> i don't even really need it, but it allows having user access to + mach devices, which is nice for the libpcap patch and tcpdump tests + <braunr> permission checking is actually its only purpose + <braunr> well, no, not really, it also allows opening devices implemented + by user space servers transparently + + +## IRC, freenode, #hurd, 2012-01-27 + + <braunr> hmm, bpf needs more work :( + <braunr> or we can use the userspace bpf filter in libpcap, so that it + works with both gnumach and dde drivers + <antrik> braunr: there is a userspace BPF implementation in libpcap? I'm + surprised that zhengda didn't notice it, and ported the one from gnumach + instead... + <antrik> what is missing in the kernel implementation? + <braunr> antrik: filling the bpf header + <braunr> frankly, i'm not sure we want to bother with the kernel + implementation + <braunr> i'd like it to work with both gnumach and dde drivers + <braunr> and in the long run, we'll be using userspace drivers anyway + <braunr> the bpf header was one of the things the defunct translator did + <braunr> which involved ugly memcpy()s :p + <antrik> braunr: well, if you want to get rid of the kernel implementation, + basically you would have to take up eth-multiplexer and get it into + mainline + <antrik> (and make sure it's used by default in Debian) + <antrik> I frankly believe it's the better design anyways... but quite a + major change :-) + <braunr> not that major to me + <braunr> in the meantime i'll use the libpcap embedded implementation + <braunr> we'll have something useful faster, with minimum work when + eth-multiplexer is available + <antrik> eth-multiplexer is ready for use, it just needs to go upstream + <antrik> though it's probably desirable to switch it to the BPF + implementation from libpcap + <braunr> using the libpcap implementation in libpcap and in eth-multiplexer + are two different things + <braunr> the latter is preferrable + <braunr> (and yes, by available, i meant upstream ofc) + <antrik> eth-mulitplexer is already using libpcap anyways (for compiling + the filters); I'm sure zhengda just didn't realize it has an actual BPF + implementation too... + <braunr> we want the filter implementation as close to the packet source as + possible + <antrik> I have been using eth-multiplexer for at least two years now + <braunr> hm, there is a "snoop" source type, using raw sockets + <braunr> too far from the packet source, but i'll try it anyway + <braunr> hm wrong, snoop was the solaris packet filter fyi + + +## IRC, freenode, #hurd, 2012-01-28 + + <braunr> nice, i have tcpdump working :) + <braunr> let's see if it's as simple with wireshark + <pinotree> \o/ + <braunr> pinotree: it was actually very simple + <pinotree> heh, POV ;) + <braunr> yep, wireshark works too + <braunr> promiscuous mode is harder to test :/ + <braunr> but that's a start + + +## IRC, freenode, #hurd, 2012-01-30 + + <braunr> ok so next step: get tcpreplay working + <antrik> braunr: BTW, when you checked the status of the kernel BPF code, + did you take zhengda's enhancements/fixes into account?... + <braunr> no + <braunr> when did i check it ? + <antrik> braunr: well, you said the kernel BPF code has serious + shortcomings. did you take zhengda's changes into account? + <braunr> antrik: ah, when i mention the issues, i considered the userspace + translator only + <braunr> antrik: and stuff like non blocking io, exporting a selectable + file descriptor + <braunr> antrik: deb http://ftp.sceen.net/debian-hurd experimental/ + <braunr> antrik: this is my easy to use repository with a patched + libpcap0.8 + <braunr> and a small and unoptimized pcap-hurd.c module + <braunr> it doesn't use devopen yet + <braunr> i thought it would be better to have packet filtering working + first as a debian patch, then get the new translator+final patch upstream + <jkoenig> braunr, tcpdump works great here (awesome!). I'm probably using + exactly the same setup and "hardware" as you do, though :-P + + +## IRC, freenode, #hurd, 2012-01-31 + + <braunr> antrik: i tend to think we need a bpf translator, or anything + between the kernel and libpcap to provide selectable file descriptors + <braunr> jkoenig: do you happen to know how mach_msg (as called in a + hello.c file without special macros or options) deals with signals ? + <braunr> i mean, is it wrapped by the libc in a version that sets errno ? + <jkoenig> braunr: no idea. + <pinotree> braunr: what's up with it? (not that i have an idea about your + actual question, just curious) + <braunr> pinotree: i'm improving signal handling in my pcap-hurd module + <braunr> i guess checking for MACH_RCV_INTERRUPTED will dio + <braunr> -INFO is correctly handled :) + <braunr> ok new patch seems fine + <antrik> braunr: selectable file descriptors? + <braunr> antrik: see pcap_fileno() for example + <braunr> it returns a file descriptor matching the underlying object + (usually a socket) that can be multiplexed in a select/poll call + <braunr> obviously a mach port alone can't do the job + <braunr> i've upgraded the libpcap0.8 package with improved signal handling + for tests + <antrik> braunr: no idea what you are talking about :-( + + +## IRC, freenode, #hurd, 2012-02-01 + + <braunr> antrik: you do know about select/poll + <braunr> antrik: you know they work with multiple selectable/pollable file + descriptors + <braunr> on most unix systems, packet capture sources are socket + descriptors + <braunr> they're selectable/pollable + <antrik> braunr: what are packet capture sources? + <braunr> antrik: objects that provide applications with packets :) + <braunr> antrik: a PF_PACKET socket on Linux for example, or a Mach device, + or a BPF file descriptor on BSD + <antrik> for a single network device? or all of them? + <antrik> AIUI the userspace BPF implementation in libpcap opens this + device, waits for packets, and if any arrive, decides depending on the + rules whether to pass them to the main program? + <braunr> antrik: that's it, but it's not the point + <braunr> antrik: the point is that, if programs need to include packet + sources in select/poll calls, they need file descriptors + <braunr> without a translator, i can't provide that + <braunr> so we either decide to stick with the libpcap patch only, and keep + this limitation, or we write a translator that enables this feature + <pinotree> braunr: are the two options exclusive? + <braunr> pinotree: unless we implement a complete bpf translator like i did + years ago, we'll need a patch in libpcap + <braunr> pinotree: the problem with my early translator implementation is + that it's buggy :( + <braunr> pinotree: and it's also slower, as packets are small enough to be + passed through raw copies + <antrik> braunr: I'm not sure what you mean when talking about "programs + including packet sources". programs only interact with packet sources + through libpcap, right? + <antrik> braunr: or are you saying that programs somehow include file + descriptors for packet sources (how do they obtain them?) in their main + loop, and explicitly pass control to libpcap once something arrives on + the respecitive descriptors? + <braunr> antrik: that's the idea, yes + <antrik> braunr: what is the idea? + <braunr> 20:38 < antrik> braunr: or are you saying that programs somehow + include file descriptors for packet sources (how do they obtain them?) in + their main loop, and explicitly pass control to libpcap once something + arrives on the respecitive descriptors? + <antrik> braunr: you didn't answer my question though :-) + <antrik> braunr: how do programs obtain these FDs? + <braunr> antrik: using pcap_fileno() for example + + +## IRC, freenode, #hurd, 2012-02-02 + + <antrik> braunr: oh right, you already mentioned that one... + <antrik> braunr: so you want some entity that exposes the device as + something more POSIXy, so it can be used in standard FS calls, unlike the + Mach devices used for pfinet + <antrik> this is probably a good sentiment in general... but I'm not in + favour of a special solution only for BPF. rather I'd take this as an + indication that we probably should expose network interfaces as something + file-like in general after all, and adapt pfinet, eth-multiplexer, and + DDE accordingly + <braunr> antrik: i agree + <braunr> antrik: eth-multiplexer would be the right place + + +## IRC, freenode, #hurd, 2012-04-24 + + <gnu_srs> braunr: Is BPF fully supported by now? Can it be used for + isc-dhcp? + <braunr> gnu_srs: bpf isn't supported at all + <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module + in libpcap + <braunr> if isc-dhcp can use libpcap, then fine + <braunr> (otherwise we could create a hurd-specific patch for dhcp that + uses the in-kernel bpf filter implementation) + <braunr> gnu_srs: can't it use a raw socket ? + <youpi> it can + <youpi> it's just that the shape of the patch to do so wasn't exactly how + they needed it + <youpi> so they have to rework it a bit + <youpi> and that takes time + <braunr> ok + <braunr> antrik: for now, we prefer encapsulating the system specific code + in libpcap, and let users of that library benefit from it + <braunr> instead of implementing the low level bpf interface, which + nonetheless has some system-specific variants .. + + +## IRC, freenode, #hurd, 2012-08-03 + +In context of the [[select]] issue. + + <braunr> i understand now why my bpf translator was so buggy + <braunr> the condition_timedwait i wrote at the time was .. incomplete :) 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/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn new file mode 100644 index 00000000..f2009bd8 --- /dev/null +++ b/open_issues/chroot_difference_from_linux.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]]."]]"""]] + +\#hurd, freenode, 2010 + + <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux + <pochu> cfhammar: isn't that expected? + <cfhammar> pochu: well, i didn't expect it :-) + <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural + <pochu> cfhammar: oh right, didn't notice the ".." :-) diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn new file mode 100644 index 00000000..5345ed6b --- /dev/null +++ b/open_issues/clock_gettime.mdwn @@ -0,0 +1,71 @@ +[[!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="clock_gettime"]] + +[[!tag open_issue_glibc open_issue_gnumach]] + +Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) + +It could be a mere matter of extending the mappable clock: add it to +`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and +make `clock_gettime` use it. + +BTW, also make `gettimeofday()` use it, since it's way more efficient and some +applications assume that it is. + +What about adding a nanosecond-precision clock, too? --[[tschwinge]] + +IRC, freenode, #hurd, 2011-08-26: + + < pinotree> youpi: thing is: apparently i found a simple way to have a + monotonic clock as mmap-able device inside gnumach + < pinotree> currently, in kern/mach_clock.c there's a variable 'time', + which gets increased on clock interrupt, and optionally modified by + host_set_time + < pinotree> () + < pinotree> if i add a new variable next to it, only increasing it on + interrupt but not modifying it at all otherwise, would that give me a + monotonic clock? + < pinotree> at least on sme basic tests i did, it seems it could work that + way + < youpi> yes, it should work + < braunr> sure + < youpi> and that's the way I was considering implementing it + +IRC, freenode, #hurd, 2011-09-06: + + <pinotree> yeah, i had a draft of improved idea for also handling + nanoseconds + <tschwinge> pinotree: Ah, nice, I thought about nanoseconds as well. + <tschwinge> pinotree, youpi: This memory page is all-zero by default, + right? + <tschwinge> Can't we then say that its last int is a version code, and if + it is 0 (as it is now), we only have the normal mapped time field, if it + is 1, we also have the monotonic cliock and ns precision on address 8 and + 16 (or whatever)? + <tschwinge> In case that isn't your plan anyway. + <youpi> it's all-zero, yes + <tschwinge> Or, we say if a field is != 0 it is valid. + <youpi> making the last int a version code limits the size to one page + <youpi> I was thinking a field != 0 being valid is simpler + <youpi> but it's probably a problem too + <youpi> in that glibc usually caches whether interfaces are supported + <tschwinge> Wrap-around? + <youpi> for some clocks, it may be valid that the value is 0 + <youpi> wrap-around is another issue too + <tschwinge> Well, then we can do the version-field thing, but put it right + after the current time field (address 8, I think)? + <youpi> yes + <youpi> it's a bit ugly, but it's hidden behind the structure + <tschwinge> It's not too bad, I think. + <youpi> yes + <tschwinge> And it will forever be a witness of the evolving of this + map_time interface. :-) diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn new file mode 100644 index 00000000..a73f102c --- /dev/null +++ b/open_issues/code_analysis.mdwn @@ -0,0 +1,177 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]]."]]"""]] + +In the topic of *code analysis* or *program analysis* ([[!wikipedia +Program_analysis_(computer_science) desc="Wikipedia article"]]), there is +static code analysis ([[!wikipedia Static_code_analysis desc="Wikipedia +article"]]) and dynamic program analysis ([[!wikipedia Dynamic_program_analysis +desc="Wikipedia article"]]). This topic overlaps with [[performance +analysis|performance]], [[formal_verification]], as well as general +[[debugging]]. + +[[!toc]] + + +# Bounty + +There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. + + +# Static + + * [[GCC]]'s warnings. Yes, really. + + * GCC plugins can be used for additional semantic analysis. For example, + <http://lwn.net/Articles/457543/>, and search for *kernel context* in + the comments. + + * Have GCC make use of [[RPC]]/[[microkernel/mach/MIG]] *in*/*out* + specifiers, and have it emit useful warnings in case these are pointing + to uninitialized data (for *in* only). + + * [[Port Sequence Numbers|microkernel/mach/ipc/sequence_numbering]]. If + these are used, care must be taken to update them reliably, [[!message-id + "1123688017.3905.22.camel@buko.sinrega.org"]]. This could be checked by a + static analysis tool. + + * [[!wikipedia List_of_tools_for_static_code_analysis]] + + * [Engineering zero-defect software](http://esr.ibiblio.org/?p=4340), Eric + S. Raymond, 2012-05-13 + + * [Static Source Code Analysis Tools for C](http://spinroot.com/static/) + + * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/) + + For example, [Debian's hurd_20110319-2 + package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html) + (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious; + the realloc issues are for real*). + + * Coccinelle + + * <http://lwn.net/Articles/315686/> + + * <http://www.google.com/search?q=coccinelle+analysis> + + * [clang](http://www.google.com/search?q=clang+analysis) + + * [Linux' sparse](https://sparse.wiki.kernel.org/) + + * <http://klee.llvm.org/> + + * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html> + + * [Smatch](http://smatch.sourceforge.net/) + + * [Parfait](http://labs.oracle.com/projects/parfait/) + + * <http://lwn.net/Articles/344003/> + + * [Saturn](http://saturn.stanford.edu/) + + * [Flawfinder](http://www.dwheeler.com/flawfinder/) + + * [sixgill](http://sixgill.org/) + + * [s-spider](http://code.google.com/p/s-spider/) + + * [CIL (C Intermediate Language)](http://kerneis.github.com/cil/) + + * [Frama-C](http://frama-c.com/) + + * [Coverity](http://www.coverity.com/) (nonfree?) + + * [Splint](http://www.splint.org/) + + * IRC, freenode, #hurd, 2011-12-04 + + <mcsim> has anyone used splint on hurd? + <mcsim> this is tool for statically checking C programs + <mcsim> seems I made it work + + +# Dynamic + + * [[community/gsoc/project_ideas/Valgrind]] + + * glibc's `libmcheck` + + * Used by GDB, for example. + + * Is not thread-safe, [[!sourceware_PR 6547]], [[!sourceware_PR 9939]], + [[!sourceware_PR 12751]], [[!stackoverflow_question 314931]]. + + * <http://en.wikipedia.org/wiki/Electric_Fence> + + * <http://sourceforge.net/projects/duma/> + + * <http://wiki.debian.org/Hardening> + + * <https://wiki.ubuntu.com/CompilerFlags> + + * `MALLOC_CHECK_`/`MALLOC_PERTURB_` + + * IRC, freenode, #glibc, 2011-09-28 + + <vsrinivas> two things you can do -- there is an environment + variable (DEBUG_MALLOC_ iirc?) that can be set to 2 to make + ptmalloc (glibc's allocator) more forceful and verbose wrt error + checking + <vsrinivas> another is to grab a copy of Tor's source tree and copy + out OpenBSD's allocator (its a clearly-identifyable file in the + tree); LD_PRELOAD it or link it into your app, it is even more + aggressive about detecting memory misuse. + <vsrinivas> third, Red hat has a gdb python plugin that can + instrument glibc's heap structure. its kinda handy, might help? + <vsrinivas> MALLOC_CHECK_ was the envvar you want, sorry. + + * [`MALLOC_PERTURB_`](http://udrepper.livejournal.com/11429.html) + + * <http://git.fedorahosted.org/cgit/initscripts.git/diff/?id=deb0df0124fbe9b645755a0a44c7cb8044f24719> + + * In context of [[!message-id + "1341350006-2499-1-git-send-email-rbraun@sceen.net"]]/the `alloca` issue + mentioned in [[gnumach_page_cache_policy]]: + + IRC, freenode, #hurd, 2012-07-08: + + <youpi> braunr: there's actually already an ifdef REDZONE in libthreads + + It's `RED_ZONE`. + + <youpi> except it seems clumsy :) + <youpi> ah, no, the libthreads code properly sets the guard, just for + grow-up stacks + + * GCC's AddressSanitizer, a memory error detector (ASan; + `-fsanitize=address`) + + [Finding races and memory errors with GCC instrumentation + (AddressSanitizer)](http://gcc.gnu.org/wiki/cauldron2012#Finding_races_and_memory_errors_with_GCC_instrumentation_.28AddressSanitizer.29), + GNU Tools Cauldron 2012. <http://code.google.com/p/address-sanitizer/>. + + Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]]. + + * GCC's ThreadSanitizer, a data race detector (TSan; `-fsanitize=thread`) + + <http://code.google.com/p/data-race-test/wiki/ThreadSanitizer> + + Not yet [[ported to the Hurd|community/gsoc/project_ideas/gcc_asan]]. + + * Input fuzzing + + Not a new topic; has been used (and a paper published) for early UNIX + tools, I[[I|tschwinge]]RC. + + * <http://caca.zoy.org/wiki/zzuf> + + What about some [[RPC]] fuzzing? diff --git a/open_issues/code_analysis/discussion.mdwn b/open_issues/code_analysis/discussion.mdwn new file mode 100644 index 00000000..7ac3beb1 --- /dev/null +++ b/open_issues/code_analysis/discussion.mdwn @@ -0,0 +1,51 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-12-04 + + <mcsim> defpager uses it's own dynamic memory allocator, which uses + vm_allocate/vm_deallocate as backing store? Am I able to use duma in such + case? + <braunr> you will have to adapt it + <braunr> but it's already designed to handle custom allocators + <braunr> iirc + <braunr> btw, are there special flags for that memory which the pager + allocates ? + <braunr> e.g. to use wired memory ? + <mcsim> yes, wired memory + <braunr> you'll have to change that in duma then + <braunr> but apart from such details, it should be straightforward + + <antrik> braunr: I have no idea about duma; but if you think it's a useful + tool, please add it to open_issues/code_analysis.mdwn + <antrik> (I guess we should have a "proper" page listing useful debugging + tools...) + + +## IRC, freenode, #hurd, 2012-09-03 + + <mcsim> hello. Has anyone tried some memory debugging tools like duma or + dmalloc with hurd? + <braunr> mcsim: yes, but i couldn't + <braunr> i tried duma, and it crashes, probably because of cthreads :) + + +## IRC, freenode, #hurd, 2012-09-08 + + <mcsim> hello. What static analyzer would you suggest (probably you have + tried it for hurd already)? + <braunr> mcsim: if you find some good free static analyzer, let me know :) + <pinotree> a simple one is cppcheck + <mcsim> braunr: I'm choosing now between splint and adlint diff --git a/open_issues/console_tty1.mdwn b/open_issues/console_tty1.mdwn new file mode 100644 index 00000000..614c02c9 --- /dev/null +++ b/open_issues/console_tty1.mdwn @@ -0,0 +1,151 @@ +[[!meta copyright="Copyright © 2012 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]] + +Seen in context of [[libpthread]], but probably not directly related to it. + + +# IRC, freenode, #hurd, 2012-08-30 + + <gnu_srs> Do you also experience a frozen hurd console? + <braunr> yes + <braunr> i didn't check but i'm almost certain it's a bug in my branch + <braunr> the replacement of condition_implies was a bit hasty in some + places + <braunr> this is why i want to rework it separately + + +## IRC, freenode, #hurd, 2012-09-03 + + <gnu_srs> braunr: Did you find the cause of the Hurd console freeze for + your libpthread branch? + <braunr> gnu_srs: like i said, a bug + <braunr> probably in the replacement of condition_implies + <braunr> i rewrote that part in libpipe and it no works + <braunr> now* + + <braunr> gnu_srs: the packages have been updated + <braunr> and these apparently fix the hurd console issue correctly + +## IRC, freenode, #hurd, 2012-09-04 + + <braunr> gnu_srs: this hurd console problem isn't fixed + <braunr> it seems to be due to a race condition that only affects the first + console + <braunr> and by reading the code i can't see how it can even work oO + <gnu_srs> braunr: just rebooted, tty1 is still locked, tty2-6 works. And + the floppy error stays (maybe a kvm bug??) + <braunr> the floppy error is probably a kvm bug as we discussed + <braunr> the tty1 locked isn't + <braunr> i have it too + <braunr> it seems to be a bug in the hurd console server + <braunr> which is started by tty1, but for some reason, doesn't return a + valid answer at init time + <braunr> if you kill the term handling tty1, you'll see your first tty + starts working + <braunr> for now i'll try a hack that starts the hurd console server before + the clients + <braunr> doesn't work eh + <braunr> tty1 is the only one started before runttys + <braunr> indeed, fixing /etc/hurd/runsystem.gnu so that it doesn't touch + tty1 fixes the problem + <gnu_srs> do you have an explanation? + <braunr> not really no + <braunr> but it will do for now + <pinotree> samuel added that with the comment above, apparently to + workaround some other issue of the hurd console + <braunr> i'm pretty sure the bug is already visible with cthreads + <braunr> the first console always seems weird compared to the others + <braunr> with a login: at the bottom of the screen + <braunr> didn't you notice ? + <pinotree> sometimes, but not often + <braunr> typical of a race + <pinotree> (at least for me) + <braunr> pthreads being slightly slower exposes it + <gnu_srs> confirmed, it works by commenting out touch /dev/tty1 + <gnu_srs> yes, the login is at the bottom of the screen, sometimes one in + the upper part too:-/ + <braunr> so we have a new open issue + <braunr> hm + <braunr> exiting the first tty doesn't work + <braunr> which makes me think of the issue we have with screen + <gnu_srs> confirmed! + <braunr> also, i don't understand why we have getty on tty1, but nothing on + the other terminals + <braunr> something is really wrong with terminals on hurd *sigh* + <braunr> ah, the problem looks like it happens when getty attempts to + handle a terminal ! + <braunr> gnu_srs: anyway, i don't think it should be blocking for the + conversion to pthreads + <braunr> but it would be better if someone could assign himself that bug + <braunr> :) + + +## IRC, freenode, #hurd, 2012-09-05 + + <antrik> braunr: the login at the bottom of the screen if from the Mach + console I believe + <braunr> antrik: well maybe, but it shouldn't be there anyway + <antrik> braunr: why not? + <antrik> it's confusing, but perfectly correct as far as I can tell + <braunr> antrik: two login: on the same screen ? + <braunr> antrik: it's even more confusing when comparing with other ttys + <antrik> I mean it's correct from a techincal point of view... I'm not + saying it's helpful for the user ;-) + <braunr> i'm not even sure it's correct + <braunr> i've double checked the pthreads patch and didn't see anything + wrong there + <antrik> perhaps the startup of the Hurd console could be delayed a bit to + make sure it happens after the Mach console login is done printing + stuff... + <braunr> why are our gettys stubs ? + <antrik> I never understood the point of a getty TBH... + <braunr> well you need to communicate to something behind your terminal, + don't you ? + <braunr> with* + <antrik> why not just launch the login program or login shell right away? + <braunr> what if you want something else than a login program ? + <antrik> like what? + <antrik> and how would a getty help with that? + <braunr> an ascii-art version of star wars + <braunr> it would be configured to start something else + <antrik> and why does that need a getty? why not just start something else + directly? + <braunr> well getty is about the serial line parameters actually + <antrik> yeah, I had a vague understanding that it has something to do with + serial lines (or real TTY lines)... but we hardly need that on local + cosoles :-) + <antrik> consoles + <braunr> right + <braunr> but then why even bother with something like runttys + <antrik> well, something has to start the terminal servers?... + <antrik> I might be confused though + <braunr> what i don't understand is + <braunr> why is there no getty at startup, whereas they are spawned when + logging off ? + <antrik> they are? that's fascinating indeed ;-) + <braunr> does it behave like this on your old version ? + <antrik> I don't remember ever having seen a "getty" process on my Hurd + systems... + <braunr> can you log on e.g. tty2 and then log out, and see ? + <antrik> OTOH, I'm hardly ever using consoles... + <antrik> hm... I think that should be possible remotely using the console + client with ncurses driver? never tried that... + <braunr> ncurses driver ? + <braunr> hum i don't know, never tried either + <braunr> and it may add other bugs :p + <braunr> better wait to be close to the machine + <antrik> hehe + <antrik> well, it's a good excuse for trying the ncurses driver ;-) + <antrik> hrm + <antrik> alien:~# console -d ncursesw + <antrik> console: loading driver `ncursesw' failed: Gratuitous error + <antrik> I guess nobody tested that stuff in years diff --git a/open_issues/console_vs_xorg.mdwn b/open_issues/console_vs_xorg.mdwn new file mode 100644 index 00000000..ffefb389 --- /dev/null +++ b/open_issues/console_vs_xorg.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 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_hurd]] + + +# IRC, freenode, #hurd, 2012-08-30 + + <gean> braunr: I have some errors about keyboard in the xorg log, but + keyboard is working on the X + <braunr> gean: paste the log somewhere please + <gean> braunr: http://justpaste.it/19jb + [...] + [1987693.272] Fatal server error: + [1987693.272] Cannot set event mode on keyboard (Inappropriate ioctl for device) + [...] + [1987693.292] FatalError re-entered, aborting + [1987693.302] can't reset keyboard mode (Inappropriate ioctl for device) + [...] + <braunr> hum + <braunr> it looks like the xorg keyboard driver evolved and now uses ioctls + our drivers don't implement + <braunr> thanks for the report, we'll have to work on this + <braunr> i'm not sure the problem is new actually diff --git a/open_issues/contributing.mdwn b/open_issues/contributing.mdwn new file mode 100644 index 00000000..7ae742f0 --- /dev/null +++ b/open_issues/contributing.mdwn @@ -0,0 +1,44 @@ +[[!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_documentation]] + +This should be integrated into [[/contributing]]. + +--- + +Every now and then, people show up who have an inward urge to contribute to the +GNU Hurd, but have some difficulties about how to do that. + +For example, IRC, #hurd, 2010-10-06: + + <rah> I find it difficult to find the will to contribute to the hurd while hurd != hurd-ng + <pochu> hurd-ng? + <pochu> ah, http://www.gnu.org/software/hurd/hurd/ng.html + <pochu> rah: you may want to work on achieving that then + <rah> pochu: I'm not in a position to do OS research + <antrik> rah: if you are not into OS research, why do you need it to be ngHurd? :-) + <rah> antrik: I don't want to work on software which I know is already obsolete + <tschwinge> rah: My position on that can be found here; you may want to think about it. http://lists.gnu.org/archive/html/bug-hurd/2007-07/msg00111.html + <antrik> rah: the existing Hurd implementation is not any more obsolete than any other large software project + <antrik> there are always things that could be redone in a better way some time in the future + <antrik> but we have to start somewhere + <antrik> software development is a dynamic process + <antrik> trying to come up with a perfect design before you write any code will never lead anywhere, ever + <rah> antrik: of course, but when you know your start is wrong, have identified its problems, and are in the process of designing a second attempt, working on the first seems pointless + <antrik> rah: well, do you know all these things? because I do not + <antrik> what the experiments with new Hurd designs proved so far is that nobody is in a position to claim, "I have a better design" + <antrik> it's not hard to come up with a design that is better in some points -- but it's damn hard to come up with one that's not lacking in others + <antrik> the existing Hurd design is actually the only one which we *know* to work + <antrik> while research on improving the design is certainly beneficial, it's not like there is something new ready to replace the existing design at any moment + <antrik> and frankly, I'm more and more convinced that only iterative changes can ever result in any real improvement + <antrik> (and doing these changes requires a certain momentum, which we will never gain unless we actually have something usable first) + <LarstiQ> rah: afaik, not much is being done of designing another attempt + <rah> antrik: yes, I know all these things diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn new file mode 100644 index 00000000..7ed4afbf --- /dev/null +++ b/open_issues/crash_server.mdwn @@ -0,0 +1,195 @@ +[[!meta copyright="Copyright © 2009, 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 +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]] + +Given an `a.out` executable that only does `raise (SIGABRT)`, invoking that +one... + + * ... against `crash-dump-core` will... + + * ... not overwrite existing `core` files. + + Is this reasonable? Linux does overwrite them, for example. + + * ... show big variances in running-time behavior: + + $ TIMEFORMAT='real %R user %U system %S' + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 1.350 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 22.771 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 21:59 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 1.367 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 5.789 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:00 core + $ rm -f core; time env CRASHSERVER=/servers/crash-dump-core ./a.out; ls -l core + Aborted (core dumped) + real 22.664 user 0.010 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:01 core + + * ... produce a huge `core` file: + + $ du -hs core + 17M core + + On Linux, the `core` file occupies 76 KiB of disk space, which seems + much more reasonable. This is possibly related with the default 128MiB + heap preallocation. + + * ... does not always produce a useful backtrace: + + `abort();` + + $ gdb test core + warning: core file may not match specified executable file. + [New Thread 86678] + warning: Wrong size fpregset in core file. + ... + Core was generated by `./test'. + Program terminated with signal 6, Aborted. + warning: Wrong size fpregset in core file. + (gdb) bt + #0 0x00000000 in ?? () + #1 0x011f593f in __msg_sig_post (process=72, signal=6, sigcode=0, refport=1) + at /build/buildd-eglibc_2.10.2-7-hurd-i386-iGL6op/eglibc-2.10.2/build-tree/hurd-i386-libc/hurd/RPC_msg_sig_post.c:144 + #2 0x0109a433 in kill_port (pid=<value optimized out>) + at ../sysdeps/mach/hurd/kill.c:68 + #3 kill_pid (pid=<value optimized out>) at ../sysdeps/mach/hurd/kill.c:105 + #4 0x0109a69f in __kill (pid=21142, sig=6) at ../sysdeps/mach/hurd/kill.c:139 + #5 0x01099af6 in raise (sig=6) at ../sysdeps/posix/raise.c:27 + #6 0x0109de59 in abort () at abort.c:88 + #7 0x0804849f in main () + + `char *foo = 0; *foo = 1;` + + $ gdb test core + Program terminated with signal 11, Segmentation fault. + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + #1 0x0108565b in __libc_start_main (main=0x8048464 <main>, argc=1, ubp_av=0x1023e64, + init=0x8048490 <__libc_csu_init>, fini=0x8048480 <__libc_csu_fini>, rtld_fini=0xea20 <_dl_fini>, + stack_end=0x1023e5c) at libc-start.c:251 + #2 0x080483d1 in _start () + + `raise (SIGABRT);` + + $ gdb a.out core + warning: core file may not match specified executable file. + [New Thread 76651] + + warning: Wrong size fpregset in core file. + Reading symbols from /lib/libc.so.0.3...[...] + Core was generated by `./a.out'. + Program terminated with signal 6, Aborted. + + warning: Wrong size fpregset in core file. + #0 0x00000000 in ?? () + (gdb) bt + #0 0x00000000 in ?? () + Cannot access memory at address 0x17 + + [[!tag open_issue_gdb]] Probably [[GDB]] doesn't manage to dig in the stack properly. + + * ... against `crash-suspend` will... + + * ... not work at all: + + $ CRASHSERVER=/servers/crash-suspend ./a.out + $ [returns to the shell and doesn't suspended] + + * ... show big variances in running-time behavior: + + $ TIMEFORMAT='real %R user %U system %S' + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.381 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.332 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 21.228 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:04 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.323 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 22.279 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:05 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.362 user 0.000 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 21.110 user 0.000 system 0.000 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + $ rm -f core; time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted (core dumped) + real 1.350 user 0.000 system 0.020 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + + * ... can reliably crash GNU Mach: + + This happens if a `core` file is already present (and won't get + overwritten; see above). I reproduced this three times. + + $ TIMEFORMAT='real %R user %U system %S' + $ time env CRASHSERVER=/servers/crash-suspend ./a.out; ls -l core + Aborted + real 2.856 user 0.000 system 0.010 + -rw------- 1 tschwinge tschwinge 17031168 Jul 7 22:08 core + + panic: zalloc: zone kalloc.8192 exhausted + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006aba8,4d0f7e9c,200209b0,0,0) + 0x20020a4d(2006b094,2006ae40,2000,20016803,4a5f4114) + 0x2002bca5(49a03564,1,0,9,1000) + 0x20022f4c(2000,4a5f45d4,4a84879c,49a46564,4ac43e78) + 0x20021e65(4ac43e78,4a5f45d4,4a5f4114,0,0) + 0x2005309d(2106ba9c,3,38,28,1783) + Bad frame pointer: 0x2106ba78 + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020a4d 0x2002bca5 0x20022f4c 0x20021e65 0x2005309d + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + panic + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:148 + zalloc + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/zalloc.c:470 + kalloc + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/kalloc.c:185 + ipc_kobject_server + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:76 + mach_msg_trap + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + +--- + +If someone is working in this area, they may want to have a look at +[[GDB_gcore]], and port <http://code.google.com/p/google-coredumper/>, too. 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/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.mdwn new file mode 100644 index 00000000..b94c0c1d --- /dev/null +++ b/open_issues/crt0_o_crt1_o_debug_info_relocation_invalid_symbol_index.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_glibc open_issue_gcc]] + + $ gcc -o /dev/null -x c /dev/null + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 0 has invalid symbol index 12 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 1 has invalid symbol index 13 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 2 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 3 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 4 has invalid symbol index 12 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 5 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 6 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 7 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 8 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 9 has invalid symbol index 2 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 10 has invalid symbol index 13 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 11 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 12 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 13 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 14 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 15 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 16 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 17 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 18 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 19 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 20 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 21 has invalid symbol index 14 + /usr/bin/ld: /usr/lib/debug/usr/lib/crt1.o(.debug_info): relocation 22 has invalid symbol index 22 + /usr/lib/gcc/i486-gnu/4.4.5/../../../crt1.o: In function `_start': + (.text+0x18): undefined reference to `main' + collect2: ld returned 1 exit status + +Likewise for `-static`, `crt0.o`. diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn new file mode 100644 index 00000000..2f02579e --- /dev/null +++ b/open_issues/dbus.mdwn @@ -0,0 +1,90 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and socket credentials +[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in +[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms. + +--- + +IRC, freenode, #hurd, 2011-11-26: + + <antrik> BTW, how much effort is necessary to fix dbus? + <pinotree> basically, have pflocal know who's the sender + (pid/uid/gid/groups) in the socket send op + +IRC, freenode, #hurd, 2011-12-16: + + <braunr> pinotree: what's the problem with dbus ? + <pinotree> braunr: select() returning 0 changed fd's with very short (eg < + 1ms) timeouts when there are actually events; + +[[select]]. + + <pinotree> and missing socket credentials + +[[sendmsg_scm_creds]]. + + <braunr> oh + <braunr> which socket creds interface ? + <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on + {recv,send}msg() + <braunr> ok + <braunr> SCM_RIGHTS too ? + <braunr> the select issue seems weird though + <pinotree> hm no, that's for passing fd's to other processes + <braunr> is it specific to pflocal or does dbus use pfinet too ? + <pinotree> iirc on very short timeouts the application has no time waiting + for the reply of servers + <braunr> i see + <pinotree> braunr: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358 + <braunr> thanks + <pinotree> (the interesting messages are from #53 and on) + <braunr> 2000 eh ... :) + <braunr> hm i agree with neal, i don't understand why the timeout is given + to the kernel as part of the mach_msg call + +IRC, freenode, #hurd, 2011-12-20: + + <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus + <braunr> only SCM_RIGHTS + <pinotree> braunr: yes, that one + <braunr> oh + <braunr> i thought you said the opposite last time + <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and + _dbus_read_credentials_socket (with #define HAVE_CMSGCRED) + <braunr> hm + <braunr> which version ? + <braunr> i don't see anything in 1.4.16 + <pinotree> 1.4.16 + <braunr> grmbl + <braunr> ah, i see + <braunr> SCM_CREDS + <pinotree> if you want, i have a simplier .c source with it + <braunr> no i'm just gathering info + <pinotree> ok + <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ? + <braunr> bsd vs sysv ? + <braunr> oh, http://lists.debian.org/debian-hurd/2002/03/msg00135.html + <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus + <braunr> dbus + <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's + <braunr> yes + <braunr> but it's used by dbus + <braunr> so if we can get it, it should help too + <pinotree> there's a preliminary patch for it done by emilio time ago, and + iirc it's applied to debian's glibc + <braunr> ah, he changed the libc + <braunr> right, that's the only sane way + <pinotree> iirc roland didn't like one or more parts of it (but i could be + wrong) + <braunr> ok diff --git a/open_issues/dbus_in_linux_kernel.mdwn b/open_issues/dbus_in_linux_kernel.mdwn new file mode 100644 index 00000000..a94e1fed --- /dev/null +++ b/open_issues/dbus_in_linux_kernel.mdwn @@ -0,0 +1,64 @@ +[[!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]]."]]"""]] + +Might be interesting to watch how this develops. + +IRC, #hurd, August / September 2010 + + <neal> check this out: + <neal> someone is working on implementing dbus in linux + <neal> linux finally gets mach ipc ;-) + <marcusb> it's old news though, unless there is an update + <marcusb> and I think it was only the client? + <neal> youpi : someone is adding dbus ipc to the linux kernel + <neal> marcusb: I just heard about it. + <youpi> (it's crazy how this drives backward compared to a hurdish approach) + <youpi> what is the motivation for moving to the kernel? + <neal> context switch overhead + <azeem_> they wanna use it to talk to device drivers? :) + <kilobug> well, they did that with the in-kernel web server, but they + abandonned it later on + <neal> azeem: I don't think so. + <neal> dbus in the kernel is actually good for the Hurd as dbus IPC is + basically neutered Mach IPC + <marcusb> I don't think anybody wants to put the dbus server in the kernel + <neal> well, there is at least one person + <marcusb> maybe this is a different news from the one I read + <neal> Alban Crequy (albanc) is working out. He works for collabora, fwiw + +<http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/> + + <marcusb> what I read was about hal etc + <marcusb> so that you don't need a user space daemon to glue the kernel to the + dbus world + <neal> I don't think that is what he is talking about + <marcusb> I can't find it anymore though. I mentioned it in this channel at + the time though, so it should be in the backlog + <marcusb> neal, yeah could very well be a separate thing + <marcusb> neal, dbus does have marginal support for fd passing though, and some + attempts on the mailing list to make "fds" an official type in the message + failed (as far as I could see, I didn't read the whole discussion) + <marcusb> so no mach ipc just yet + <neal> wrong + <neal> FD handling is in 1.4 + <neal> type o, if I'm not mistaken + <marcusb> then the discussion moved on from initial rejection + <neal> no, 'h' + <marcusb> I'm out of date by two months + <marcusb> ok + <guillem> neal: AFAIR Marcel Holtmann talked about dbus in-kernel several years + ago, but he never ended up implementing it, or there were rumors he had + private "working code" + + * Related Mailing List Discussion + + * [\[PATCH 0/5\] RFC: Multicast and filtering features on + AF_UNIX](http://article.gmane.org/gmane.linux.kernel/1040481), + 2010-09-24 diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn new file mode 100644 index 00000000..5f6fcf6a --- /dev/null +++ b/open_issues/dde.mdwn @@ -0,0 +1,538 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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_gnumach]] + +[[General Information|/dde]]. + +Still waiting for interface finalization and proper integration. + +[[!toc]] + +See [[user-space_device_drivers]] for generic discussion related to user-space +device drivers. + + +# Disk Drivers + +Not yet supported. + +The plan is to use [[libstore_parted]] for accessing partitions. + + +# Upstream Status + + +## IRC, freenode, #hurd, 2012-02-08 + +At the microkernel davroom at [[community/meetings/FOSDEM_2012]]: + + <antrik> there was quite some talk about DDE. I learnt that there are newer + versions in Genode and in Minix (as opposed to the DROPS one we are + using) + <antrik> but apparently none of the guys involved is interested in creating + a proper upstream project with central repository and communication + channels :-( + <antrik> the original DDE creator was also there, but said he isn't working + on it anymore + <tschwinge> OK, and the other two projects basically have their own forks. + <tschwinge> Or are they actively cooperating? + <tschwinge> (If you know about it.) + <antrik> well, Genode is also part of the Dresden L4 group; but apart from + that, I'd rather call it a fork... + <antrik> hm... actually, I'm not sure anymore whether the guy I talked to + was from Genode or Nova... + <antrik> (both from the Dresdem L4 group) + + +### IRC, freenode, #hurd, 2012-08-12 + + <antrik> + http://genode.org/documentation/release-notes/12.05#Re-approaching_the_Linux_device-driver_environment + <antrik> I wonder whether the very detailed explanation was prompted by our + DDE discussions at FOSDEM... + <pinotree> antrik: one could think about approaching them to develop the + common dde libs + dde_linux together + <antrik> pinotree: that's what I did at FOSDEM -- they weren't interested + <pinotree> antrik: this year's one? why weren't they? + <pinotree> maybe at that time dde was not integrated properly yet (netdde + is just few months "old") + <braunr> do you really consider it integrated properly ? + <pinotree> no, but a bit better than last year + <antrik> I don't see what our integration has to do with anything... + <antrik> they just prefer hacking thing ad-hoc than having some central + usptream + <pinotree> the helenos people? + <antrik> err... how did helenos come into the picture?... + <antrik> we are talking about genode + <pinotree> sorry, confused wrong microkernel OS + <antrik> actually, I don't remember exactly who said what; there were + people from genode there and from one or more other DDE projects... but + none of them seemed interested in a common DDE + <antrik> err... one or two other L4 projects + + +## IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: do we know exactly which DDE version Zheng Da took as a + base ? + <youpi> (so as to be able to merge new changes easily) + <antrik> youpi: not sure... but from what I gathered at FOSDEM, the version + he based on (from DROPS) is not really actively developed right now; if + we want to go for newer versions, we probably have to look at other + projects (like Genode or Nova or Minix) + <youpi> there's no central project for dde ? + <youpi> that sucks + <antrik> no... and nobody seemed interested in having one :-( + <youpi> pff + <antrik> which makes me seriously question the original decision to build + on DDE... + <braunr> .. + <antrik> if we have to basically maintain it ourselfs anyways, we could + just as well have gone with custom glue + <youpi> well, the advantage of DDE is that it already exists now + <antrik> on the positive side, one of the projcets (not sure which) + apparently have both USB and SATA working with some variant of DDE + + +### IRC, freenode, #hurd, 2012-11-03 + + <mcsim> DrChaos: there is DDEUSB framework for L4. You could port it, if + you want. It uses Linux 2.6.26 usb subsystem. + + +# IRC, OFTC, #debian-hurd, 2012-02-15 + + <pinotree> i have no idea how the dde system works + <youpi> gnumach patch to provide access to physical memory and interrupts + <youpi> then userland accesses i/o ports by hand to drive things + <youpi> but that assumes that no kernel driver is interfering + <youpi> so one has to disable kernel drivers + <pinotree> how are dde drivers used? can they be loaded on their own + automatically, or you have to settrans yourself to setup a device? + <youpi> there's no autoloader for now + <youpi> we'd need a bus arbitrer that'd do autoprobing + +[[PCI_arbiter]]. + + <pinotree> i see + <pinotree> (you see i'm not really that low level, so pardon the flood of + posssibly-noobish questions ;) ) + <youpi> I haven't set it up yet, but IIRC you need to specify which driver + to be used + <youpi> well, I mostly have the same questions actually :) + <youpi> I just have some guesswork here :) + <pinotree> i wonder whether the following could be feasible: + <youpi> I'm wondering how we'll manage to make it work in d-i + <pinotree> a) you create a package which would b-d on linux-source, build a + selection of (network only for now) drivers and install them in + /hurd/dde/ + <youpi> probably through a choice at the boot menu + <youpi> I wouldn't dare depending on linux-source + <youpi> dde is usually not up-to-date + <pinotree> b) add a small utility over the actual fsys_settrans() which + would pick the driver from /hurd/dde/ + <pinotree> ... so you could do `set-dde-driver b43 <device>` (or something + like that) + <youpi> we can provide something like b) yes + <youpi> although documenting the settrans should be fine enough ;) + <pinotree> the a) would help/ease with the fact that you need to compile on + your own the drivers + <pinotree> otherwise we would need to create a new linux-dde-sources-X.Y.Z + only with the sources of the drivers we want from linux X.Y.Z + <pinotree> (or hurd-dde-linux-X.Y.Z) + <CIA-4> samuel.thibault * raccdec3 gnumach/debian/ (changelog + patches/70_dde.patch patches/series): + <CIA-4> Add DDE experimental support + <CIA-4> * debian/patches/70_dde.patch: Add experimental support for irq + passing and + <CIA-4> physical memory allocation for DDE. Also adds nonetdev boot + parameter to + <CIA-4> disable network device drivers. + <youpi> ok, boots fine with the additional nonetdev option + <youpi> now I need to try that dde hurd branch :) + <CIA-4> samuel.thibault * rf8b9426 gnumach/debian/patches/70_dde.patch: Add + experimental.defs to gnuamch-dev + + +# IRC, freenode, #hurd, 2012-02-19 + + * youpi got dde almost working + <youpi> it's able to send packets, but apparently not receive them + <youpi> (e1000) + <youpi> ok, rtl8139 works + <youpi> antrik: the wiki instructions are correct + <youpi> with e1000 I haven't investigated + <antrik> (Archhurd guys also reported problems with e1000 IIRC... the one I + built a while back works fine though on my T40p with real e1000 NIC) + <antrik> maybe I should try with current versions... something might got + broken by later changes :-( + <youpi> at least testing could tell the changeset which breaks it + <youpi> Mmm, it's very odd + <youpi> with the debian package, pfinet's call to device_set_filter returns + D_INVALID_OPERATION + <youpi> and indeed devnode.c returns that + <youpi> ah but it's libmachdev which is supposed to answer here + <antrik> youpi: so, regarding the failing device_set_filter... I guess you + are using some wrong combination of gnumach and pfinet + <youpi> no it's actually that my pfinet was not using bpf + <youpi> I've now fixed it + <antrik> the DDE drivers rely on zhengda's modified pfinet, which uses + devnode, but also switched to using proper BPF filters. so you also need + his BPF additions/fixes in gnumach + <antrik> OK + <youpi> that's the latter + <youpi> I had already fixed the devnode part + <youpi> but hadn't seen that the filter was different + <antrik> err... did I say gnumach? that of course doesn't come into play + here + <antrik> so yes, you just need a pfinet using BPF + <youpi> libmachdev does ;) + <antrik> I'm just using pfinet from zhengda's DDE branch... I think devnode + and BPF are the only modifications + <youpi> there's also a libpcap modification in the incubator + <youpi> probably for tcpdump etc. + <antrik> libpcap is used by the modified pfinet to compile the filter rule + <youpi> why does pfinet need to compile the rule ? + <youpi> it's libbpf which is used in the dde driver + <antrik> it doesn't strictly need to... but I guess zhengda considered it + more elegant to put the source rule in pfinet on compile it live, rather + than the compiled blob + <antrik> I probably discussed this with him myself a few years back... but + my memory on this is rather hazy ;-) + <antrik> err... and compile it live + <youpi> ah, right, it's only used when asking pfinet to change its filter + <youpi> but it does not need it for the default filter + <youpi> which is hardcoded + <antrik> I see + <antrik> when would pfinet change its filter? + * youpi now completely converting his hurd box to debian packages with dde + support + <youpi> on SIOCSIFADDR apparently + <youpi> to set "arp or (ip host %s)", + <antrik> well, that sounds like the default filter... + <youpi> the default filter does not choose an IP + <antrik> oh, right... pfinet has to readjust the filter when setting the IP + <youpi> arg we lack support for kernel options for gnumach in update-grub + <antrik> again, I have a vague recollection of discussing this + * youpi crosses fingers + <youpi> yay, works + <antrik> so we *do* need libpcap in pfinet to set proper rules... though I + guess it can also work with a static catchall rule (like it did before + zhengda's changes), only less efficient + <youpi> well in the past we were already catching everything anyway, so at + least it's not a regression :) + <antrik> right + + +# [[PCI_Arbiter]] + +## IRC, freenode, #hurd, 2012-02-21 + + <youpi> since all drivers need is interrupts, io ports and iomem + <youpi> the latter was already available through /dev/mem + <youpi> io ports through the i386 rpcs + <youpi> the changes provide both interrupts, and physical-contiguous + allocation + <youpi> it should be way enough + <braunr> youpi: ok + <braunr> youpi: thanks for the details :) + <antrik> braunr: this was mentioned in the context of the interrupt + forwarding interface... the original one implemented by zhengda isn't + suitable for a PCI server; but the ones proposed by youpi and tschwinge + would work + <antrik> same for the physical memory interface: the current implementation + doesn't allow delegation; but I already said that it's wrong + + +# IRC, freenode, #hurd, 2012-02-20 + + <youpi> I was a bit wary of including the ton of dde headers in hurd-dev + <youpi> maybe adding another package for that + <youpi> but that would have delayed introducing the dde binaries + <youpi> probably we can do that for next upload + <pinotree> i can try to work on it, if is feasible (ie if the dde drivers + can currently be built from outside the hurd source tree) + <youpi> it should be, it's a matter of pointing its makefile to a place + where the make scripts and include headers are + <youpi> (and the libraries) + <pinotree> ok + <antrik> youpi: you mean DDEKit headers? + <antrik> pinotree: actually it doesn't matter where the dde-ified Linux + drivers are built -- libdde_linux26 and the actual drivers use a + completetly different build system anyways + <antrik> in fact we concluded at some point that they should live in a + separate repository -- but that change never happened + <antrik> only the base stuff (ddekit, libmachdev etc.) belong in the Hurd + source tree + <youpi> antrik: yes + <youpi> antrik: err, not really completely different + <youpi> the actual drivers' Makefile include the libdde_linux26 mk files + <youpi> the build itself is separate, though + <antrik> youpi: yes, I mean both libdde_linux26 and the drivers use a build + system that is completely distinct from the Hurd one + <youpi> ah, yes + <youpi> libdde_linux26 should however be shipped in the system + <antrik> ideally libdde_linux26 and all the drivers should be built in one + go I'd say... + <youpi> it should be easily feasible to also have a separate driver too + <youpi> e.g. to quickly try a 2.6 driver + <antrik> youpi: I'm not sure about that. it's not even dynamically linked + IIRC?... + <youpi> with scripts to build it + <youpi> it's not + <youpi> but that doesn't mean it can't be separate + <youpi> .a files are usually shipped in -dev packages + <antrik> youpi: ideally we should try to come with a build system that + reuses the original Linux makefile snippets to build all the drivers + automatically without any manual per-driver work + <youpi> there's usually no modification of the drivers themselves? + <youpi> but yeah + <youpi> "ideally", when somebody takes the time to do it + <antrik> unfortunately, it's necessary to include one particular + Hurd/DDE-specific header file in each driver :-( + <youpi> can't it be done through gcc's -include option? + <antrik> zhengda didn't find a way to avoid this... though I still hope + that it must be possible somehow + <antrik> I think the problem is that it has to be included *after* the + other Linux headers. don't remember the details though + <youpi> uh + <youpi> well, a good script can add a line after the last occurrence of + #include + <antrik> yeah... rather hacky, but might work + <youpi> even with a bit of grep, tail, cut, and sed it should work :) + <antrik> note that this is Hurd-specific; the L4 guys didn't need that + <youpi> what is it? + <antrik> don't remember off-hand + + +# IRC, freenode, #hurd, 2012-02-22 + + <youpi> antrik: AIUI, it should be possible to include all network drivers + in just one binary? + <youpi> that'd permit to use it in d-i + <youpi> and completely replace the mach drivers + <youpi> we just need to make sure to include at least what the mach drivers + cover + <youpi> (all DDE network drivers, I mean) + <youpi> of course that doesn't hinder from people to carefully separate + drivers in several binaries if they wish + <youpi> antrik: it does link at least, I'll give a try later + <youpi> yes it works! + <youpi> that looks like a plan + <youpi> throw all network drivers in a /hurd/dde_net + <youpi> settrans it on /dev/dde_net, and settrans devnode on /dev/eth[0-9] + <youpi> I'm also uploading a version of hurd which includes headers & + libraries, so you just need a make in dde_{e100,e1000,etc,net} + <youpi> (uploading it with the dde driver itself :) ) + <youpi> btw, a nice thing is that we don't really care that all drivers are + stuffed into a single binary, since it's a normal process only the useful + pages are mapped and actually take memory :) + <Tekk_> is that really a nice thing though? compared to other systems I + mean + <Tekk_> I know on linux it only loads the modules I need, for example. It's + definitely a step up for hurd though :D + <youpi> that's actually precisely what I mean + <youpi> you don't need to load only the modules you need + <youpi> you just load them all + <youpi> and paging eliminates automatically what's not useful + <youpi> even parts of the driver that your device will not need + <Tekk_> ooh + <Tekk_> awesome + <youpi> (actually, it's not even loaded, but the pci tables of the drivers + are loaded, then paged out) + + +# IRC, freenode, #hurd, 2012-02-24 + + <youpi> antrik_: about the #include <ddekit/timer.h>, I see the issue, it's + about jiffies + <youpi> it wouldn't be a very good thing to have a jiffies variable which + we'd have to update 100times per second + <youpi> so ZhengDa preferred to make jiffies a macro which calls a function + which reads the mapped time + <youpi> however, that break any use of the work "jiffies", e.g. structure + members & such + <youpi> actually it's not only after headers that the #include has to be + done, but after any code what uses the word "jiffies" for something else + than the variable + <youpi> pb is: it has to be done *before* any code that uses the word + "jiffies" for the variable, e.g. inline functions in headers + <youpi> in l4dde, there's already the jiffies variable so it's not a + problem + + +# IRC, OFTC, #debian-hurd, 2012-02-27 + + <tschwinge> I plan to do some light performance testing w.r.t. DDE + Ethernet. That is DDE vs. Mach, etc. + <youpi> that'd be good, indeed + <youpi> I'm getting 4MiB/s with dde + <youpi> I don't remember with mach + <tschwinge> Yes. It just shouldn't regress too much. + <tschwinge> Aha, OK. + + +## IRC, freenode, #hurd, 2012-02-27 + + <youpi> tschwinge: nttcp tells me ~80Mbps for mach-rtl8139, ~72Mbps for + dde-rtl8139, ~72Mbps for dde-e1000 + <youpi> civodul: ↑ btw + <ArneBab> youpi: so the dde network device is not much slower than the + kernel-one? + <civodul> youpi: yes, looks good + <ArneBab> rather almost the same speed + <youpi> apparently + <ArneBab> that’s quite a deal. + <ArneBab> what speed should it have as maximum? + <ArneBab> (means: does the mach version get out all that’s possible?) + <ArneBab> differently put: What speed would GNU/Linux get? + <youpi> I'm checking that right now + <ArneBab> cool! + <ArneBab> we need those numbers for the moth after the next + <youpi> Mmm, I'm not sure you really want the linux number :) + <youpi> 1.6Gbps :) + <ArneBab> oh… + <youpi> let me check with udp rather than tcp + <ArneBab> so the Hurd is a “tiny bit” worse at using the network… + <youpi> it might simply be an issue with tcp tuning in pfinet + <ArneBab> hm, yes + <ArneBab> tcp is not that cheap + <ArneBab> and has some pretty advanced stuff for getting to high speeds + <youpi> well, I'm not thinking about being cheap + <youpi> but using more recent tuning + <youpi> that does not believe only 1Mbps network cards exist :) + <ArneBab> like adaptive windows and such? + <ArneBab> :) + <youpi> yes + * ArneBab remembers that TCP was invented when the connections went over + phone lines - by audio :) + <youpi> yep + <ArneBab> what’s the system load while doing the test? + <youpi> yes, udp seems not so bad + <ArneBab> ah, cool! + <youpi> it's very variable (300-3000Mbps), but like on linux + <ArneBab> that pushing it into user space has so low cost is pretty nice. + * ArneBab thinks that that’s a point where Hurd pays off + <youpi> that's actually what AST said to fosdem + <youpi> he doesn't care about putting an RPC for each and every port i/o + <youpi> because hardware is slow anyway + <ArneBab> jupp + <ArneBab> but it is important to see that in real life + + +# IRC, freenode, #hurd, 2012-04-01 + + <youpi> antrik: I wonder whether you could actually not route the IRQs to a + non-zero ring, AIUI you can in the x86 IDT table + <antrik> youpi: you mean having a userspace server for each (non-timer) + interrupt? + <antrik> youpi: how would a userspace IRQ handler interact with the + scheduler? + <youpi> antrik: it doesn't necessarily have to + <youpi> provided that it's trusted + <antrik> youpi: how would you do CPU time accounting if there is no + interaction with the scheduler?... + <youpi> antrik: you don't necessarily want to care about it + <antrik> youpi: well, that would mean that all drivers handling interrupts + would have to be trusted to not use more than a very small part of CPU + time... + <youpi> yes + <youpi> which is usually needed for interrupt handlers anyway + <antrik> youpi: nah, the bottom handler only has to do very basic stuff; + afterwards, we can pass off to "normal" driver processes, scheduled just + like other processes... but that requires some interaction between the + IRQ handler and the scheduler I think + <youpi> the IRQ handler can wake up a thread, yes + <youpi> no need for anything special there + <antrik> so the userspace IRQ server would just decide what process to wake + up, and then call the scheduler to do a normal task switch? I guess + that's possible; but I'm not sure it would buy much... + <youpi> it would permit userland to quickly react to the IRQ + <youpi> such as acknowledge it to the hardware etc. + <antrik> yeah, but my point is that I don't see much benefit in having this + part of the code isolated in a userspace process... it has to be trusted + anyways, and it's pretty trivial too + <youpi> I never said it was a good idea + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> oh i forgot about my work on pcap + <braunr> is devnode (or devopen or whatever) in the upstream repository now + ? + <antrik> can't say for sure, but I'd be surprised... don't remember seeing + any movement in that regard :-( + <braunr> wasn't it needed for dde ? + <antrik> hm... good point + + +# IRC, freenode, #hurd, 2012-08-14 + + <braunr> it's amazing how much code just gets reimplemented needlessly ... + <braunr> libddekit has its own mutex, condition, semaphore etc.. objects + <braunr> with the *exact* same comment about the dequeueing-on-timeout + problem found in libpthread + <braunr> *sigh* + + + +# IRC, freenode, #hurd, 2012-08-18 + + <braunr> hum, leaks and potential deadlocks in libddekit/thread.c :/ + + +# IRC, freenode, #hurd, 2012-08-18 + + <braunr> nice, dde relies on a race to start .. + + +# IRC, freenode, #hurd, 2012-08-18 + + <braunr> hm looks like if netdde crashes, the kernel doesn't handle it + cleanly, and we can't attach another netdde instance + +[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]] + + +# IRC, freenode, #hurd, 2012-08-21 + +In context of [[libpthread]]. + + <braunr> hm, i thought my pthreads patches introduced a deadlock, but + actually this one is present in the current upstream/debian code :/ + <braunr> (the deadlock occurs when receiving data fast with sftp) + <braunr> either in netdde or pfinet + + +# DDE for Filesystems + +## IRC, freenode, #hurd, 2012-10-07 + + * pinotree wonders whether the dde layer could aldo theorically support + also file systems + <antrik> pinotree: yeah, I also brought up the idea of creating a DDE + extension or DDE-like wrapper for Linux filesystems a while back... don't + know enough about it though to decide whether it's doable + <antrik> OTOH, I'm not sure it would be worthwhile. we still should + probably have a native (not GPLv2-only) implementation for the main FS at + least; so the wrapper would only be for accessing external + partitions/media... + + +# virtio + + +## IRC, freenode, #hurd, 2012-07-01 + + <braunr> hm, i haven't looked but, does someone know if virtio is included + in netdde ? + <youpi> braunr: nope, there's an underlying virtio layer needed before diff --git a/open_issues/debian_cross_toolchain.mdwn b/open_issues/debian_cross_toolchain.mdwn new file mode 100644 index 00000000..e0665466 --- /dev/null +++ b/open_issues/debian_cross_toolchain.mdwn @@ -0,0 +1,15 @@ +[[!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]] + +Have a look at the Debian *Cross Toolchain* project, +<https://alioth.debian.org/projects/crosstoolchain/>, +<http://wiki.debian.org/ToolChain/Cross>. diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn new file mode 100644 index 00000000..8e6c4900 --- /dev/null +++ b/open_issues/debootstrap.mdwn @@ -0,0 +1,24 @@ +[[!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]]."]]"""]] + +\#hurd, freenode, 2010 + + <azeem_> you know, you would really help the Hurd if you tried debootstrap instead + <tschwinge> Oh? Does that have everying in place by now? + <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25 + <azeem_> they are waiting for feedbacl + <azeem_> feedback* + +\#hurd, freenode, June (?) 2010 + + <azeem_> jd823592: if you want to use debootstrap, you should apply a patch + <azeem_> and test + <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731 + <azeem_> we desperately need somebody to test the patch diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn new file mode 100644 index 00000000..b2d49b26 --- /dev/null +++ b/open_issues/debugging.mdwn @@ -0,0 +1,53 @@ +[[!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 +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]]."]]"""]] + + +# Existing + +We have debugging infrastructure. For example: + + * [[GDB]] + + * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]] + + * [[GNU Hurd debugging|hurd/debugging]], including + [[hurd/debugging/rpctrace]], and more. + + +# To Do + + * [[ltrace]] + + * [[latrace]] + + * [[profiling]] + + * *Checkpoint/restart allows the state of a set of processes to be saved to + persistent storage, then restarted at some future time* -- quoting from + Jonathan Corbet's [2010 Linux Kernel Summit + report](http://lwn.net/Articles/412749/). + + This is surely a very useful facility to have for reproducing failures, for + example. But on the other hand it's questionable how it can help with + debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions, + as their state is typically spread between several processes. + + Continues: <http://lwn.net/Articles/414264/>, which introduces + <http://dmtcp.sourceforge.net/>. + + * [[crash_server}}, [[GDB_gcore]], + <http://code.google.com/p/google-coredumper/> + + * [[community/gsoc/project_ideas/libdiskfs_locking]] + + * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> -- + just two examples; there's a lot of such stuff for Linux. + + * [[debugging_gnumach_startup_QEMU_GDB]] diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn new file mode 100644 index 00000000..e3a6b648 --- /dev/null +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -0,0 +1,116 @@ +[[!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="Debugging GNU Mach's startup in QEMU with GDB"]] + +[[!tag open_issue_gdb open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2011-07-14 + + <mcsim> Hello. I have problem with debugging gnumach. I set 2 brakepoints + in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then + I start qemu with patched gnumach kernel and stop at gdt_init. When I + enter command "continue" in gdb, qemu hangs. But when I go step by step, + using command "next", I freely reach idt_init. What can cause this + problem? + <braunr> hm + <braunr> not sure + <braunr> let me try + <braunr> mcsim: works for me :/ + <mcsim> it works without my patch, but with it qemu hangs + <braunr> oh, i thought it worked when not using continue + <mcsim> with my patch I can reach idt_init only using next + <mcsim> and without all works fine + <braunr> mcsim: are you sure you correctly built it with debugging symbols + ? + <mcsim> I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0 + <braunr> hm + <braunr> i have internal kvm errors actually + <braunr> mcsim: do you use kvm ? + <braunr> mcsim: and why break on those functions ? + <braunr> i'm not sure the address space is already fine at this point + <mcsim> no. I don't have hardware virtualisation support. + <braunr> hm actually, you won't be able to use gdb + <braunr> i just remembered how gnumach is linked and mapped :/ + <braunr> the addresses in the elf image are low addresses, matching the + image as it is loaded by the boot loader + <mcsim> I was wondering why qemu hangs. + <braunr> then the kernel uses segmentation to map itself at 2 (or 3 + previously) GiB + <braunr> well, if the addresses are wrong, your breakpoints are wrong + <braunr> i even wonder how it can work when stepping + <braunr> i don't have the issue with x15 because of its linker script + <mcsim> Are there any ways of such debugging without qemu? + <braunr> i don't think so + <braunr> as antrik told you, the in kernel debugger needs many services + running before being usable + <braunr> you'll have to use printf, and there may be steps during bootstrap + when even that isn't available + <mcsim> So I need computer with hardware virtualisation? + <braunr> well, of course stepping works, since the breakpoints are relative + <braunr> no + <braunr> kvm has nothing to do with the problem + <braunr> it's just that the problem appears differently with kvm enabled + <mcsim> ok. thank you. + <braunr> good luck + <antrik> braunr: would it be hard to "fix" gnumach to avoid the + segmentation magic?... + <braunr> antrik: because of the linux drivers, it may + <antrik> or alternatively, implement something in GDB to deal with that?... + <braunr> antrik: i didn't study that part enough to know for sure + <antrik> uhm... why would the Linux drivers depend on that? does Linux also + do such magic?... + <braunr> well it should simply be a matter of shifting the address by a + fixed offset + <braunr> antrik: linux drivers rely on physical memory being allocated + through kmalloc + <braunr> so there must be a direct mapping between virtual kernel memory + and physical memory + <braunr> they don't specifically need that segmentation settings + <braunr> so if you remove the offset implemented through segmentation, you + have to replace it with page mapping + <braunr> and i don't know how much needs to be done for that + <braunr> you also need to link the kernel differently + <antrik> hm, OK + <antrik> so adding GDB support for the offset would probably be easier... + <braunr> yes + <braunr> but using the offset must only be done once segmentation is set up + <braunr> so you must break after gdt_init + <braunr> not on it + <braunr> mcsim: why do you break on these functions btw ? + <mcsim> I just wanted to find out why qemu hangs + <braunr> yes but why those ? + <mcsim> I found out that before gdt_init all workes fine, but after qemu + hangs. So idt_init is just the next function + <braunr> ok + <braunr> and does your patch change something to how segmentation is + initialized ? + <mcsim> now + <mcsim> no + <braunr> try to build it with the regular cflags + <braunr> i don't know if gnumach can work with -O0 + <mcsim> I've tried. But all the same + <mcsim> Regular are -g -O2 + <braunr> can you make your patch available ? + <mcsim> yes + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <antrik> well, if the segmentation stuff is the thing GDB has problems + with, I don't see how it can work without your patch... + <braunr> without ? + <antrik> well, the patch shouldn't affect the segmentation... so I don't + see how it can make a difference + <braunr> he said qemu hanged + <braunr> so let's not introduce gdb yet + <braunr> qemu can hang for other reasons + <antrik> oh, right, without GDB... + <antrik> though if that's what he meant, his statement was very misleading + at least diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn new file mode 100644 index 00000000..9a8e9412 --- /dev/null +++ b/open_issues/default_pager.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-31 + + <antrik> braunr: do you have any idea what could cause the paging errors + long before swap is exhausted? + <braunr> antrik: not really, but i know every project based on the mach vm + have rewritten their swap pager + <antrik> (and also I/O performance steadily dropping before that point is + reached?) + +[[performance/degradation]], [[ext2fs_page_cache_swapping_leak]]. + + <antrik> hm + <braunr> there could too many things + <antrik> perhaps we could "borrow" from one of them? :-) + <braunr> map entry fragmentation for example + <braunr> the freebsd one is the only possible candidate + <braunr> uvm is too different + <braunr> dragonflybsd maybe, but it's very close to freebsd + <braunr> i didn't look at darwin/xnu + + +# [[trust_the_behavior_of_translators]] 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 new file mode 100644 index 00000000..5bda0213 --- /dev/null +++ b/open_issues/device_drivers_and_io_systems.mdwn @@ -0,0 +1,94 @@ +[[!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 +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_hurd]] + +This is a collection of resources concerning *device drivers* and *I/O systems* +in general. + +Also see [[user-space device drivers]]. +[[community/gsoc/project ideas/driver glue code]]. + +[[!toc levels=2]] + + +# Documentation + + * [An I/O System for Mach + 3.0](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.3210), + 1991, Alessandro Forin, David Golub, Brian Bershad + + * [Linux Device Driver Emulation in + Mach](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7252), + 1996, Shantanu Goel, Dan Duchamp + + * [Eliminating receive livelock in an interrupt-driven + kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.8257), + 1997, Jeffrey Mogul, Dec Western, Jeffrey C. Mogul, K. K. Ramakrishnan + + * [IO-Lite: A Unified I/O Buffering and Caching + System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4224), + 1997, Vivek S. Pai, Peter Druschel, Willy Zwaenepoel + + * [The Flux OSKit: A substrate for kernel and language + research](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118.534), + 1997, Bryan Ford, Godmar Back, Greg Benson, Jay Lepreau, Albert Lin, Olin + Shivers + + * [Reuse Linux Device Drivers in Embedded + Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.6951), + 1998, Chi-wei Yang, Paul C. H. Lee, Ruei-Chuan Chang + + * [THINK: A Software Framework for Component-based Operating System + Kernels](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.133.9239), + 2002, Jean-Philippe Fassino, Jean-Bernard Stefani, Julia Lawall, Gilles + Muller + + * [An I/O Architecture for Microkernel-Based Operating + Systems](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.5.4337), + 2003, Hermann Haertig, Jork Loeser, Jork Löser, Frank Mehnert, Lars + Reuther, Martin Pohlack, Alexander Warg + + * [High-Speed I/O: The Operating System as a Signalling + Mechanism](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.9.6991), + 2003, Matthew Burnside, Angelos D. Keromytis + + * [Unmodified device driver reuse and improved system dependability via + virtual + machines](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.5317), + 2004, Joshua Levasseur, Volkmar Uhlig, Jan Stoess, Stefan Götz + + +# External Projects + + * [[/DDE]] + + * [Building Linux Device Drivers on + FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html) + + * [Project UDI](http://www.projectudi.org/), a multi-company effort to define + a Uniform Driver Interface + + * [The Free Software Movement and + UDI](http://www.gnu.org/philosophy/udi.html) + + * [OSKit](http://www.cs.utah.edu/flux/oskit/) + + * [Unofficial OSKit source](http://www.nongnu.org/oskit/) on Savannah + + * [[microkernel/Mach]]-like + + It might be possible to integrate these systems' device drivers, as they're + expected to mostly be using the same interfaces as the current in-kernel + Mach drivers are. + + * OSF Mach + + * Darwin diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn new file mode 100644 index 00000000..64866eb5 --- /dev/null +++ b/open_issues/dir-lookup_authority.mdwn @@ -0,0 +1,68 @@ +[[!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. + + <cfhammar> I have discovered a bug in the dir-lookup protocol though + <cfhammar> Currently, I'm investigating the bug a bit further + <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup + <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable + <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to + <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup + <antrik> cfhammar: I'm not sure this is a bug + <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me + <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority + <antrik> it's kinda consistent with passing normal FDs + <cfhammar> antrik: it should only allow accesses to entries not sub-entries + <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix + <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority + <cfhammar> probably more common, that is + <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs + <antrik> but if it is, it would indeed be good to know what POSIX says about this + <antrik> cfhammar: I don't see how this is related?... + <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to + <antrik> cfhammar: interesting point... + <antrik> cfhammar: do you think this is fixable? + <cfhammar> antrik: Not without (defacto) changing the interface + <cfhammar> e.g only looking up a singe path component at a time + <cfhammar> or doing the auth check lazily on io_reauthenticate + <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether... + <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-( + <cfhammar> diskfs_S_dir_lookup is a very large function, for example + <antrik> cfhammar: OK + <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations... + <cfhammar> we could provide a new RPC while supporting the old one + <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine + <antrik> cfhammar: have you posted your findings to the ML yet? + <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug + <cfhammar> Intrestingly it's the one using all POSIX functions... + <cfhammar> Perhaps its a bug that maskes the lookup bug ;-) + <antrik> I guess there is some quirk which you do not fully understand yet :-) + <cfhammar> Oh, there's always a new quirk to find in the Hurd :-) + <cfhammar> antrik: seems that dir_lookup isn't buggy after all + <cfhammar> antrik: as all FDs are reauthenticated on setauth + <antrik> ah + <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered + <antrik> yeah, that's the idea behind the auth protocol... + <antrik> users obtain specific capabilities by authenticating generic ports against their own ID + <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth + <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable + <antrik> not sure what you mean + <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it + <cfhammar> (as it should be) + <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it + <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits + <youpi> Mmm, openat should however be able to + <youpi> since you've first opened the directory with the auth + <cfhammar> it isn't since open FDs are reauthed on setauth + <cfhammar> not sure whether it should though, Linux behaves the same way atleast + <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn new file mode 100644 index 00000000..d03b733c --- /dev/null +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -0,0 +1,38 @@ +[[!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 +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. + + <Duck> something's broken in ext2, fsck, or the like + <Duck> /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0. + <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524 + <Duck> i'll just check when it is fixed + <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x + <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots + <Duck> antrik: ho, so in my example this could be related to procfs then + <antrik> Duck: don't know... I got it with various terminal-related nodes + <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there + <antrik> unless the machine crashes of course + <antrik> ah, right, it told you that it's the /proc node :-) + <antrik> was it the only node it complained about? + <antrik> Duck: ^ + <Duck> antrik: yes, the only one + <youpi> so it's most probably i + <youpi> t + <Duck> but currently i don't have much translators around besides the base install + <antrik> that's strange... my theory about translators active at reboot seems wrong then + <youpi> well, maybe procps is not behaving properly + <youpi> procfs* + <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well + <youpi> k + <antrik> 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>. diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn new file mode 100644 index 00000000..ee372971 --- /dev/null +++ b/open_issues/elinks.mdwn @@ -0,0 +1,28 @@ +[[!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_porting]] + +IRC, unknown channel, 2008-05-26 and later + + <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this? + <youpi> eeerf + <youpi> I had never seen a program assuming that + <youpi> that sucks + <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects. + <youpi> fixed where ? + <paakku> in elinks + <youpi> k + <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable. + <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report. + + <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013 + <kahmalo> or to one of our mailing lists. + <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed? diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn new file mode 100644 index 00000000..cdd1b10d --- /dev/null +++ b/open_issues/emacs.mdwn @@ -0,0 +1,1527 @@ +[[!meta copyright="Copyright © 2009 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="GNU Emacs"]] + +[[!tag open_issue_porting]] + +GNU Emacs mostly does work, however there are a few issues. + + * `dired` on a directory hangs. (Use `C-g C-g` to break the unresponsive + operation.) + + * Configuration in `src/s/`: `gnu.h` uses `bsd-common.h`. `gnu-kfreebsd.h` + uses `gnu-linux.h` -- we probably should too. + + * `gnu-linux.h` makes a few things depend on `/proc` (also see + `HAVE_PROCFS`) -- either resort to our own ways, or enhance our + [[hurd/translator/procfs]] accordingly. + + * `sysdep.c` + + * Got a hang when compiling GNU Emacs 23, when it was compiling `.el` to + `.elc` files. Looked like busy-looping inside glibc. This was not + reproducible so far. + + * Debian emacs23_23.1+1-2, grubber, (probably) busy-looping in `ext2fs` on + `/media/data` when resuming emacs23 build in `~/tmp/emacs/emacs23-*/` + (`dpkg-buildpackage -B -uc -nc 2>&1 | tee L`). No modifications to + `emacs23-*` so far, I think. Hangs always in the same place, it seems, and + reproducible. Tarred to `emacs23-23.1+1.tar.bz2` (beware: empty and + zero-permission files: + `emacs23-23.1+1/.pc/debian-site-init-el.diff/lisp/site-init.el`, + `emacs23-23.1+1/.pc/autofiles.diff/src/config.in~`). At hang-time: the + rootfs is fine (`syncfs -c -s /` works; `syncfs` involving `/media/data` + hangs). Plan: GDB on that ext2fs, and see what's hanging / locked. [[!tag + open_issue_hurd]] + + +--- + +# 2010-10-11 + +Apparently, none of the Debian emacs packages are installable at the moment. + +Try to compile bzr trunk. + +System (sort-of) crashed during build. Perhaps while / or shortly after +dumping `src/emacs`, as there was such a zero-sized file. (Log file doesn't +show anything useful.) Removed the truncated `src/emacs`, continued build: + + [...] + Compiling /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el + Parsing *srecode-map-tmp* (LALR)... + Parsing *srecode-map-tmp* (LALR)...done + Segmentation fault + make[2]: *** [cedet/srecode/mode.elc] Error 139 + make[2]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' + make[1]: *** [compile-main] Error 2 + make[1]: Leaving directory `/media/data/home/tschwinge/tmp/emacs/trunk.build/lisp' + make: *** [lisp] Error 2 + +Command line: + + $ EMACSLOADPATH=/home/tschwinge/tmp/emacs/trunk/lisp LC_ALL=C /home/tschwinge/tmp/emacs/trunk.build/src/emacs -batch --no-site-file -f batch-byte-compile /home/tschwinge/tmp/emacs/trunk/lisp/cedet/srecode/mode.el + +GDB: + + Program received signal SIGSEGV, Segmentation fault. + mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 + 5343 if (STRING_MARKED_P (ptr)) + (gdb) bt + #0 mark_object (arg=1) at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:5343 + #1 0x0818080f in Fgarbage_collect () at /home/tschwinge/tmp/emacs/trunk/src/alloc.c:4993 + #2 0x08196db3 in Ffuncall (nargs=1, args=0x23fce70) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2987 + #3 0x081ce8e1 in Fbyte_code (bytestr=139696577, vector=141708997, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #4 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #5 0x08196bb3 in Ffuncall (nargs=1, args=0x23fcff0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #6 0x081ce8e1 in Fbyte_code (bytestr=139922913, vector=141583493, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #7 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #8 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd170) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #9 0x081ce8e1 in Fbyte_code (bytestr=140515737, vector=141583205, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #10 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #11 0x08196bb3 in Ffuncall (nargs=2, args=0x23fd2f0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #12 0x081ce8e1 in Fbyte_code (bytestr=139911193, vector=139312997, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #13 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #14 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #15 0x081ce8e1 in Fbyte_code (bytestr=136508105, vector=136508125, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #16 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #17 0x08196bb3 in Ffuncall (nargs=3, args=0x23fd5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #18 0x081ce8e1 in Fbyte_code (bytestr=136508849, vector=136508869, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #19 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #20 0x08195bff in apply_lambda (fun=136508805, args=139814646, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #21 0x08195ef4 in Feval (form=139814582) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #22 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139636697, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #23 0x081bbad7 in Fload (file=140023529, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #24 0x081a1357 in Frequire (feature=141037690, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #25 0x08196d83 in Ffuncall (nargs=2, args=0x23fdb90) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #26 0x081ce8e1 in Fbyte_code (bytestr=140023705, vector=141489853, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #27 0x08196304 in Feval (form=141177630) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 + #28 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=140023785, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #29 0x081bbad7 in Fload (file=139743441, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #30 0x081a1357 in Frequire (feature=140528330, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #31 0x08196d83 in Ffuncall (nargs=2, args=0x23fe030) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #32 0x081ce8e1 in Fbyte_code (bytestr=139743489, vector=139592949, maxdepth=8) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #33 0x08196304 in Feval (form=139785254) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2358 + #34 0x081bb206 in readevalloop (readcharfun=138475290, stream=<value optimized out>, sourcename=139743569, printflag=0, unibyte=138364586, readfun=138364586, + start=138364586, end=138364586, evalfun=<value optimized out>) at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1734 + #35 0x081bbad7 in Fload (file=139985769, noerror=138364586, nomessage=138364610, nosuffix=138364586, must_suffix=138364586) + at /home/tschwinge/tmp/emacs/trunk/src/lread.c:1225 + #36 0x081a1357 in Frequire (feature=140528282, filename=138364586, noerror=138364586) at /home/tschwinge/tmp/emacs/trunk/src/fns.c:2694 + #37 0x08196d83 in Ffuncall (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2996 + #38 0x0819879e in Fapply (nargs=2, args=0x23fe5c4) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2453 + #39 0x08196e26 in Ffuncall (nargs=3, args=0x23fe5c0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2971 + #40 0x081ce8e1 in Fbyte_code (bytestr=139665665, vector=140243293, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #41 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #42 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe730) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #43 0x081ce8e1 in Fbyte_code (bytestr=139663633, vector=140113917, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #44 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #45 0x08196bb3 in Ffuncall (nargs=2, args=0x23fe8a0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #46 0x081ce8e1 in Fbyte_code (bytestr=139651313, vector=141733317, maxdepth=16) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #47 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #48 0x08196bb3 in Ffuncall (nargs=1, args=0x23fea20) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #49 0x081961cd in Feval (form=142062606) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2324 + #50 0x08198ec2 in internal_lisp_condition_case (var=139619738, bodyform=142062606, handlers=142059126) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 + #51 0x081cdb3a in Fbyte_code (bytestr=139651065, vector=138947149, maxdepth=64) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 + #52 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #53 0x08196bb3 in Ffuncall (nargs=3, args=0x23fed10) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #54 0x081ce8e1 in Fbyte_code (bytestr=139638617, vector=140190309, maxdepth=32) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #55 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #56 0x08195bff in apply_lambda (fun=141815293, args=139024998, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #57 0x08195ef4 in Feval (form=139025038) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #58 0x08198ec2 in internal_lisp_condition_case (var=138727490, bodyform=139025038, handlers=138994086) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1407 + #59 0x081cdb3a in Fbyte_code (bytestr=141397873, vector=139422605, maxdepth=12) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:869 + #60 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #61 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff150) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #62 0x081ce8e1 in Fbyte_code (bytestr=141396361, vector=138448733, maxdepth=20) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #63 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #64 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff2d0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #65 0x081ce8e1 in Fbyte_code (bytestr=136699577, vector=136699597, maxdepth=40) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #66 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #67 0x08196bb3 in Ffuncall (nargs=2, args=0x23ff460) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #68 0x081ce8e1 in Fbyte_code (bytestr=136685793, vector=136685813, maxdepth=28) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #69 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #70 0x08196bb3 in Ffuncall (nargs=1, args=0x23ff5e0) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3047 + #71 0x081ce8e1 in Fbyte_code (bytestr=136683265, vector=136683285, maxdepth=24) at /home/tschwinge/tmp/emacs/trunk/src/bytecode.c:679 + #72 0x08196894 in funcall_lambda (fun=<value optimized out>, nargs=<value optimized out>, arg_vector=0x1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3174 + #73 0x08195bff in apply_lambda (fun=136683245, args=138364586, eval_flag=1) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:3100 + #74 0x08195ef4 in Feval (form=138740766) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:2412 + #75 0x0812dd83 in top_level_2 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1336 + #76 0x081951dc in internal_condition_case (bfun=0x812dd70 <top_level_2>, handlers=138394034, hfun=0x8132020 <cmd_error>) + at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1460 + #77 0x08131de5 in top_level_1 (ignore=138364586) at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1344 + #78 0x081952a9 in internal_catch (tag=138392170, func=0x8131d80 <top_level_1>, arg=138364586) at /home/tschwinge/tmp/emacs/trunk/src/eval.c:1204 + #79 0x08131e53 in command_loop () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:1299 + #80 0x0813220a in recursive_edit_1 () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:929 + #81 0x08132332 in Frecursive_edit () at /home/tschwinge/tmp/emacs/trunk/src/keyboard.c:991 + #82 0x0812727b in main (argc=<value optimized out>, argv=0x23ffad8) at /home/tschwinge/tmp/emacs/trunk/src/emacs.c:1718 + +Next: restarted from scratch, rebuilt without optimizations. +`--prefix=$PWD.install --build=i686-pc-gnu --enable-asserts +--enable-checking=all CFLAGS=-g` + + $ make + [...] + Dumping under the name emacs [sits here for a long time] + + $ vmstat + pagesize: 4K + size: 324M + free: 9.16M + active: 56M + inactive: 242M + wired: 17.6M + zero filled: 8.75G + reactivated: 0 + pageins: 289M + pageouts: 371M + page faults: 12508128 + cow faults: 1411724 + memobj hit ratio: 99% + swap size: 512M + swap free: 512M + +Apparently low memory, but doesn't swap out. + +Uses a lot of CPU time, as observed with `xm top`. + +Creating another `screen` window as user tschwinge doesn't get to the shell +prompt. + +Running `vmstat` works in a `screen` window that is already open, but running +`ps -Af` just hangs; adding `-M` helps. + +Perhaps the /media/data/ file system (which backs /home/) is in a inconsistent +state / deadlocked? + +More specifically, this does not work / does not exit: + + login> syncfs -s -c /media/data/ & + [2] 10785 + +But this works: + + login> syncfs -s -c / & + [3] 10786 + login> + [3]+ Done syncfs -s -c / + +Thus, the rootfs still is responsive; /media/data/ is not. + + login> ps -F hurd-long -T -M -w -A & + [4] 10796 + login> PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc + 0 0.0 0:00.00 0:00.13 + 1 0.0 0:00.30 0:03.55 + 2 0.0 0:00.30 0:04.21 + 3 0.0 0:00.65 0:06.88 + 4 0.0 0:00.02 0:00.31 + 5 0.0 0:00.32 0:03.72 + 6 0.0 0:00.00 0:00.23 + 7 0.0 0:00.00 0:00.03 + 8 0.0 0:00.30 0:03.17 + 9 0.0 0:00.47 0:04.69 + 10 0.0 0:00.62 0:06.42 + 11 0.0 0:00.40 0:05.91 + 12 0.0 0:00.47 0:04.18 + 13 0.0 0:00.10 0:00.73 + 14 0.0 0:00.56 0:05.97 + 15 0.0 0:00.26 0:04.61 + 1 0 1 1 1 1 146M 368K 0.0 0:00.00 0:00.03 /hurd/init root=device:hd0 + 0 0.0 0:00.00 0:00.03 + 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 + 0 0.0 0:00.00 0:00.00 + 1 92.6 0:00.00 46:33.66 + 2 0.0 0:00.00 0:12.07 + 3 0.0 0:00.00 0:00.05 + 4 0.0 0:00.00 0:00.02 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.01 + 3 0 1 1 1 173 409M 15.7M 0.2 4:39.39 34:08.86 ext2fs -A --multiboot-command-line=root=device:hd0 --host-priv-port=1 --device-master-port=2 -- + [165CM-exec-server-task=3 -T typed device:hd0 + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:21.78 2:32.67 + 2 0.0 0:00.15 0:01.33 + 3 0.0 0:00.07 0:01.13 + 4 0.0 0:22.09 2:32.56 + 5 0.0 0:00.11 0:01.30 + 6 0.0 0:21.57 2:32.78 + 7 0.2 0:04.10 0:54.37 + 8 0.0 0:00.00 0:00.01 + 9 0.0 0:20.96 2:30.00 + 10 0.0 0:00.09 0:01.05 + 11 0.0 0:00.09 0:00.94 + 12 0.0 0:21.59 2:32.40 + 13 0.0 0:21.50 2:32.02 + 14 0.0 0:00.00 0:00.92 + 15 0.0 0:00.07 0:00.60 + 16 0.0 0:00.09 0:00.86 + 17 0.0 0:00.04 0:00.88 + 18 0.0 0:00.13 0:00.91 + 19 0.0 0:00.04 0:00.91 + 20 0.0 0:00.02 0:00.89 + 21 0.0 0:00.08 0:00.97 + 22 0.0 0:00.05 0:00.84 + 23 0.0 0:00.04 0:00.86 + 24 0.0 0:00.09 0:00.86 + 25 0.0 0:00.11 0:00.88 + 26 0.0 0:00.04 0:00.64 + 27 0.0 0:21.10 2:32.22 + 28 0.0 0:20.32 2:29.92 + 29 0.0 0:20.58 2:31.51 + 30 0.0 0:20.50 2:32.72 + 31 0.0 0:21.05 2:30.05 + 32 0.0 0:19.78 2:33.40 + 33 0.0 0:20.55 2:31.88 + 34 0.0 0:00.00 0:00.06 + 35 0.0 0:00.00 0:00.07 + 36 0.0 0:00.00 0:00.02 + 37 0.0 0:00.01 0:00.05 + 38 0.0 0:00.00 0:00.03 + 39 0.0 0:00.00 0:00.02 + 40 0.0 0:00.00 0:00.06 + 41 0.0 0:00.02 0:00.02 + 42 0.0 0:00.00 0:00.03 + 43 0.0 0:00.00 0:00.05 + 44 0.0 0:00.00 0:00.07 + 45 0.0 0:00.00 0:00.02 + 46 0.0 0:00.00 0:00.02 + 47 0.0 0:00.00 0:00.04 + 48 0.0 0:00.00 0:00.03 + 49 0.0 0:00.00 0:00.03 + 50 0.0 0:00.00 0:00.05 + 51 0.0 0:00.00 0:00.05 + 52 0.0 0:00.00 0:00.04 + 53 0.0 0:00.00 0:00.04 + 54 0.0 0:00.00 0:00.02 + 55 0.0 0:00.00 0:00.03 + 56 0.0 0:00.01 0:00.01 + 57 0.0 0:00.03 0:00.01 + 58 0.0 0:00.01 0:00.00 + 59 0.0 0:00.00 0:00.00 + 60 0.0 0:00.00 0:00.00 + 61 0.0 0:00.00 0:00.03 + 62 0.0 0:00.00 0:00.00 + 63 0.0 0:00.00 0:00.08 + 64 0.0 0:00.00 0:00.06 + 65 0.0 0:00.01 0:00.00 + 66 0.0 0:00.00 0:00.07 + 67 0.0 0:00.00 0:00.01 + 68 0.0 0:00.02 0:00.02 + 69 0.0 0:00.01 0:00.02 + 70 0.0 0:00.01 0:00.01 + 71 0.0 0:00.01 0:00.04 + 72 0.0 0:00.00 0:00.01 + 73 0.0 0:00.01 0:00.00 + 74 0.0 0:00.00 0:00.06 + 75 0.0 0:00.00 0:00.04 + 76 0.0 0:00.02 0:00.05 + 77 0.0 0:00.00 0:00.03 + 78 0.0 0:00.00 0:00.02 + 79 0.0 0:00.00 0:00.05 + 80 0.0 0:00.01 0:00.00 + 81 0.0 0:00.00 0:00.02 + 82 0.0 0:00.00 0:00.03 + 83 0.0 0:00.00 0:00.00 + 84 0.0 0:00.00 0:00.00 + 85 0.0 0:00.00 0:00.04 + 86 0.0 0:00.00 0:00.04 + 87 0.0 0:00.00 0:00.02 + 88 0.0 0:00.01 0:00.00 + 89 0.0 0:00.00 0:00.04 + 90 0.0 0:00.00 0:00.04 + 91 0.0 0:00.00 0:00.05 + 92 0.0 0:00.00 0:00.02 + 93 0.0 0:00.00 0:00.03 + 94 0.0 0:00.00 0:00.02 + 95 0.0 0:00.00 0:00.01 + 96 0.0 0:00.00 0:00.02 + 97 0.0 0:00.00 0:00.03 + 98 0.0 0:00.00 0:00.05 + 99 0.0 0:00.00 0:00.04 + 100 0.0 0:00.00 0:00.03 + 101 0.0 0:00.00 0:00.01 + 102 0.0 0:00.00 0:00.01 + 103 0.0 0:00.00 0:00.05 + 104 0.0 0:00.00 0:00.06 + 105 0.0 0:00.01 0:00.04 + 106 0.0 0:00.00 0:00.00 + 107 0.0 0:00.01 0:00.02 + 108 0.0 0:00.00 0:00.00 + 109 0.0 0:00.00 0:00.02 + 110 0.0 0:00.00 0:00.01 + 111 0.0 0:00.00 0:00.02 + 112 0.0 0:00.01 0:00.04 + 113 0.0 0:00.01 0:00.01 + 114 0.0 0:00.00 0:00.02 + 115 0.0 0:00.01 0:00.02 + 116 0.0 0:00.01 0:00.03 + 117 0.0 0:00.00 0:00.03 + 118 0.0 0:00.01 0:00.01 + 119 0.0 0:00.00 0:00.01 + 120 0.0 0:00.00 0:00.05 + 121 0.0 0:00.00 0:00.02 + 122 0.0 0:00.00 0:00.02 + 123 0.0 0:00.00 0:00.04 + 124 0.0 0:00.00 0:00.04 + 125 0.0 0:00.00 0:00.02 + 126 0.0 0:00.00 0:00.02 + 127 0.0 0:00.01 0:00.01 + 128 0.0 0:00.00 0:00.01 + 129 0.0 0:00.01 0:00.03 + 130 0.0 0:00.01 0:00.05 + 131 0.0 0:00.00 0:00.02 + 132 0.0 0:00.00 0:00.03 + 133 0.0 0:00.00 0:00.03 + 134 0.0 0:00.00 0:00.02 + 135 0.0 0:00.00 0:00.00 + 136 0.0 0:00.00 0:00.01 + 137 0.0 0:00.01 0:00.03 + 138 0.0 0:00.00 0:00.03 + 139 0.0 0:00.00 0:00.02 + 140 0.0 0:00.01 0:00.01 + 141 0.0 0:00.01 0:00.02 + 142 0.0 0:00.00 0:00.00 + 143 0.0 0:00.00 0:00.02 + 144 0.0 0:00.01 0:00.00 + 145 0.0 0:00.00 0:00.01 + 146 0.0 0:00.00 0:00.00 + 147 0.0 0:00.00 0:00.00 + 148 0.0 0:00.00 0:00.03 + 149 0.0 0:00.00 0:00.00 + 150 0.0 0:00.00 0:00.01 + 151 0.0 0:00.00 0:00.00 + 152 0.0 0:00.00 0:00.01 + 153 0.0 0:00.00 0:00.00 + 154 0.0 0:00.00 0:00.00 + 155 0.0 0:00.00 0:00.00 + 156 0.0 0:00.00 0:00.00 + 157 0.0 0:00.00 0:00.01 + 158 0.0 0:00.00 0:00.00 + 159 0.0 0:00.00 0:00.01 + 160 0.0 0:00.00 0:00.01 + 161 0.0 0:00.00 0:00.00 + 162 0.0 0:00.00 0:00.00 + 163 0.0 0:00.00 0:00.00 + 164 0.0 0:00.00 0:00.01 + 165 0.0 0:00.00 0:00.00 + 166 0.0 0:00.00 0:00.00 + 167 0.0 0:00.00 0:00.00 + 168 0.0 0:00.00 0:00.00 + 169 0.0 0:00.00 0:00.00 + 170 0.0 0:00.00 0:00.00 + 171 0.0 0:00.00 0:00.00 + 172 0.0 0:00.00 0:00.00 + 4 0 3 1 1 6 131M 1.32M 0.0 0:02.20 0:26.26 /hurd/exec + 0 0.0 0:00.43 0:05.32 + 1 0.0 0:00.41 0:05.54 + 2 0.0 0:00.44 0:05.38 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.45 0:05.05 + 5 0.0 0:00.44 0:04.95 + 5 0 1 1 1 6 130M 580K 0.0 0:01.17 0:14.92 /hurd/auth + 0 0.0 0:00.20 0:02.99 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.24 0:03.03 + 3 0.0 0:00.18 0:02.86 + 4 0.0 0:00.22 0:03.01 + 5 0.0 0:00.31 0:03.01 + 6 0 1 6 6 2 147M 1.09M 0.0 0:00.01 0:00.13 /bin/bash /libexec/runsystem root=device:hd0 + 0 0.0 0:00.01 0:00.13 + 1 0.0 0:00.00 0:00.00 + 7 0 3 1 1 7 130M 880K 0.1 0:00.35 0:10.10 /hurd/term /dev/console device console + 0 0.0 0:00.07 0:01.15 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:00.14 0:03.10 + 3 0.1 0:00.10 0:01.87 + 4 0.0 0:00.01 0:00.50 + 5 0.0 0:00.00 0:01.54 + 6 0.0 0:00.02 0:01.91 + 9 0 3 1 1 19 131M 1.13M 0.0 0:05.41 1:17.29 /hurd/pflocal + 0 0.0 0:00.06 0:00.48 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.05 0:00.48 + 3 0.0 0:00.78 0:09.10 + 4 0.0 0:00.49 0:06.13 + 5 0.0 0:00.56 0:07.07 + 6 0.0 0:00.30 0:03.41 + 7 0.0 0:00.47 0:05.58 + 8 0.0 0:00.27 0:06.00 + 9 0.0 0:00.04 0:00.47 + 10 0.0 0:00.43 0:06.17 + 11 0.0 0:00.70 0:09.21 + 12 0.0 0:00.00 0:00.04 + 13 0.0 0:00.59 0:10.75 + 14 0.0 0:00.14 0:01.86 + 15 0.0 0:00.04 0:01.49 + 16 0.0 0:00.02 0:00.76 + 17 0.0 0:00.22 0:05.59 + 18 0.0 0:00.16 0:02.62 + 12 0 1 12 12 6 129M 1.2M 0.0 0:00.00 0:00.06 /hurd/mach-defpager + 0 0.0 0:00.00 0:00.06 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.00 + 14 0 3 1 1 3 131M 504K 0.0 0:00.00 0:00.05 /hurd/storeio hd1 + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 18 0 3 1 1 3 131M 512K 0.0 0:00.39 0:06.71 /hurd/storeio hd0 + 0 0.0 0:00.13 0:01.66 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.25 0:05.04 + 19 0 3 1 1 3 131M 656K 0.0 0:00.27 0:04.89 /hurd/storeio hd2 + 0 0.0 0:00.10 0:01.48 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.16 0:03.41 + 21 0 3 1 1 4 130M 648K 0.0 0:00.55 0:06.94 /hurd/null + 0 0.0 0:00.24 0:02.09 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.08 0:02.16 + 3 0.0 0:00.22 0:02.68 + 22 0 3 1 1 4 130M 820K 0.0 0:00.00 0:00.05 /hurd/procfs + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 71 1 1 71 71 2 146M 728K 0.0 0:00.00 0:00.03 /usr/sbin/atd + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 77 0 3 1 1 4 130M 896K 0.0 0:00.00 0:00.02 /hurd/streamio kmsg + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 117 0 1 117 117 2 146M 1.02M 0.0 0:00.00 0:00.04 /usr/sbin/cron + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 122 101 1 122 122 2 7.75M 1.07M 0.0 0:00.00 0:00.05 /usr/bin/dbus-daemon --system + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 128 0 3 1 1 4 130M 908K 0.0 0:00.00 0:00.02 /hurd/fifo + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 131 8 1 6 6 2 147M 880K 0.0 0:00.01 0:00.07 /usr/sbin/nullmailer-send -d + 0 0.0 0:00.01 0:00.07 + 1 0.0 0:00.00 0:00.00 + 139 0 3 1 1 19 133M 2.19M 0.3 0:18.66 1:17.98 /hurd/pfinet -i eth0 -a 192.168.10.63 -g 192.168.10.1 -m 255.255.255.0 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.1 0:12.72 0:14.56 + 3 0.2 0:01.65 0:12.23 + 4 0.0 0:01.67 0:18.56 + 5 0.0 0:00.50 0:05.93 + 6 0.0 0:00.40 0:06.16 + 7 0.0 0:00.57 0:05.95 + 8 0.0 0:00.30 0:04.15 + 9 0.0 0:00.15 0:01.92 + 10 0.0 0:00.13 0:01.45 + 11 0.0 0:00.14 0:01.47 + 12 0.0 0:00.07 0:01.06 + 13 0.0 0:00.08 0:01.23 + 14 0.0 0:00.08 0:00.92 + 15 0.0 0:00.03 0:00.63 + 16 0.0 0:00.03 0:00.45 + 17 0.0 0:00.05 0:00.72 + 18 0.0 0:00.03 0:00.49 + 140 0 3 1 1 3 131M 1.16M 0.0 0:00.00 0:00.05 /hurd/storeio --no-cache time + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 142 0 1 142 142 2 10.5M 1.23M 0.0 0:00.00 0:00.05 /usr/sbin/sshd + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 157 0 3 1 1 6 130M 1M 0.0 0:00.02 0:00.01 /hurd/term /dev/tty1 hurdio /dev/vcs/1/console + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.01 0:00.00 + 158 0 6 158 158 2 146M 824K 0.0 0:00.00 0:00.01 /libexec/runttys + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 159 0 3 1 1 15 133M 1.67M 0.0 0:00.01 0:00.06 /hurd/console + 0 0.0 0:00.01 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.00 + 7 0.0 0:00.00 0:00.02 + 8 0.0 0:00.00 0:00.00 + 9 0.0 0:00.00 0:00.00 + 10 0.0 0:00.00 0:00.00 + 11 0.0 0:00.00 0:00.00 + 12 0.0 0:00.00 0:00.01 + 13 0.0 0:00.00 0:00.00 + 14 0.0 0:00.00 0:00.00 + 160 - 158 160 160 2 147M 1.82M 0.0 0:00.02 0:00.16 -login prompt (bash) + 0 0.0 0:00.02 0:00.14 + 1 0.0 0:00.00 0:00.02 + 161 - 158 161 161 2 147M 1.78M 0.0 0:00.00 0:00.07 -login prompt (bash) + 0 0.0 0:00.00 0:00.07 + 1 0.0 0:00.00 0:00.00 + 162 - 158 162 162 2 147M 1.78M 0.0 0:00.01 0:00.07 -login prompt (bash) + 0 0.0 0:00.01 0:00.07 + 1 0.0 0:00.00 0:00.00 + 163 - 158 163 163 2 147M 1.78M 0.0 0:00.00 0:00.03 -login prompt (bash) + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + 164 - 158 164 164 2 147M 1.78M 0.0 0:00.02 0:00.03 -login prompt (bash) + 0 0.0 0:00.02 0:00.03 + 1 0.0 0:00.00 0:00.00 + 165 - 158 165 165 2 147M 1.78M 0.0 0:00.00 0:00.08 -login prompt (bash) + 0 0.0 0:00.00 0:00.08 + 1 0.0 0:00.00 0:00.00 + 166 - 158 166 166 2 147M 1.78M 0.0 0:00.01 0:00.01 -login prompt (bash) + 0 0.0 0:00.01 0:00.01 + 1 0.0 0:00.00 0:00.00 + 167 0 3 1 1 6 130M 1016K 0.0 0:00.01 0:00.11 /hurd/term /dev/tty2 hurdio /dev/vcs/2/console + 0 0.0 0:00.01 0:00.06 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.01 + 4 0.0 0:00.00 0:00.03 + 5 0.0 0:00.00 0:00.00 + 168 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty3 hurdio /dev/vcs/3/console + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.01 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.01 + 169 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.04 /hurd/term /dev/tty5 hurdio /dev/vcs/5/console + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.04 + 5 0.0 0:00.00 0:00.00 + 170 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.05 /hurd/term /dev/tty4 hurdio /dev/vcs/4/console + 0 0.0 0:00.00 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.01 + 5 0.0 0:00.00 0:00.00 + 171 0 3 1 1 6 130M 1016K 0.0 0:00.00 0:00.01 /hurd/term /dev/tty6 hurdio /dev/vcs/6/console + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 4 0.0 0:00.00 0:00.00 + 5 0.0 0:00.00 0:00.00 + 172 0 3 1 1 4 130M 892K 0.0 0:00.00 0:00.01 /hurd/password + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 3 0.0 0:00.00 0:00.00 + 173 0 142 173 173 3 10.7M 3.09M 0.0 0:02.09 0:12.63 /usr/sbin/sshd -R + 0 0.0 0:02.09 0:12.63 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.0 1:34.24 6:26.66 + 3 0.0 0:00.04 0:00.31 + 4 0.0 0:00.13 0:00.47 + 5 0.0 0:00.05 0:00.57 + 6 0.0 1:36.91 6:26.41 + 7 0.0 0:12.98 0:34.83 + 8 0.0 1:37.85 6:26.20 + 9 0.0 1:35.07 6:17.07 + 10 0.0 0:00.05 0:00.50 + 11 0.0 0:00.04 0:00.48 + 12 0.0 0:00.07 0:00.55 + 13 0.0 0:00.03 0:00.46 + 14 0.0 0:00.03 0:00.42 + 15 0.0 0:00.06 0:00.32 + 16 0.0 0:00.05 0:00.56 + 17 0.0 0:00.05 0:00.50 + 18 0.0 0:00.05 0:00.48 + 19 0.0 0:00.03 0:00.37 + 20 0.0 0:00.08 0:00.48 + 21 0.0 0:00.01 0:00.52 + 22 0.0 0:00.02 0:00.44 + 23 0.0 0:00.02 0:00.44 + 24 0.0 0:00.03 0:00.31 + 25 0.0 0:00.05 0:00.32 + 26 0.0 0:00.04 0:00.37 + 27 0.0 0:00.00 0:00.31 + 28 0.0 0:00.03 0:00.23 + 29 0.0 0:00.05 0:00.33 + 30 0.0 0:00.04 0:00.31 + 31 0.0 0:00.01 0:00.29 + 32 0.0 0:00.07 0:00.27 + 33 0.0 0:00.05 0:00.28 + 34 0.0 0:00.04 0:00.23 + 35 0.0 0:00.04 0:00.46 + 36 0.0 0:00.02 0:00.31 + 37 0.0 0:00.02 0:00.38 + 38 0.0 0:00.06 0:00.29 + 39 0.0 0:00.03 0:00.22 + 40 0.0 0:00.02 0:00.28 + 41 0.0 0:00.03 0:00.26 + 42 0.0 0:00.05 0:00.39 + 43 0.0 0:00.06 0:00.37 + 44 0.0 0:00.03 0:00.36 + 45 0.0 0:00.04 0:00.20 + 46 0.0 0:00.02 0:00.28 + 47 0.0 0:00.01 0:00.29 + 48 0.0 0:00.03 0:00.23 + 49 0.0 0:00.04 0:00.22 + 50 0.0 0:00.07 0:00.25 + 51 0.0 0:00.00 0:00.33 + 52 0.0 0:00.05 0:00.49 + 53 0.0 0:00.02 0:00.31 + 54 0.0 0:00.00 0:00.27 + 55 0.0 0:00.06 0:00.25 + 56 0.0 0:00.05 0:00.35 + 57 0.0 0:00.01 0:00.28 + 58 0.0 0:00.06 0:00.25 + 59 0.0 0:00.05 0:00.30 + 60 0.0 0:00.03 0:00.36 + 61 0.0 0:00.04 0:00.31 + 62 0.0 0:00.05 0:00.18 + 63 0.0 0:00.02 0:00.31 + 64 0.0 0:00.00 0:00.27 + 65 0.0 0:00.02 0:00.26 + 66 0.0 0:00.00 0:00.31 + 67 0.0 0:00.00 0:00.15 + 68 0.0 0:00.04 0:00.32 + 69 0.0 0:00.04 0:00.21 + 70 0.0 0:00.01 0:00.31 + 71 0.0 0:00.05 0:00.22 + 72 0.0 0:00.01 0:00.28 + 73 0.0 0:00.04 0:00.31 + 74 0.0 0:00.06 0:00.20 + 75 0.0 0:00.04 0:00.38 + 76 0.0 0:00.03 0:00.37 + 77 0.0 0:00.06 0:00.32 + 78 0.0 0:00.04 0:00.22 + 79 0.0 0:00.04 0:00.25 + 80 0.0 0:00.04 0:00.29 + 81 0.0 0:00.07 0:00.31 + 82 0.0 0:00.04 0:00.27 + 83 0.0 0:00.04 0:00.23 + 84 0.0 0:00.02 0:00.37 + 85 0.0 0:00.03 0:00.24 + 86 0.0 0:00.01 0:00.29 + 87 0.0 0:00.03 0:00.24 + 88 0.0 0:00.01 0:00.31 + 89 0.0 0:00.03 0:00.39 + 90 0.0 0:00.00 0:00.30 + 91 0.0 0:00.03 0:00.32 + 92 0.0 0:00.00 0:00.24 + 93 0.0 0:00.03 0:00.32 + 94 0.0 0:00.04 0:00.30 + 95 0.0 0:00.00 0:00.33 + 96 0.0 0:00.02 0:00.24 + 97 0.0 0:00.01 0:00.26 + 98 0.0 0:00.04 0:00.33 + 99 0.0 0:00.03 0:00.26 + 100 0.0 0:00.05 0:00.29 + 101 0.0 0:00.05 0:00.34 + 102 0.0 0:00.04 0:00.38 + 103 0.0 0:00.00 0:00.22 + 104 0.0 0:00.03 0:00.38 + 105 0.0 0:00.01 0:00.43 + 106 0.0 0:00.03 0:00.37 + 107 0.0 0:00.05 0:00.31 + 108 0.0 0:00.02 0:00.31 + 109 0.0 0:00.00 0:00.26 + 110 0.0 0:00.03 0:00.27 + 111 0.0 0:00.03 0:00.25 + 112 0.0 0:00.02 0:00.30 + 113 0.0 0:00.05 0:00.23 + 114 0.0 0:00.02 0:00.32 + 115 0.0 0:00.02 0:00.29 + 116 0.0 0:00.04 0:00.22 + 117 0.0 0:00.04 0:00.26 + 118 0.0 0:00.02 0:00.36 + 119 0.0 0:00.03 0:00.31 + 120 0.0 0:00.04 0:00.26 + 121 0.0 0:00.05 0:00.28 + 122 0.0 0:00.01 0:00.27 + 123 0.0 0:00.03 0:00.34 + 124 0.0 0:00.03 0:00.36 + 125 0.0 0:00.02 0:00.33 + 126 0.0 0:00.04 0:00.36 + 127 0.0 0:00.00 0:00.41 + 128 0.0 0:00.02 0:00.33 + 129 0.0 0:00.07 0:00.32 + 130 0.0 0:00.03 0:00.29 + 131 0.0 0:00.00 0:00.34 + 132 0.0 0:00.04 0:00.28 + 133 0.0 0:00.04 0:00.24 + 134 0.0 0:00.03 0:00.35 + 135 0.0 0:00.04 0:00.38 + 136 0.0 0:00.04 0:00.37 + 137 0.0 0:00.04 0:00.26 + 138 0.0 0:00.00 0:00.26 + 139 0.0 0:00.06 0:00.40 + 140 0.0 1:23.58 6:28.86 + 141 0.0 0:25.74 1:55.97 + 142 0.0 0:00.00 0:00.00 + 143 0.0 0:00.00 0:00.00 + 144 0.0 0:00.00 0:00.00 + 145 0.0 0:00.00 0:00.00 + 146 0.0 0:00.00 0:00.00 + 147 0.0 0:00.00 0:00.00 + 148 0.0 0:00.00 0:00.00 + 149 0.0 0:00.00 0:00.00 + 150 0.0 0:00.00 0:00.00 + 151 0.0 0:00.00 0:00.00 + 152 0.0 0:00.00 0:00.00 + 153 0.0 0:00.00 0:00.00 + 154 0.0 0:00.00 0:00.00 + 155 0.0 0:00.00 0:00.00 + 156 0.0 0:00.00 0:00.00 + 157 0.0 0:00.00 0:00.00 + 158 0.0 0:00.00 0:00.00 + 159 0.0 0:00.00 0:00.00 + 160 0.0 0:00.00 0:00.00 + 161 0.0 0:00.00 0:00.00 + 162 0.0 0:00.00 0:00.00 + 163 0.0 0:00.00 0:00.00 + 164 0.0 0:00.00 0:00.00 + 165 0.0 0:00.00 0:00.00 + 166 0.0 0:00.00 0:00.00 + 167 0.0 0:00.00 0:00.00 + 168 0.0 0:00.00 0:00.00 + 169 0.0 0:00.00 0:00.00 + 170 0.0 0:00.00 0:00.00 + 171 0.0 0:00.00 0:00.00 + 172 0.0 0:00.00 0:00.00 + 173 0.0 0:00.00 0:00.00 + 174 0.0 0:00.00 0:00.00 + 175 0.0 0:00.00 0:00.00 + 176 0.0 0:00.00 0:00.00 + 177 0.0 0:00.00 0:00.00 + 178 0.0 0:00.00 0:00.00 + 179 0.0 0:00.00 0:00.00 + 180 0.0 0:00.00 0:00.00 + 181 0.0 0:00.00 0:00.00 + 182 0.0 0:00.00 0:00.00 + 183 0.0 0:00.00 0:00.00 + 184 0.0 0:00.00 0:00.00 + 185 0.0 0:00.00 0:00.00 + 186 0.0 0:00.00 0:00.00 + 187 0.0 0:00.00 0:00.00 + 188 0.0 0:00.00 0:00.00 + 189 0.0 0:00.00 0:00.00 + 190 0.0 0:00.00 0:00.00 + 191 0.0 0:00.00 0:00.00 + 192 0.0 0:00.00 0:00.00 + 193 0.0 0:00.00 0:00.00 + 194 0.0 0:00.00 0:00.00 + 195 0.0 0:00.00 0:00.00 + 196 0.0 0:00.00 0:00.00 + 197 0.0 0:00.00 0:00.00 + 198 0.0 0:00.00 0:00.00 + 199 0.0 0:00.00 0:00.00 + 200 0.0 0:00.00 0:00.00 + 201 0.0 0:00.00 0:00.00 + 202 0.0 0:00.00 0:00.00 + 203 0.0 0:00.00 0:00.00 + 204 0.0 0:00.00 0:00.00 + 205 0.0 0:00.00 0:00.00 + 206 0.0 0:00.00 0:00.00 + 207 0.0 0:00.00 0:00.00 + 208 0.0 0:00.00 0:00.00 + 209 0.0 0:00.00 0:00.00 + 210 0.0 0:00.00 0:00.00 + 211 0.0 0:00.00 0:00.00 + 212 0.0 0:00.00 0:00.00 + 213 0.0 0:00.00 0:00.00 + 214 0.0 0:00.00 0:00.00 + 215 0.0 0:00.00 0:00.00 + 216 0.0 0:00.00 0:00.00 + 217 0.0 0:00.00 0:00.00 + 218 0.0 0:00.00 0:00.00 + 219 0.0 0:00.00 0:00.00 + 220 0.0 0:00.00 0:00.00 + 221 0.0 0:00.00 0:00.00 + 222 0.0 0:00.00 0:00.00 + 223 0.0 0:00.00 0:00.00 + 224 0.0 0:00.00 0:00.00 + 225 0.0 0:00.00 0:00.00 + 226 0.0 0:00.00 0:00.00 + 227 0.0 0:00.00 0:00.00 + 228 0.0 0:00.00 0:00.00 + 229 0.0 0:00.00 0:00.00 + 230 0.0 0:00.00 0:00.00 + 231 0.0 0:00.00 0:00.00 + 232 0.0 0:00.00 0:00.00 + 233 0.0 0:00.00 0:00.00 + 234 0.0 0:00.00 0:00.00 + 235 0.0 0:00.00 0:00.00 + 236 0.0 0:00.00 0:00.00 + 237 0.0 0:00.00 0:00.00 + 238 0.0 0:00.00 0:00.00 + 239 0.0 0:00.00 0:00.00 + 240 0.0 0:00.00 0:00.00 + 241 0.0 0:00.00 0:00.00 + 242 0.0 0:00.00 0:00.00 + 243 0.0 0:00.00 0:00.00 + 244 0.0 0:00.00 0:00.00 + 245 0.0 0:00.00 0:00.00 + 246 0.0 0:00.00 0:00.00 + 247 0.0 0:00.00 0:00.00 + 248 0.0 0:00.00 0:00.00 + 249 0.0 0:00.00 0:00.00 + 250 0.0 0:00.00 0:00.00 + 251 0.0 0:00.00 0:00.00 + 252 0.0 0:00.00 0:00.00 + 253 0.0 0:00.00 0:00.00 + 254 0.0 0:00.00 0:00.00 + 255 0.0 0:00.00 0:00.00 + 256 0.0 0:00.00 0:00.00 + 257 0.0 0:00.00 0:00.00 + 258 0.0 0:00.00 0:00.00 + 259 0.0 0:00.00 0:00.00 + 260 0.0 0:00.00 0:00.00 + 261 0.0 0:00.00 0:00.00 + 262 0.0 0:00.00 0:00.00 + 263 0.0 0:00.00 0:00.00 + 264 0.0 0:00.00 0:00.00 + 265 0.0 0:00.00 0:00.00 + 266 0.0 0:00.00 0:00.00 + 267 0.0 0:00.00 0:00.00 + 268 0.0 0:00.00 0:00.00 + 269 0.0 0:00.00 0:00.00 + 270 0.0 0:00.00 0:00.00 + 271 0.0 0:00.00 0:00.00 + 272 0.0 0:00.00 0:00.00 + 273 0.0 0:00.00 0:00.00 + 274 0.0 0:00.00 0:00.00 + 275 0.0 0:00.00 0:00.00 + 276 0.0 0:00.00 0:00.00 + 277 0.0 0:00.00 0:00.00 + 278 0.0 0:00.00 0:00.00 + 279 0.0 0:00.00 0:00.00 + 280 0.0 0:00.00 0:00.00 + 281 0.0 0:00.00 0:00.00 + 282 0.0 0:00.00 0:00.00 + 283 0.0 0:00.00 0:00.00 + 284 0.0 0:00.00 0:00.00 + 285 0.0 0:00.00 0:00.00 + 286 0.0 0:00.00 0:00.00 + 287 0.0 0:00.00 0:00.00 + 288 0.0 0:00.00 0:00.00 + 289 0.0 0:00.00 0:00.00 + 290 0.0 0:00.00 0:00.00 + 291 0.0 0:00.00 0:00.00 + 292 0.0 0:00.00 0:00.00 + 293 0.0 0:00.00 0:00.00 + 294 0.0 0:00.00 0:00.00 + 295 0.0 0:00.00 0:00.00 + 296 0.0 0:00.00 0:00.00 + 297 0.0 0:00.00 0:00.00 + 298 0.0 0:00.00 0:00.00 + 299 0.0 0:00.00 0:00.00 + 300 0.0 0:00.00 0:00.00 + 301 0.0 0:00.00 0:00.00 + 302 0.0 0:00.00 0:00.00 + 303 0.0 0:00.00 0:00.00 + 304 0.0 0:00.00 0:00.00 + 305 0.0 0:00.00 0:00.00 + 306 0.0 0:00.00 0:00.00 + 307 0.0 0:00.00 0:00.00 + 308 0.0 0:00.00 0:00.00 + 309 0.0 0:00.00 0:00.00 + 310 0.0 0:00.00 0:00.00 + 311 0.0 0:00.00 0:00.00 + 312 0.0 0:00.00 0:00.00 + 313 0.0 0:00.00 0:00.00 + 314 0.0 0:00.00 0:00.00 + 315 0.0 0:00.00 0:00.00 + 316 0.0 0:00.00 0:00.00 + 317 0.0 0:00.00 0:00.00 + 318 0.0 0:00.00 0:00.00 + 319 0.0 0:00.00 0:00.00 + 320 0.0 0:00.00 0:00.00 + 321 0.0 0:00.00 0:00.00 + 322 0.0 0:00.00 0:00.00 + 323 0.0 0:00.00 0:00.00 + 324 0.0 0:00.00 0:00.00 + 325 0.0 0:00.00 0:00.00 + 326 0.0 0:00.00 0:00.00 + 327 0.0 0:00.00 0:00.00 + 328 0.0 0:00.00 0:00.00 + 329 0.0 0:00.00 0:00.00 + 330 0.0 0:00.00 0:00.00 + 331 0.0 0:00.00 0:00.00 + 332 0.0 0:00.00 0:00.00 + 333 0.0 0:00.00 0:00.00 + 334 0.0 0:00.00 0:00.00 + 335 0.0 0:00.00 0:00.00 + 336 0.0 0:00.00 0:00.00 + 337 0.0 0:00.00 0:00.00 + 338 0.0 0:00.00 0:00.00 + 339 0.0 0:00.00 0:00.00 + 340 0.0 0:00.00 0:00.00 + 341 0.0 0:00.00 0:00.00 + 342 0.0 0:00.00 0:00.00 + 343 0.0 0:00.00 0:00.00 + 344 0.0 0:00.00 0:00.00 + 345 0.0 0:00.00 0:00.00 + 346 0.0 0:00.00 0:00.00 + 347 0.0 0:00.00 0:00.00 + 348 0.0 0:00.00 0:00.00 + 349 0.0 0:00.00 0:00.00 + 350 0.0 0:00.00 0:00.00 + 351 0.0 0:00.00 0:00.00 + 352 0.0 0:00.00 0:00.00 + 353 0.0 0:00.00 0:00.00 + 354 0.0 0:00.00 0:00.00 + 355 0.0 0:00.00 0:00.00 + 356 0.0 0:00.00 0:00.00 + 357 0.0 0:00.00 0:00.00 + 358 0.0 0:00.00 0:00.00 + 359 0.0 0:00.00 0:00.00 + 360 0.0 0:00.00 0:00.00 + 361 0.0 0:00.00 0:00.00 + 362 0.0 0:00.00 0:00.00 + 363 0.0 0:00.00 0:00.00 + 364 0.0 0:00.00 0:00.00 + 365 0.0 0:00.00 0:00.00 + 366 0.0 0:00.00 0:00.00 + 367 0.0 0:00.00 0:00.00 + 368 0.0 0:00.00 0:00.00 + 369 0.0 0:00.00 0:00.00 + 370 0.0 0:00.00 0:00.00 + 371 0.0 0:00.00 0:00.03 + 372 0.0 0:00.00 0:00.00 + 373 0.0 0:00.00 0:00.00 + 374 0.0 0:00.00 0:00.00 + 375 0.0 0:00.00 0:00.00 + 376 0.0 0:00.00 0:00.00 + 377 0.0 0:00.00 0:00.00 + 378 0.0 0:00.00 0:00.00 + 379 0.0 0:00.00 0:00.00 + 380 0.0 0:00.00 0:00.00 + 381 0.0 0:00.00 0:00.00 + 382 0.0 0:00.00 0:00.00 + 383 0.0 0:00.00 0:00.00 + 384 0.0 0:00.00 0:00.00 + 385 0.0 0:00.00 0:00.00 + 386 0.0 0:00.00 0:00.00 + 387 0.0 0:00.00 0:00.00 + 388 0.0 0:00.00 0:00.00 + 389 0.0 0:00.00 0:00.00 + 390 0.0 0:00.00 0:00.00 + 391 0.0 0:00.00 0:00.00 + 392 0.0 0:00.00 0:00.00 + 393 0.0 0:00.00 0:00.00 + 394 0.0 0:00.00 0:00.00 + 395 0.0 0:00.00 0:00.00 + 396 0.0 0:00.00 0:00.00 + 397 0.0 0:00.00 0:00.00 + 398 0.0 0:00.00 0:00.00 + 399 0.0 0:00.00 0:00.00 + 400 0.0 0:00.00 0:00.00 + 401 0.0 0:00.00 0:00.00 + 402 0.0 0:00.00 0:00.00 + 403 0.0 0:00.00 0:00.00 + 404 0.0 0:00.00 0:00.00 + 405 0.0 0:00.00 0:00.00 + 406 0.0 0:00.00 0:00.00 + 407 0.0 0:00.00 0:00.00 + 408 0.0 0:00.00 0:00.00 + 409 0.0 0:00.00 0:00.00 + 410 0.0 0:00.00 0:00.00 + 411 0.0 0:00.00 0:00.00 + 412 0.0 0:00.00 0:00.00 + 413 0.0 0:00.00 0:00.00 + 414 0.0 0:00.00 0:00.00 + 415 0.0 0:00.00 0:00.00 + 416 0.0 0:00.00 0:00.00 + 417 0.0 0:00.00 0:00.00 + 418 0.0 0:00.00 0:00.00 + 419 0.0 0:00.00 0:00.00 + 420 0.0 0:00.00 0:00.00 + 421 0.0 0:00.00 0:00.00 + 422 0.0 0:00.00 0:00.00 + 423 0.0 0:00.00 0:00.00 + 424 0.0 0:00.00 0:00.00 + 425 0.0 0:00.00 0:00.00 + 426 0.0 0:00.00 0:00.00 + 427 0.0 0:00.00 0:00.00 + 428 0.0 0:00.00 0:00.00 + 429 0.0 0:00.00 0:00.00 + 430 0.0 0:00.00 0:00.00 + 431 0.0 0:00.00 0:00.00 + 432 0.0 0:00.00 0:00.00 + 433 0.0 0:00.00 0:00.00 + 434 0.0 0:00.00 0:00.00 + 435 0.0 0:00.00 0:00.00 + 436 0.0 0:00.00 0:00.00 + 437 0.0 0:00.00 0:00.00 + 438 0.0 0:00.00 0:00.00 + 439 0.0 0:00.00 0:00.00 + 440 0.0 0:00.00 0:00.00 + 441 0.0 0:00.00 0:00.00 + 442 0.0 0:00.00 0:00.00 + 443 0.0 0:00.00 0:00.00 + 444 0.0 0:00.00 0:00.00 + 445 0.0 0:00.00 0:00.00 + 446 0.0 0:00.00 0:00.00 + 447 0.0 0:00.00 0:00.00 + 448 0.0 0:00.00 0:00.00 + 449 0.0 0:00.00 0:00.00 + 450 0.0 0:00.00 0:00.00 + 451 0.0 0:00.00 0:00.00 + 452 0.0 0:00.00 0:00.00 + 453 0.0 0:00.00 0:00.00 + 454 0.0 0:00.00 0:00.00 + 455 0.0 0:00.00 0:00.00 + 456 0.0 0:00.00 0:00.00 + 457 0.0 0:00.00 0:00.00 + 458 0.0 0:00.00 0:00.00 + 459 0.0 0:00.00 0:00.00 + 460 0.0 0:00.00 0:00.00 + 461 0.0 0:00.00 0:00.00 + 462 0.0 0:00.00 0:00.00 + 463 0.0 0:00.00 0:00.00 + 464 0.0 0:00.00 0:00.00 + 465 0.0 0:00.00 0:00.00 + 466 0.0 0:00.00 0:00.00 + 467 0.0 0:00.00 0:00.00 + 468 0.0 0:00.00 0:00.00 + 469 0.0 0:00.00 0:00.00 + 470 0.0 0:00.00 0:00.00 + 471 0.0 0:00.00 0:00.00 + 472 0.0 0:00.00 0:00.00 + 473 0.0 0:00.00 0:00.00 + 474 0.0 0:00.00 0:00.00 + 475 0.0 0:00.00 0:00.00 + 476 0.0 0:00.00 0:00.00 + 477 0.0 0:00.00 0:00.00 + 478 0.0 0:00.00 0:00.00 + 479 0.0 0:00.00 0:00.00 + 480 0.0 0:00.00 0:00.00 + 481 0.0 0:00.00 0:00.00 + 482 0.0 0:00.00 0:00.00 + 483 0.0 0:00.00 0:00.00 + 484 0.0 0:00.00 0:00.00 + 485 0.0 0:00.00 0:00.00 + 486 0.0 0:00.00 0:00.00 + 487 0.0 0:00.00 0:00.00 + 488 0.0 0:00.00 0:00.00 + 489 0.0 0:00.00 0:00.00 + 490 0.0 0:00.00 0:00.00 + 491 0.0 0:00.00 0:00.00 + 492 0.0 0:00.00 0:00.00 + 493 0.0 0:00.00 0:00.00 + 494 0.0 0:00.00 0:00.00 + 495 0.0 0:00.00 0:00.00 + 496 0.0 0:00.00 0:00.00 + 497 0.0 0:00.00 0:00.00 + 498 0.0 0:00.00 0:00.00 + 499 0.0 0:00.00 0:00.00 + 500 0.0 0:00.00 0:00.00 + 501 0.0 0:00.00 0:00.00 + 502 0.0 0:00.00 0:00.00 + 503 0.0 0:00.00 0:00.00 + 504 0.0 0:00.00 0:00.00 + 505 0.0 0:00.00 0:00.00 + 506 0.0 0:00.00 0:00.00 + 507 0.0 0:00.00 0:00.00 + 508 0.0 0:00.00 0:00.00 + 509 0.0 0:00.00 0:00.00 + 510 0.0 0:00.00 0:00.00 + 511 0.0 0:00.00 0:00.00 + 512 0.0 0:00.00 0:00.00 + 513 0.0 0:00.00 0:00.00 + 514 0.0 0:00.00 0:00.00 + 515 0.0 0:00.00 0:00.00 + 516 0.0 0:00.00 0:00.00 + 517 0.0 0:00.00 0:00.00 + 518 0.0 0:00.00 0:00.00 + 519 0.0 0:00.00 0:00.00 + 520 0.0 0:00.00 0:00.00 + 521 0.0 0:00.00 0:00.00 + 522 0.0 0:00.00 0:00.00 + 523 0.0 0:00.00 0:00.00 + 524 0.0 0:00.00 0:00.00 + 525 0.0 0:00.00 0:00.00 + 526 0.0 0:00.00 0:00.00 + 527 0.0 0:00.00 0:00.00 + 528 0.0 0:00.00 0:00.00 + 529 0.0 0:00.00 0:00.00 + 530 0.0 0:00.00 0:00.00 + 531 0.0 0:00.00 0:00.00 + 532 0.0 0:00.00 0:00.00 + 533 0.0 0:00.00 0:00.00 + 534 0.0 0:00.00 0:00.00 + 535 0.0 0:00.00 0:00.00 + 536 0.0 0:00.00 0:00.00 + 537 0.0 0:00.00 0:00.00 + 538 0.0 0:00.00 0:00.00 + 539 0.0 0:00.00 0:00.00 + 540 0.0 0:00.00 0:00.00 + 541 0.0 0:00.00 0:00.00 + 542 0.0 0:00.00 0:00.00 + 543 0.0 0:00.00 0:00.00 + 544 0.0 0:00.00 0:00.00 + 545 0.0 0:00.00 0:00.00 + 546 0.0 0:00.00 0:00.00 + 547 0.0 0:00.00 0:00.00 + 548 0.0 0:00.00 0:00.00 + 549 0.0 0:00.00 0:00.00 + 550 0.0 0:00.00 0:00.00 + 551 0.0 0:00.00 0:00.00 + 552 0.0 0:00.00 0:00.00 + 553 0.0 0:00.00 0:00.00 + 554 0.0 0:00.00 0:00.00 + 555 0.0 0:00.00 0:00.00 + 556 0.0 0:00.00 0:00.00 + 557 0.0 0:00.00 0:00.00 + 558 0.0 0:00.00 0:00.00 + 559 0.0 0:00.00 0:00.00 + 560 0.0 0:00.00 0:00.00 + 561 0.0 0:00.00 0:00.00 + 562 0.0 0:00.00 0:00.00 + 563 0.0 0:00.00 0:00.00 + 564 0.0 0:00.00 0:00.00 + 565 0.0 0:00.00 0:00.00 + 566 0.0 0:00.00 0:00.00 + 567 0.0 0:00.00 0:00.00 + 568 0.0 0:00.00 0:00.00 + 569 0.0 0:00.00 0:00.00 + 570 0.0 0:00.00 0:00.00 + 571 0.0 0:00.00 0:00.00 + 572 0.0 0:00.00 0:00.00 + 573 0.0 0:00.00 0:00.00 + 574 0.0 0:00.00 0:00.00 + 575 0.0 0:00.00 0:00.00 + 576 0.0 0:00.00 0:00.00 + 577 0.0 0:00.00 0:00.00 + 578 0.0 0:00.00 0:00.00 + 579 0.0 0:00.00 0:00.00 + 580 0.0 0:00.00 0:00.00 + 581 0.0 0:00.00 0:00.00 + 582 0.0 0:00.00 0:00.00 + 583 0.0 0:00.00 0:00.00 + 584 0.0 0:00.00 0:00.00 + 585 0.0 0:00.00 0:00.00 + 586 0.0 0:00.00 0:00.00 + 587 0.0 0:00.00 0:00.00 + 588 0.0 0:00.00 0:00.00 + 589 0.0 0:00.00 0:00.00 + 590 0.0 0:00.00 0:00.00 + 591 0.0 0:00.00 0:00.00 + 592 0.0 0:00.00 0:00.00 + 593 0.0 0:00.00 0:00.00 + 594 0.0 0:00.00 0:00.00 + 595 0.0 0:00.00 0:00.00 + 596 0.0 0:00.00 0:00.00 + 597 0.0 0:00.00 0:00.00 + 598 0.0 0:00.00 0:00.00 + 599 0.0 0:00.00 0:00.00 + 600 0.0 0:00.00 0:00.00 + 601 0.0 0:00.00 0:00.00 + 602 0.0 0:00.00 0:00.00 + 603 0.0 0:00.00 0:00.00 + 604 0.0 0:00.00 0:00.00 + 605 0.0 0:00.00 0:00.00 + 606 0.0 0:00.00 0:00.00 + 607 0.0 0:00.00 0:00.00 + 608 0.0 0:00.00 0:00.00 + 609 0.0 0:00.00 0:00.00 + 610 0.0 0:00.00 0:00.00 + 611 0.0 0:00.00 0:00.00 + 612 0.0 0:00.00 0:00.00 + 613 0.0 0:00.00 0:00.00 + 614 0.0 0:00.00 0:00.00 + 615 0.0 0:00.00 0:00.00 + 616 0.0 0:00.00 0:00.00 + 617 0.0 0:00.00 0:00.00 + 618 0.0 0:00.00 0:00.00 + 619 0.0 0:00.00 0:00.00 + 620 0.0 0:00.00 0:00.00 + 621 0.0 0:00.00 0:00.00 + 622 0.0 0:00.00 0:00.00 + 623 0.0 0:00.00 0:00.00 + 624 0.0 0:00.00 0:00.00 + 625 0.0 0:00.00 0:00.00 + 626 0.0 0:00.00 0:00.00 + 627 0.0 0:00.00 0:00.00 + 628 0.0 0:00.00 0:00.00 + 629 0.0 0:00.00 0:00.00 + 630 0.0 0:00.00 0:00.00 + 631 100.3 8:11.86 17:35.07 + 175 0 3 1 1 6 130M 1.08M 0.0 0:03.06 0:33.84 /hurd/term /dev/ptyp0 pty-master /dev/ttyp0 + 0 0.0 0:00.80 0:07.55 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.56 0:05.97 + 3 0.0 0:00.50 0:06.99 + 4 0.0 0:00.56 0:06.99 + 5 0.0 0:00.62 0:06.32 + 176 1000 173 176 176 2 148M 2.19M 0.0 0:00.08 0:00.54 -bash + 0 0.0 0:00.08 0:00.47 + 1 0.0 0:00.00 0:00.07 + 284 1000 1 284 284 2 20.5M 700K 0.0 0:00.00 0:00.00 ssh-agent + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 302 1000 176 302 176 3 148M 1.37M 0.0 0:00.03 0:00.14 screen -S S_main + 0 0.0 0:00.02 0:00.07 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.01 0:00.06 + 304 1000 302 304 304 3 148M 2.45M 0.0 0:02.86 0:13.03 SCREEN -S S_main + 0 0.0 0:02.86 0:12.97 + 1 0.0 0:00.00 0:00.03 + 2 0.0 0:00.00 0:00.02 + 305 1000 3 1 1 5 130M 960K 0.0 0:01.57 0:15.62 /hurd/fifo + 0 0.0 0:00.31 0:04.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.31 0:03.95 + 3 0.0 0:00.45 0:03.78 + 4 0.0 0:00.49 0:03.84 + 306 0 3 1 1 5 130M 1.02M 0.0 0:01.42 0:16.72 /hurd/term /dev/ptyp1 pty-master /dev/ttyp1 + 0 0.0 0:00.43 0:06.13 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.40 0:04.77 + 3 0.0 0:00.00 0:00.14 + 4 0.0 0:00.59 0:05.67 + 309 1000 304 309 309 2 148M 2.12M 0.0 0:00.02 0:00.09 /bin/bash + 0 0.0 0:00.02 0:00.09 + 1 0.0 0:00.00 0:00.00 + 319 1000 309 319 309 2 153M 7.29M 0.0 0:00.33 0:00.74 emacs + 0 0.0 0:00.33 0:00.74 + 1 0.0 0:00.00 0:00.00 + 320 0 3 1 1 6 130M 1.48M 0.0 0:03.25 0:38.79 /hurd/term /dev/ptyp2 pty-master /dev/ttyp2 + 0 0.0 0:00.60 0:07.07 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.69 0:08.43 + 3 0.0 0:00.78 0:07.78 + 4 0.0 0:00.55 0:07.98 + 5 0.0 0:00.60 0:07.52 + 323 1000 304 323 323 2 148M 2.19M 0.0 0:00.12 0:00.60 /bin/bash + 0 0.0 0:00.12 0:00.54 + 1 0.0 0:00.00 0:00.06 + 411 0 3 1 1 5 130M 1.02M 0.0 0:01.17 0:16.40 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:00.42 0:03.74 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.15 0:02.70 + 3 0.0 0:00.24 0:05.48 + 4 0.0 0:00.33 0:04.45 + 414 1000 304 414 414 2 148M 2.13M 0.0 0:00.05 0:00.23 /bin/bash + 0 0.0 0:00.04 0:00.21 + 1 0.0 0:00.00 0:00.02 + 425 0 3 1 1 3 130M 872K 0.0 0:00.02 0:00.05 /hurd/proxy-defpager + 0 0.0 0:00.02 0:00.04 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.01 + 3087 0 3 1 1 5 130M 1.02M 0.0 0:00.23 0:01.39 /hurd/term /dev/ptyp4 pty-master /dev/ttyp4 + 0 0.0 0:00.05 0:00.39 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.07 0:00.43 + 3 0.0 0:00.07 0:00.31 + 4 0.0 0:00.04 0:00.26 + 3648 0 3 1 1 3 130M 876K 0.0 0:00.00 0:00.05 /hurd/crash --kill + 0 0.0 0:00.00 0:00.05 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 5512 0 3 1 1 5 130M 1.01M 0.0 0:00.05 0:00.70 /hurd/term /dev/ptyp5 pty-master /dev/ttyp5 + 0 0.0 0:00.00 0:00.26 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.03 0:00.16 + 3 0.0 0:00.02 0:00.14 + 4 0.0 0:00.00 0:00.14 + 10286 1000 323 10286 323 2 135M 1.28M 0.0 0:00.06 0:00.20 make + 0 0.0 0:00.06 0:00.20 + 1 0.0 0:00.00 0:00.00 + 10287 1000 323 10286 323 2 147M 884K 0.0 0:00.00 0:00.33 tee standard output L_ LC_PAPER=en_US.utf8 LC_ADDRESS=en_US.utf8 SSH_AGENT_PID=284 LC_MONETARY= + [165CM=en_US.utf8 SP_REPLACE_LINKS=n SHELL=/bin/bash TERM=screen SP_STOP_AFTER=build HISTSIZE=10000 SSH_CLIENT=192.168.10.60 55972 22 LC_NUMERIC=en_US.utf8 OLDPWD=/home/tsch + [165CMhwinge SSH_TTY=/dev/ttyp0 USER=tschwinge HISTFILESIZE=10000 LD_LIBRARY_PATH= LC_TELEPHONE=en_US.utf8 SP_COMPAT=n LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01; + [165CM;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=0 + [165CM01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31: + [165CM:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35 + [165CM5:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=0 + [165CM01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm + [165CMm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.an + [165CMnx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*. + [165CM.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36: SSH_AUTH_SOCK=/home/tschwinge/.ssh/auth_sock.grubber.bddebian.com TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal + [165CMl:\^K^J:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\^K^J:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\^K^J:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH + [165CMH:up=\EM:\^K^J:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\^K^J:li#50:co#166:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\^K^J:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E + [165CME[P:DC=\E[%dP:\^K^J:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\^K^J:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\^K^J:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E + [165CME[24m:so=\E[3m:\^K^J:se=\E[23m:mb=\E[5m:md=\E[1m:mr=\E[7m:me=\E[m:ms:\^K^J:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\^K^J:vb=\Eg:G0:as=\E(0:ae=\E(B:\^K^J:ac=\1 + [165CM140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\^K^J:po=\E[5i:pf=\E[4i:k0=\E[10~:k1=\EOP:k2=\EOQ:k3=\EOR:\^K^J:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E + [165CME[18~:k8=\E[19~:\^K^J:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:F3=\E[1;2P:\^K^J:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:F7=\E[15;2~:\^K^J:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:k + [165CMkb=\177:K2=\EOE:\^K^J:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:*7=\E[1;2F:\^K^J:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:%e=\E[5;2~:\^K^J:%i=\E[1;2C:kh=\E[1~:@1=\E[ + [165CM[1~:kH=\E[4~:@7=\E[4~:\^K^J:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:kd=\EOB:\^K^J:kr=\EOC:kl=\EOD:km: have_bash_profile=y SPF_SOURCE_DEBUG=y PATH=/home/tschwinge/c + [165CMcommand:/home/tschwinge/shared/command:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games MAIL=/var/mail/tschwinge LC_MESSAGES=en_US.utf8 SP_TARDIR=/ + [165CM/home/tschwinge/tmp/source/package STY=304.S_main LC_COLLATE=C LC_IDENTIFICATION=en_US.utf8 SP_FOREIGN_DIR=/home/tschwinge/shared.old/package/host/schwinge.homeip.net/ + [165CM/sp-foreign-snippets/snippets PWD=/home/tschwinge/tmp/emacs/trunk.build _LD_LIBRARY_PATH= EDITOR=emacsclient LANG=en_US.utf8 TZ=Europe/Berlin LC_MEASUREMENT=en_US.utf + [165CMf8 KRB5CCNAME=/tmp/krb5cc.tschwinge HISTCONTROL=ignoreboth HOME=/home/tschwinge SHLVL=2 SPF_COMPAT=n LOGNAME=tschwinge LESS=-M -R CVS_RSH=ssh WINDOW=1 SSH_CONNECTION=1 + [165CM192.168.10.60 55972 192.168.10.63 22 LC_CTYPE=en_US.utf8 LESSOPEN=| /usr/bin/lesspipe %s EMAIL=thomas@schwinge.name ALTERNATE_EDITOR=joe LC_TIME=en_US.utf8 LESSCLOSE=/ + [165CM/usr/bin/lesspipe %s %s SPF_SOURCE_DATA_DIR=/home/tschwinge/shared.old/source/package/misc/spf LC_NAME=en_US.utf8 _=/usr/bin/tee + 0 0.0 0:00.00 0:00.33 + 1 0.0 0:00.00 0:00.00 + 10377 1000 10286 10286 323 2 146M 828K 0.0 0:00.00 0:00.00 /bin/sh -c boot=bootstrap-emacs; \^Kif [ ! -x "src/$boot" ]; then + [165CM \^K cd src; make all \^K CC='gcc' CFLAGS='-g' CPPFLAGS='-DXASSERTS=1' \^K LDFLA + [165CMAGS='-Wl,-znocombreloc ' MAKE='make' BOOTSTRAPEMACS="$boot"; \^Kfi; + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 10378 1000 10377 10286 323 2 135M 1.65M 0.0 0:00.71 0:02.12 make all CC=gcc CFLAGS=-g CPPFLAGS=-DXASSERTS=1 LDFLAGS=-Wl,-znocombreloc MAKE=make BOOTSTRAPE + [165CMEMACS=bootstrap-emacs + 0 0.0 0:00.71 0:01.92 + 1 0.0 0:00.00 0:00.19 + 10770 1000 10378 10286 323 2 146M 852K 0.0 0:00.00 0:00.03 /bin/sh -c if test "no" = "yes"; then \^K ln -f temacs bootstrap-emacs; \^Kelse \^K `/bin/pwd + [165CMd`/temacs --batch --load loadup bootstrap || exit 1; \^K mv -f emacs bootstrap-emacs; \^Kfi + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + 10772 1000 10770 10286 323 3 180M 38.8M 0.0 1:16.35 0:05.27 /media/data/home/tschwinge/tmp/emacs/trunk.build/src/temacs --batch --load loadup bootstrap + 0 0.0 1:16.35 0:05.27 + 1 0.0 0:00.00 0:00.00 + 2 0.0 0:00.00 0:00.00 + 10778 1000 304 304 304 2 148M 396K 0.0 0:00.00 0:00.00 SCREEN -S S_main + 0 0.0 0:00.00 0:00.00 + 1 0.0 0:00.00 0:00.00 + 10784 - 160 10784 160 2 146M 672K 0.0 0:00.00 0:00.01 syncfs -s + 0 0.0 0:00.00 0:00.01 + 1 0.0 0:00.00 0:00.00 + 10785 - 160 10785 160 2 146M 672K 0.0 0:00.00 0:00.02 syncfs -s -c /media/data/ + 0 0.0 0:00.00 0:00.02 + 1 0.0 0:00.00 0:00.00 + 10787 0 160 10787 160 2 146M 876K 0.0 0:00.00 0:00.06 ps -Af + 0 0.0 0:00.00 0:00.06 + 1 0.0 0:00.00 0:00.00 + 10795 8 131 6 6 2 147M 1.38M 0.1 0:00.02 0:00.04 /usr/lib/nullmailer/qmqp -d -s mail.schwinge.homeip.net + 0 0.1 0:00.02 0:00.04 + 1 0.0 0:00.00 0:00.00 + 10796 0 160 10796 160 2 146M 1.23M 0.0 0:00.00 0:00.08 ps -F hurd-long -T -M -w -A + 0 0.0 0:00.00 0:00.03 + 1 0.0 0:00.00 0:00.00 + + [4]+ Done ps -F hurd-long -T -M -w -A + login> + +TH# 631 of PID 174 (which is indeed ext2fs for /media/data) looks very +suspicious, likely together in combination with TH# 1 of PID 2 (GNU Mach), so +likely some IPC ping-pong? + + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 0 0 1 1 1 16 132M 1M 0.0 0:04.84 0:54.84 /hurd/proc + [...] + 2 - 1 1 1 7 418M 19.5M 0.0 0:00.00 0:12.16 root=device:hd0 + 0 0.0 0:00.00 0:00.00 + 1 92.6 0:00.00 46:33.66 + 2 0.0 0:00.00 0:12.07 + 3 0.0 0:00.00 0:00.05 + 4 0.0 0:00.00 0:00.02 + 5 0.0 0:00.00 0:00.00 + 6 0.0 0:00.00 0:00.01 + [...] + 174 0 3 1 1 632 2.99G 27.6M 100.3 16:43.18 52:54.41 /hurd/ext2fs /dev/hd2 + 0 0.0 0:00.01 0:00.03 + 1 0.0 0:00.00 0:00.00 + 2 0.0 1:34.24 6:26.66 + 3 0.0 0:00.04 0:00.31 + [...] + 630 0.0 0:00.00 0:00.00 + 631 100.3 8:11.86 17:35.07 + [...] + +Attaching GDB hangs. Should have used noninvasive mode... + +Having a look again after an hour or two, GNU Mach's thread 1's (system) time +count has gone up to nearly 120 minutes, and ext2fs' thread 631's is up to 12 +minutes user and 26 minutes system time. + +I was able to get another root shell via plain `ssh root@grubber`, and I'm able +to attach GDB in noninvasive mode. Hopefully the first unsuccessful (but still +running) GDB didn't cause any interference. + +Due to differences in [[thread_numbering_of_ps_and_gdb]], GDB's thread 632 +(which is the last one anyways) should be the offending one. GDB's thread 631 +and earlier ones (manually checked down to 600) are sitting in `mach_msg_trap`. + + (gdb) thread apply 632 bt + + Thread 632 (Thread 174.632): + #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 + #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 + #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 + #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 + #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 + #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 + #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 + #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 + #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 + #9 0x00000000 in ?? () + + (gdb) thread apply 632 bt full + + Thread 632 (Thread 174.632): + #0 0x010e408c in syscall_vm_allocate () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/syscall_vm_allocate.S:2 + No locals. + #1 0x010e423a in __vm_allocate (target_task=1, address=0xbfffbde0, size=65536, anywhere=0) + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/vm_allocate.c:54 + err = <value optimized out> + #2 0x010b023a in alloc_stack (p=0x83774a8) at /home/sthibaul-guest/hurd-debian/./libthreads/stack.c:397 + base = 321454080 + #3 0x010ae9b3 in cproc_create () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:724 + child = 0x83774a8 + n = <value optimized out> + #4 0x010afe5a in cthread_fork (func=0x133ff42, arg=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:341 + t = 0x8377430 + #5 0x010b505d in internal_demuxer (inp=0xbfffdf20, outheadp=0xbfffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:72 + status = <value optimized out> + pi = 0x0 + link = {thread = 2050, next = 0x0, prevp = 0x2000, notifies = 0x12, interrupted_next = 0x0} + __PRETTY_FUNCTION__ = "internal_demuxer" + lock = -1073758644 + nreqthreads = -1073750240 + totalthreads = 137852072 + bucket = 0x10b1c64 + demuxer = 0x10b01eb <alloc_stack+11> + #6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 + request = 0xbfffdf20 + reply = 0xbfffbf10 + mr = 3 + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805f6c0 + lock = 0 + totalthreads = 497 + nreqthreads = 1 + #8 0x010b0058 in cthread_body (self=0x8376c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 + t = 0x8376bd8 + #9 0x00000000 in ?? () + No symbol table info available. + +May this simply be an out-of-memory situation where Mach won't / can't satisfy +libports / libthreads demand? (Looks like the latter library is currently +creating a new thread.) If yes, should the code be prepared for that? Is it +perhaps prepared (I did not yet have a look), and re-tries again and again? +Why doesn't Mach page out some pages to make memory available? + +This is stock GNU Mach from Git, no patches, configured for Xen domU usage. 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/etc_fstab.mdwn b/open_issues/etc_fstab.mdwn new file mode 100644 index 00000000..eb2a34f9 --- /dev/null +++ b/open_issues/etc_fstab.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2009 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="/etc/fstab"]] + +Even though we don't need a `/etc/fstab` for mounting filesystems +(passive [[hurd/translator]]s to the rescue; they have problems on their +own, see the [[hurd/critique]]), we still need this file for `fsck -a` +and `swapon -a` to function. + +[[!tag open_issue_hurd]] diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn new file mode 100644 index 00000000..47d1560a --- /dev/null +++ b/open_issues/exec.mdwn @@ -0,0 +1,23 @@ +[[!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]]."]]"""]] + +[[!open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang + <youpi> support in exec* I meant + + <youpi> now a funny bug: if I disable gzip/bzip2 support from exec + <youpi> trying to run a zero-byte file hangs + +--- + +May want to have a look at using BFD / libiberty/simpleobject. diff --git a/open_issues/exec_leak.mdwn b/open_issues/exec_leak.mdwn new file mode 100644 index 00000000..b58d2c81 --- /dev/null +++ b/open_issues/exec_leak.mdwn @@ -0,0 +1,57 @@ +[[!meta copyright="Copyright © 2012 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, 2012-08-11 + + <braunr> the exec servers seems to leak a lot + <braunr> server* + <braunr> exec now uses 109M on darnassus + <braunr> it really leaks a lot + <pinotree> only 109mb? few months ago, exec on exodar was taking more than + 200mb after few days of uptime with builds done + <braunr> i wonder how much it takes on the buildds + + +# IRC, freenode, #hurd, 2012-08-17 + + <braunr> the exec leak is tricky + <braunr> bddebian: btw, look at the TODO file in the hurd source code + <braunr> bddebian: there is a not from thomas bushnell about that + <braunr> "*** Handle dead name notifications on execserver ports. ! + <braunr> not sure it's still a todo item, but it might be worth checking + <bddebian> braunr: diskfs_execboot_class = ports_create_class (0, 0); + This is what would need to change right? It should call some cleanup + routine in the first argument? + <bddebian> Would be ideal if it could just use deadboot() from exec. + <braunr> bddebian: possible + <braunr> bddebian: hum execboot, i'm not so sure + <bddebian> Execboot is the exec task, no? + <braunr> i don't know what execboot is + <bddebian> It's from libdiskfs + <braunr> but "diskfs_execboot_class" looks like a class of ports used at + startup only + <braunr> ah + <braunr> then it's something run in the diskfs users ? + <bddebian> yes + <braunr> the leak is in exec + <braunr> if clients misbehave, it shouldn't affect that server + <bddebian> That's a different issue, this was about the TODO thing + <braunr> ah + <braunr> i don't know + <bddebian> Me either :) + <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled + at my results.. + <braunr> ? + <bddebian> Where my counters are zero if I always increment on different + vars but wild freaking numbers if I increment on malloc and decrement on + free diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn new file mode 100644 index 00000000..1a73ce9a --- /dev/null +++ b/open_issues/exec_memory_leaks.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2012 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]] + +There are is some memory leak in [[`exec`|hurd/translator/exec]]. After twelve +hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the testsuite), we got: + + PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 4 0 3 1 1 10 392M 262M 0.0 2:18.29 2hrs /hurd/exec + +The *RSS* seems a tad high. Also the system part of CPU time consumption is +quite noticeable. In comparison: + + 0 0 1 1 1 19 131M 1.14M 0.0 3:30.25 9:17.79 /hurd/proc + 3 0 1 1 1 224 405M 12.6M 0.2 42:20.25 67min ext2fs --readonly --multiboot-command-line=root=device:hd0s6 --host-priv-port=1 --device-master-port=2 --exec-server-task=3 -T typed device:hd0s6 + 276 0 3 1 1 344 442M 28.2M 0.6 48:09.36 91min /hurd/ext2fs /dev/hd2s5 diff --git a/open_issues/ext2fs_deadlock.mdwn b/open_issues/ext2fs_deadlock.mdwn new file mode 100644 index 00000000..23f54a4a --- /dev/null +++ b/open_issues/ext2fs_deadlock.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010, 2012 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]] + +On 2010-10-26, [[I|tschwinge]]'ve been doing the following: `cp -a +../tmpdir/dump*.o ./` (65 files), changed my mind, hit `C-c`, continued with +`cp -a ../tmpdir/dump*.o ./` (to preserve timestamps), wondered why this takes +so long, hit `C-c` again, then found the FS deadlocked (using no CPU; but +`syncfs -s -c` wouldn't finish, for example). Judging from the files' +timestamps (after rebooting and `fsck`), I would assume that it already hung at +the second `cp`'s time, and the deadlock thus is not due to the second `C-c`, +but due to the first one. + + # gdb /hurd/ext2fs + [...] + (gdb) set noninvasive on + (gdb) attach 177 + [...] + [New Thread 177.535] + Reading symbols [...] + (gdb) info threads + [all the same from 177.535 down to...] + 11 Thread 177.11 0x010e3efc in mach_msg_trap () + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 10 Thread 177.10 0x010e3efc in mach_msg_trap () + at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + [doesn't continue with thread 9, but hangs, taking all CPU time] + +New GDB instance, again noninvasive, I'm able to continue. + +Here are backtraces for threads [[1 to 8|bt_1-8]] and [[10 to 535|bt_10-535]], +I didn't succeed to get any information about thread 9 (which thus would +probably be the most interesting one...) -- GDB would always hang when +accessing it, no matter whether noninvasive mode or not. (Didn't have time to +pull the information out of the process' memory manually (how to do that, +anyways?), and also didn't have time to continue with debugging GDB itself, but +this sounds like a [[!taglink open_issue_gdb]]...) + + +# IRC, freenode, #hurd, 2010-10-27 + + <youpi> thread 8 hung on ports_begin_rpc + <youpi> that's probably where one could investigated first + <youpi> yes, a lot of threads are hung on that + <tschwinge> You mean 0x10b9488, right? + <youpi> yes diff --git a/open_issues/ext2fs_deadlock/bt_1-8 b/open_issues/ext2fs_deadlock/bt_1-8 new file mode 100644 index 00000000..f3045fb4 --- /dev/null +++ b/open_issues/ext2fs_deadlock/bt_1-8 @@ -0,0 +1,88 @@ + +Thread 1 (Thread 177.1): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x131fd54, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af2d8 in condition_wait (c=0x10b1e80, m=0x10b1e50) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:783 +#4 0x010afc7f in cthread_exit (result=0x0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:393 +#5 0x0804e9e5 in main (argc=2, argv=0x131fec4) at /home/sthibaul-guest/hurd-debian/./ext2fs/ext2fs.c:204 + +Thread 2 (Thread 177.2): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x132df20, option=3, send_size=40, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x10f5930 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151 +#3 0x010e4efb in __mach_msg_server (demux=0x10f5930 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196 +#4 0x010f58ff in _hurd_msgport_receive () at msgportdemux.c:68 +#5 0x010b0058 in cthread_body (self=0x805ed38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#6 0x00000000 in ?? () + +Thread 3 (Thread 177.3): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x133bd18, option=2, send_size=0, rcv_size=24, rcv_name=22, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x133be70, outheadp=0x133de80) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=1) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b4fc7 in ports_manage_port_operations_multithread (bucket=0x805f6c0, demuxer=0x103d9b0 <diskfs_demuxer>, hook=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:164 +#9 0x0104b256 in master_thread_function (demuxer=0x103d9b0) at /home/sthibaul-guest/hurd-debian/./libdiskfs/init-first.c:37 +#10 0x010b0058 in cthread_body (self=0x805f800) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#11 0x00000000 in ?? () + +Thread 4 (Thread 177.4): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x134de80, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=1) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b4fc7 in ports_manage_port_operations_multithread (bucket=0x805f8f0, demuxer=0x105ad80 <pager_demuxer>, hook=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:164 +#5 0x01041904 in service_paging_requests (arg=0x805f8f0) at /home/sthibaul-guest/hurd-debian/./libdiskfs/disk-pager.c:41 +#6 0x010b0058 in cthread_body (self=0x805f9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#7 0x00000000 in ?? () + +Thread 5 (Thread 177.5): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x135df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8060a40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 6 (Thread 177.6): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x136bbb8, option=2, send_size=0, rcv_size=24, rcv_name=34, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8292d98) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11852, seqno=93, control=4806, offset=0, data=83726336, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11852, seqno=93, control=4806, offset=0, data=83726336, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x136df20, OutHeadP=0x136bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x136df20, outp=0x136bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x136df20, outheadp=0x136bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x80614f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 7 (Thread 177.7): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x137bdb8, option=2, send_size=0, rcv_size=24, rcv_name=38, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x137df20, outheadp=0x137bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8061d88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 8 (Thread 177.8): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x138fe80, option=2, send_size=0, rcv_size=24, rcv_name=44, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4b48 in ports_begin_rpc (portstruct=0x80625a0, msg_id=0, info=0x138ff68) at /home/sthibaul-guest/hurd-debian/./libports/begin-rpc.c:33 +#5 0x01052c15 in periodic_sync (interval=5) at /home/sthibaul-guest/hurd-debian/./libdiskfs/sync-interval.c:100 +#6 0x010b0058 in cthread_body (self=0x8062698) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#7 0x00000000 in ?? () diff --git a/open_issues/ext2fs_deadlock/bt_10-535 b/open_issues/ext2fs_deadlock/bt_10-535 new file mode 100644 index 00000000..79ed145a --- /dev/null +++ b/open_issues/ext2fs_deadlock/bt_10-535 @@ -0,0 +1,5240 @@ + +Thread 10 (Thread 177.10): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13adf20, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 11 (Thread 177.11): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=87, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13bdf20, outheadp=0x13bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x806b578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 12 (Thread 177.12): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8069bf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 13 (Thread 177.13): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806a4e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 14 (Thread 177.14): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 15 (Thread 177.15): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=46, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13fdf20, outheadp=0x13fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8070e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 16 (Thread 177.16): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x140bbb8, option=2, send_size=0, rcv_size=24, rcv_name=165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35c80) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1, initializing=0) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x140df20, OutHeadP=0x140bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x140df20, outp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x140df20, outheadp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8070f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 17 (Thread 177.17): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x141bdb8, option=2, send_size=0, rcv_size=24, rcv_name=159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x141df20, outheadp=0x141bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80731b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 18 (Thread 177.18): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x142bdb8, option=2, send_size=0, rcv_size=24, rcv_name=175, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x142bf10, outheadp=0x142df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8073f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 19 (Thread 177.19): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x143df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8070df8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 20 (Thread 177.20): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x144df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073c60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 21 (Thread 177.21): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x145df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 22 (Thread 177.22): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x146df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073af0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 23 (Thread 177.23): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x147bbb8, option=2, send_size=0, rcv_size=24, rcv_name=187, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260de8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1, initializing=0) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1) + at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x147df20, OutHeadP=0x147bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x147df20, outp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x147df20, outheadp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +Quit + +Thread 10 (Thread 177.10): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13adf20, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 11 (Thread 177.11): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=87, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13bdf20, outheadp=0x13bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x806b578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 12 (Thread 177.12): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8069bf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 13 (Thread 177.13): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x806a4e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 14 (Thread 177.14): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 15 (Thread 177.15): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x13fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=46, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x13fdf20, outheadp=0x13fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8070e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 16 (Thread 177.16): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x140bbb8, option=2, send_size=0, rcv_size=24, rcv_name=165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35c80) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6731, seqno=93, control=11865, offset=0, data=68448256, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x140df20, OutHeadP=0x140bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x140df20, outp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x140df20, outheadp=0x140bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8070f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 17 (Thread 177.17): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x141bdb8, option=2, send_size=0, rcv_size=24, rcv_name=159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x141df20, outheadp=0x141bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80731b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 18 (Thread 177.18): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x142bdb8, option=2, send_size=0, rcv_size=24, rcv_name=175, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x142bf10, outheadp=0x142df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8073f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 19 (Thread 177.19): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x143df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8070df8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 20 (Thread 177.20): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x144df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073c60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 21 (Thread 177.21): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x145df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 22 (Thread 177.22): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x146df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8073af0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 23 (Thread 177.23): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x147bbb8, option=2, send_size=0, rcv_size=24, rcv_name=187, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260de8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11699, seqno=93, control=6878, offset=0, data=85233664, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x147df20, OutHeadP=0x147bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x147df20, outp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x147df20, outheadp=0x147bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8071588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 24 (Thread 177.24): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x148df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80716e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 25 (Thread 177.25): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x149df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071838) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 26 (Thread 177.26): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8071880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 27 (Thread 177.27): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8074d80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 28 (Thread 177.28): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14cbc6c, option=3, send_size=24, rcv_size=32, rcv_name=209, timeout=0, notify=0) at msg.c:110 +#2 0x012d73dc in __thread_suspend (target_thread=66) at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/RPC_thread_suspend.c:85 +#3 0x01100e07 in hurd_thread_cancel (thread=66) at thread-cancel.c:57 +#4 0x010b5b2a in ports_interrupt_rpcs (portstruct=0x8137000) at /home/sthibaul-guest/hurd-debian/./libports/interrupt-rpcs.c:35 +#5 0x010b6434 in ports_S_interrupt_operation (port=11806, seqno=7) at /home/sthibaul-guest/hurd-debian/./libports/interrupt-operation.c:37 +#6 0x010b7a40 in _Xinterrupt_operation (InHeadP=0x14cdf20, OutHeadP=0x14cbf10) at interruptServer.c:74 +#7 0x010b79b4 in ports_interrupt_server (InHeadP=0xd1, OutHeadP=0xffffffe7) at interruptServer.c:113 +#8 0x0103da44 in diskfs_demuxer (inp=0x14cdf20, outp=0x14cbf10) at /home/sthibaul-guest/hurd-debian/./libdiskfs/demuxer.c:38 +#9 0x010b5163 in internal_demuxer (inp=0x14cdf20, outheadp=0x14cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#10 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#11 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#12 0x010b0058 in cthread_body (self=0x8079e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#13 0x00000000 in ?? () + +Thread 29 (Thread 177.29): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=294, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4812, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x14ddf20, outheadp=0x14dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807fee0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 30 (Thread 177.30): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=297, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11858, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x14edf20, outheadp=0x14ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807f960) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 31 (Thread 177.31): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x14fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x807f0a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 32 (Thread 177.32): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x150bdb8, option=2, send_size=0, rcv_size=24, rcv_name=312, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6314, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x150df20, outheadp=0x150bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x807b5d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 33 (Thread 177.33): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x151bdb8, option=2, send_size=0, rcv_size=24, rcv_name=315, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11858, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x151df20, outheadp=0x151bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8079d88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 34 (Thread 177.34): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x152df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8082708) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 35 (Thread 177.35): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x153df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8082f60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 36 (Thread 177.36): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x154bdb8, option=2, send_size=0, rcv_size=24, rcv_name=324, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5360, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x154df20, outheadp=0x154bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80837b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 37 (Thread 177.37): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x155df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8084010) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 38 (Thread 177.38): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x156bdb8, option=2, send_size=0, rcv_size=24, rcv_name=330, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6765, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x156df20, outheadp=0x156bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8084868) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 39 (Thread 177.39): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x157df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80850c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 40 (Thread 177.40): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x158df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8085918) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 41 (Thread 177.41): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x159df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8086170) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 42 (Thread 177.42): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15abdb8, option=2, send_size=0, rcv_size=24, rcv_name=342, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=12846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x15adf20, outheadp=0x15abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80869c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 43 (Thread 177.43): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8087220) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 44 (Thread 177.44): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8087a78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 45 (Thread 177.45): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=351, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11872, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x15ddf20, outheadp=0x15dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80882d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 46 (Thread 177.46): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8088b28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 47 (Thread 177.47): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x15fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8089380) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 48 (Thread 177.48): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x160bdb8, option=2, send_size=0, rcv_size=24, rcv_name=360, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6518, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x160df20, outheadp=0x160bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8089bd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 49 (Thread 177.49): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x161bdb8, option=2, send_size=0, rcv_size=24, rcv_name=363, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5340, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x161df20, outheadp=0x161bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808a430) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 50 (Thread 177.50): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x162bdb8, option=2, send_size=0, rcv_size=24, rcv_name=366, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11840, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x162df20, outheadp=0x162bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808ac88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 51 (Thread 177.51): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x163df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808b4e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 52 (Thread 177.52): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x164df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808bd38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 53 (Thread 177.53): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x165df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808c590) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 54 (Thread 177.54): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x166df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808cde8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 55 (Thread 177.55): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x167bdb8, option=2, send_size=0, rcv_size=24, rcv_name=381, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4864, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x167df20, outheadp=0x167bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808d640) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 56 (Thread 177.56): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x168df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808de98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 57 (Thread 177.57): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x169df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808e6f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 58 (Thread 177.58): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x808ef48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 59 (Thread 177.59): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=393, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5339, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16bdf20, outheadp=0x16bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808f7a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 60 (Thread 177.60): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=396, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6731, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16cdf20, outheadp=0x16cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x808fff8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 61 (Thread 177.61): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=399, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4785, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16ddf20, outheadp=0x16dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8090850) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 62 (Thread 177.62): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=402, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11824, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16edf20, outheadp=0x16ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80910a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 63 (Thread 177.63): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x16fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=405, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11863, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x16fdf20, outheadp=0x16fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8091900) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 64 (Thread 177.64): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x170df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8092158) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 65 (Thread 177.65): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x171df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80929b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 66 (Thread 177.66): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x172bdb8, option=2, send_size=0, rcv_size=24, rcv_name=414, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11855, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x172df20, outheadp=0x172bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8093208) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 67 (Thread 177.67): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x173bdb8, option=2, send_size=0, rcv_size=24, rcv_name=417, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6308, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x173df20, outheadp=0x173bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8093a60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 68 (Thread 177.68): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x174bdb8, option=2, send_size=0, rcv_size=24, rcv_name=420, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4830, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x174df20, outheadp=0x174bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80942b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 69 (Thread 177.69): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x175bdb8, option=2, send_size=0, rcv_size=24, rcv_name=423, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11875, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x175df20, outheadp=0x175bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8094b10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 70 (Thread 177.70): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x176bdb8, option=2, send_size=0, rcv_size=24, rcv_name=426, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6876, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x176df20, outheadp=0x176bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8095368) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 71 (Thread 177.71): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x177bdb8, option=2, send_size=0, rcv_size=24, rcv_name=429, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5321, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x177df20, outheadp=0x177bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8095bc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 72 (Thread 177.72): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x178df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8096418) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 73 (Thread 177.73): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x179df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8096c70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 74 (Thread 177.74): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80974c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 75 (Thread 177.75): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8097d20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 76 (Thread 177.76): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8098578) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 77 (Thread 177.77): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8098dd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 78 (Thread 177.78): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=450, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4859, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x17edf20, outheadp=0x17ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8099628) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 79 (Thread 177.79): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x17fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8099e80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 80 (Thread 177.80): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x180bdb8, option=2, send_size=0, rcv_size=24, rcv_name=456, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6876, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x180df20, outheadp=0x180bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809a6d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 81 (Thread 177.81): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x181df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809af30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 82 (Thread 177.82): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x182df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809b788) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 83 (Thread 177.83): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x183df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809bfe0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 84 (Thread 177.84): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x184df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809c838) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 85 (Thread 177.85): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x185bdb8, option=2, send_size=0, rcv_size=24, rcv_name=471, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4834, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x185df20, outheadp=0x185bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809d090) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 86 (Thread 177.86): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x186bdb8, option=2, send_size=0, rcv_size=24, rcv_name=474, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4845, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x186df20, outheadp=0x186bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809d8e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 87 (Thread 177.87): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x187bbb8, option=2, send_size=0, rcv_size=24, rcv_name=477, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a450d8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11860, seqno=93, control=11864, offset=0, data=82976768, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11860, seqno=93, control=11864, offset=0, data=82976768, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x187df20, OutHeadP=0x187bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x187df20, outp=0x187bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x187df20, outheadp=0x187bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x809e140) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 88 (Thread 177.88): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x188bdb8, option=2, send_size=0, rcv_size=24, rcv_name=480, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6778, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x188df20, outheadp=0x188bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809e998) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 89 (Thread 177.89): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x189df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x809f1f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 90 (Thread 177.90): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18abdb8, option=2, send_size=0, rcv_size=24, rcv_name=486, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4959, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x18adf20, outheadp=0x18abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x809fa48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 91 (Thread 177.91): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a02a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 92 (Thread 177.92): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18cbc48, option=2, send_size=0, rcv_size=24, rcv_name=492, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473816, control=28, offset=2453504, data=14823424, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473816, control=28, offset=2453504, data=14823424, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x18cdf20, OutHeadP=0x18cbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x18cdf20, outp=0x18cbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x18cdf20, outheadp=0x18cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x80a0af8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 93 (Thread 177.93): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a1350) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 94 (Thread 177.94): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a1ba8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 95 (Thread 177.95): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x18fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a2400) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 96 (Thread 177.96): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x190bdb8, option=2, send_size=0, rcv_size=24, rcv_name=504, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4851, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x190df20, outheadp=0x190bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a2c58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 97 (Thread 177.97): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x191df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a34b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 98 (Thread 177.98): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x192df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a3d08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 99 (Thread 177.99): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x193df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a4560) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 100 (Thread 177.100): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x194bdb8, option=2, send_size=0, rcv_size=24, rcv_name=516, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11837, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x194df20, outheadp=0x194bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a4db8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 101 (Thread 177.101): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x195df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a5610) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 102 (Thread 177.102): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x196df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a5e68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 103 (Thread 177.103): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x197df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a66c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 104 (Thread 177.104): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x198df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a6f18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 105 (Thread 177.105): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x199bdb8, option=2, send_size=0, rcv_size=24, rcv_name=531, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5402, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x199df20, outheadp=0x199bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a7770) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 106 (Thread 177.106): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19abdb8, option=2, send_size=0, rcv_size=24, rcv_name=534, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11872, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x19adf20, outheadp=0x19abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80a7fc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 107 (Thread 177.107): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a8820) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 108 (Thread 177.108): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a9078) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 109 (Thread 177.109): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80a98d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 110 (Thread 177.110): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80aa128) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 111 (Thread 177.111): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x19fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8075b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 112 (Thread 177.112): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ab848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 113 (Thread 177.113): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ae9a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 114 (Thread 177.114): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ac0f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 115 (Thread 177.115): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x807f030) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 116 (Thread 177.116): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b2ae0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 117 (Thread 177.117): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b2b28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 118 (Thread 177.118): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b5e78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 119 (Thread 177.119): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b66d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 120 (Thread 177.120): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b6f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 121 (Thread 177.121): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1a9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b7780) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 122 (Thread 177.122): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1aabdb8, option=2, send_size=0, rcv_size=24, rcv_name=692, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5327, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1aadf20, outheadp=0x1aabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b7fd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 123 (Thread 177.123): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1abbdb8, option=2, send_size=0, rcv_size=24, rcv_name=695, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1abdf20, outheadp=0x1abbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b8830) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 124 (Thread 177.124): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1acbdb8, option=2, send_size=0, rcv_size=24, rcv_name=698, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5595, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1acdf20, outheadp=0x1acbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80b9088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 125 (Thread 177.125): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1addf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80b98e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 126 (Thread 177.126): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1aebdb8, option=2, send_size=0, rcv_size=24, rcv_name=704, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6972, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1aedf20, outheadp=0x1aebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80ba138) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 127 (Thread 177.127): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1afdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80ba990) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 128 (Thread 177.128): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=710, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11847, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1b0df20, outheadp=0x1b0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80bb1e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 129 (Thread 177.129): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bba40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 130 (Thread 177.130): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bc298) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 131 (Thread 177.131): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bcaf0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 132 (Thread 177.132): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bd348) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 133 (Thread 177.133): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bdba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 134 (Thread 177.134): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80be3f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 135 (Thread 177.135): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bec50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 136 (Thread 177.136): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b8bdb8, option=2, send_size=0, rcv_size=24, rcv_name=734, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4785, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1b8df20, outheadp=0x1b8bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80bf4a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 137 (Thread 177.137): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1b9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80bfd00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 138 (Thread 177.138): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1badf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c0558) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 139 (Thread 177.139): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=743, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=13223, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1bbdf20, outheadp=0x1bbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80c0db0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 140 (Thread 177.140): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bcdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c1608) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 141 (Thread 177.141): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c1e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 142 (Thread 177.142): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80c26b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 143 (Thread 177.143): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1bfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81198b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 144 (Thread 177.144): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81196f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 145 (Thread 177.145): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8119848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 146 (Thread 177.146): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8117318) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 147 (Thread 177.147): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8115880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 148 (Thread 177.148): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11826, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1c4df20, outheadp=0x1c4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81199c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 149 (Thread 177.149): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8115600) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 150 (Thread 177.150): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8118b18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 151 (Thread 177.151): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2168, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6298, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1c7df20, outheadp=0x1c7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81197b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 152 (Thread 177.152): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8119ba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 153 (Thread 177.153): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1c9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x811d050) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 154 (Thread 177.154): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2177, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6298, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cadf20, outheadp=0x1cabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811d8a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 155 (Thread 177.155): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2180, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5340, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cbdf20, outheadp=0x1cbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811e100) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 156 (Thread 177.156): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ccbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2183, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4830, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ccdf20, outheadp=0x1ccbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811e958) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 157 (Thread 177.157): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cdbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2186, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5321, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1cddf20, outheadp=0x1cdbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x811f1b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 158 (Thread 177.158): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x811fa08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 159 (Thread 177.159): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1cfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8120260) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 160 (Thread 177.160): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8120ab8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 161 (Thread 177.161): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d1bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2198, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d1df20, outheadp=0x1d1bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8121310) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 162 (Thread 177.162): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8121b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 163 (Thread 177.163): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2204, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5883, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d3df20, outheadp=0x1d3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81223c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 164 (Thread 177.164): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2207, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1d4df20, outheadp=0x1d4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8122c18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 165 (Thread 177.165): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8123470) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 166 (Thread 177.166): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8123cc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 167 (Thread 177.167): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d7bbb8, option=2, send_size=0, rcv_size=24, rcv_name=2216, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8133588) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6841, seqno=93, control=11809, offset=0, data=66523136, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6841, seqno=93, control=11809, offset=0, data=66523136, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1d7df20, OutHeadP=0x1d7bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1d7df20, outp=0x1d7bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1d7df20, outheadp=0x1d7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8124520) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 168 (Thread 177.168): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8124d78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 169 (Thread 177.169): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1d9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81255d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 170 (Thread 177.170): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2225, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11849, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dadf20, outheadp=0x1dabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8125e28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 171 (Thread 177.171): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8126680) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 172 (Thread 177.172): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dcbc48, option=2, send_size=0, rcv_size=24, rcv_name=2231, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473817, control=28, offset=4096, data=14979072, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473817, control=28, offset=4096, data=14979072, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1dcdf20, OutHeadP=0x1dcbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1dcdf20, outp=0x1dcbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1dcdf20, outheadp=0x1dcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8126ed8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 173 (Thread 177.173): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8127730) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 174 (Thread 177.174): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1debdb8, option=2, send_size=0, rcv_size=24, rcv_name=2237, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11878, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dedf20, outheadp=0x1debf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8127f88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 175 (Thread 177.175): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1dfbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2240, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11869, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1dfdf20, outheadp=0x1dfbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81287e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 176 (Thread 177.176): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8129038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 177 (Thread 177.177): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8129890) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 178 (Thread 177.178): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e2bbd8, option=2, send_size=0, rcv_size=24, rcv_name=2249, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82c8510) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11826, seqno=66, control=4763, offset=32768, data=66375680, length=98304, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11826, seqno=66, control=4763, offset=32768, data=66375680, length=98304, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1e2df20, OutHeadP=0x1e2bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x17, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1e2df20, outp=0x1e2bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1e2df20, outheadp=0x1e2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x812a0e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 179 (Thread 177.179): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x812a940) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 180 (Thread 177.180): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159660) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 181 (Thread 177.181): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814c4c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 182 (Thread 177.182): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8137e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 183 (Thread 177.183): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x813f2a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 184 (Thread 177.184): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8154568) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 185 (Thread 177.185): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1e9bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2967, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11843, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1e9df20, outheadp=0x1e9bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8151aa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 186 (Thread 177.186): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1eabdb8, option=2, send_size=0, rcv_size=24, rcv_name=2970, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11816, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1eadf20, outheadp=0x1eabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814aaa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 187 (Thread 177.187): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ebbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2973, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11855, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ebdf20, outheadp=0x1ebbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80f1e70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 188 (Thread 177.188): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ecbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2976, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4939, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1ecdf20, outheadp=0x1ecbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814ee10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 189 (Thread 177.189): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1edbdb8, option=2, send_size=0, rcv_size=24, rcv_name=2979, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6526, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1eddf20, outheadp=0x1edbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8135588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 190 (Thread 177.190): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1eedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8140a08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 191 (Thread 177.191): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1efdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f27e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 192 (Thread 177.192): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x813db08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 193 (Thread 177.193): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f1bbb8, option=2, send_size=0, rcv_size=24, rcv_name=2991, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8306a00) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4845, seqno=93, control=5059, offset=0, data=82788352, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4845, seqno=93, control=5059, offset=0, data=82788352, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x1f1df20, OutHeadP=0x1f1bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x1f1df20, outp=0x1f1bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x1f1df20, outheadp=0x1f1bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81555c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 194 (Thread 177.194): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f2bdb8, option=2, send_size=0, rcv_size=24, rcv_name=2994, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6765, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f2df20, outheadp=0x1f2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x80c99e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 195 (Thread 177.195): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 196 (Thread 177.196): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3000, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11881, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f4df20, outheadp=0x1f4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81548f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 197 (Thread 177.197): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3003, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11805, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f5df20, outheadp=0x1f5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8153f98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 198 (Thread 177.198): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814ffd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 199 (Thread 177.199): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3009, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5144, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f7df20, outheadp=0x1f7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8151548) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 200 (Thread 177.200): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f8bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3012, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6308, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x1f8df20, outheadp=0x1f8bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8137480) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 201 (Thread 177.201): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1f9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81450d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 202 (Thread 177.202): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fadf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f2fc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 203 (Thread 177.203): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81565c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 204 (Thread 177.204): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fcdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8153f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 205 (Thread 177.205): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x814b820) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 206 (Thread 177.206): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1fedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8145130) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 207 (Thread 177.207): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x1ffdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81133e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 208 (Thread 177.208): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x200df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8159170) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 209 (Thread 177.209): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x201df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8153628) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 210 (Thread 177.210): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x202df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8133f08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 211 (Thread 177.211): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x203bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3045, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11831, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x203df20, outheadp=0x203bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x814f088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 212 (Thread 177.212): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x204df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8151d20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 213 (Thread 177.213): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x205bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3051, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4782, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x205df20, outheadp=0x205bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8154e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 214 (Thread 177.214): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x206bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3054, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a1d690) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4830, seqno=93, control=11851, offset=0, data=84103168, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4830, seqno=93, control=11851, offset=0, data=84103168, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x206df20, OutHeadP=0x206bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x206df20, outp=0x206bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x206df20, outheadp=0x206bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81595f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 215 (Thread 177.215): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x207bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3057, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11866, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x207df20, outheadp=0x207bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8138498) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 216 (Thread 177.216): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x208df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x80f1bd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 217 (Thread 177.217): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x209df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816a648) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 218 (Thread 177.218): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816aea0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 219 (Thread 177.219): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3069, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4834, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x20bdf20, outheadp=0x20bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x816b6f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 220 (Thread 177.220): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816bf50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 221 (Thread 177.221): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816c7a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 222 (Thread 177.222): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20ebc48, option=2, send_size=0, rcv_size=24, rcv_name=3078, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473819, control=28, offset=0, data=15933440, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473819, control=28, offset=0, data=15933440, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x20edf20, OutHeadP=0x20ebf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x20edf20, outp=0x20ebf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x20edf20, outheadp=0x20ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x816d000) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 223 (Thread 177.223): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x20fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816d858) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 224 (Thread 177.224): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x210df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816e0b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 225 (Thread 177.225): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x211bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3087, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4853, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x211df20, outheadp=0x211bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x816e908) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 226 (Thread 177.226): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x212df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816f160) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 227 (Thread 177.227): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x213df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x816f9b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 228 (Thread 177.228): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x214bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3096, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6841, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x214df20, outheadp=0x214bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8170210) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 229 (Thread 177.229): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x215bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3099, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6203, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x215df20, outheadp=0x215bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8170a68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 230 (Thread 177.230): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x216bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3102, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6314, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x216df20, outheadp=0x216bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81712c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 231 (Thread 177.231): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x217df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8171b18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 232 (Thread 177.232): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x218bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3108, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5402, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x218df20, outheadp=0x218bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8172370) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 233 (Thread 177.233): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x219df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8172bc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 234 (Thread 177.234): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3114, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5354, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21adf20, outheadp=0x21abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8173420) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 235 (Thread 177.235): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3117, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4787, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21bdf20, outheadp=0x21bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8173c78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 236 (Thread 177.236): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3120, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21cdf20, outheadp=0x21cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81744d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 237 (Thread 177.237): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8174d28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 238 (Thread 177.238): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8175580) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 239 (Thread 177.239): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x21fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3129, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11837, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x21fdf20, outheadp=0x21fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8175dd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 240 (Thread 177.240): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x220bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3132, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=12846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x220df20, outheadp=0x220bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8176630) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 241 (Thread 177.241): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x221df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8176e88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 242 (Thread 177.242): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x222df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81776e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 243 (Thread 177.243): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x223df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8177f38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 244 (Thread 177.244): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x224bc48, option=2, send_size=0, rcv_size=24, rcv_name=3144, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473818, control=28, offset=2125824, data=15642624, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473818, control=28, offset=2125824, data=15642624, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x224df20, OutHeadP=0x224bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x224df20, outp=0x224bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x224df20, outheadp=0x224bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8178790) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 245 (Thread 177.245): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x225bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3147, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4782, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x225df20, outheadp=0x225bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8178fe8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 246 (Thread 177.246): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x226df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8179840) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 247 (Thread 177.247): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x227df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817a098) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 248 (Thread 177.248): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x228df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817a8f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 249 (Thread 177.249): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x229bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3159, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11805, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x229df20, outheadp=0x229bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817b148) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 250 (Thread 177.250): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3162, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11831, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x22adf20, outheadp=0x22abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817b9a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 251 (Thread 177.251): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817c1f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 252 (Thread 177.252): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817ca50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 253 (Thread 177.253): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817d2a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 254 (Thread 177.254): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3174, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11875, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x22edf20, outheadp=0x22ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x817db00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 255 (Thread 177.255): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x22fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817e358) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 256 (Thread 177.256): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x230df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817ebb0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 257 (Thread 177.257): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x231df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817f408) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 258 (Thread 177.258): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x232df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x817fc60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 259 (Thread 177.259): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x233bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3189, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5963, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x233df20, outheadp=0x233bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81804b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 260 (Thread 177.260): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x234df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8180d10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 261 (Thread 177.261): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x235df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8181568) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 262 (Thread 177.262): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x236df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8181dc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 263 (Thread 177.263): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x237df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8182618) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 264 (Thread 177.264): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x238df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8182e70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 265 (Thread 177.265): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x239bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3207, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4859, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x239df20, outheadp=0x239bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81836c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 266 (Thread 177.266): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8183f20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 267 (Thread 177.267): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8184778) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 268 (Thread 177.268): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8184fd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 269 (Thread 177.269): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8185828) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 270 (Thread 177.270): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8186080) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 271 (Thread 177.271): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x23fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81868d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 272 (Thread 177.272): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x240df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8187130) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 273 (Thread 177.273): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x241bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3231, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4814, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x241df20, outheadp=0x241bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8187988) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 274 (Thread 177.274): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x242df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81881e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 275 (Thread 177.275): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x243df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8188a38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 276 (Thread 177.276): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x244df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8189290) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 277 (Thread 177.277): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x245bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3243, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11843, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x245df20, outheadp=0x245bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8189ae8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 278 (Thread 177.278): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x246bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3246, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6517, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x246df20, outheadp=0x246bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818a340) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 279 (Thread 177.279): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x247df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ab98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 280 (Thread 177.280): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x248df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818b3f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 281 (Thread 177.281): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x249bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3255, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5315, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x249df20, outheadp=0x249bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818bc48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 282 (Thread 177.282): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818c4a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 283 (Thread 177.283): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ccf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 284 (Thread 177.284): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818d550) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 285 (Thread 177.285): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818dda8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 286 (Thread 177.286): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818e600) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 287 (Thread 177.287): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x24fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3273, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x24fdf20, outheadp=0x24fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x818ee58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 288 (Thread 177.288): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x250df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818f6b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 289 (Thread 177.289): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x251df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x818ff08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 290 (Thread 177.290): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x252df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8190760) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 291 (Thread 177.291): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x253df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8190fb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 292 (Thread 177.292): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x254bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3288, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11852, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x254df20, outheadp=0x254bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8191810) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 293 (Thread 177.293): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x255df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8192068) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 294 (Thread 177.294): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x256bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3294, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5144, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x256df20, outheadp=0x256bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81928c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 295 (Thread 177.295): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x257df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8193118) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 296 (Thread 177.296): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x258df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8193970) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 297 (Thread 177.297): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x259df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81941c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 298 (Thread 177.298): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8194a20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 299 (Thread 177.299): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8195278) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 300 (Thread 177.300): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3312, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5339, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25cdf20, outheadp=0x25cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8195ad0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 301 (Thread 177.301): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3315, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=13223, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25ddf20, outheadp=0x25dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8196328) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 302 (Thread 177.302): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8196b80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 303 (Thread 177.303): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x25fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3321, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6517, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x25fdf20, outheadp=0x25fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81973d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 304 (Thread 177.304): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x260df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8197c30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 305 (Thread 177.305): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x261bcc8, option=2, send_size=0, rcv_size=24, rcv_name=3327, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82c8510) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059a84 in _pager_seqnos_memory_object_data_unlock (object=11826, seqno=68, control=4763, offset=131072, length=4096, access=2) at /home/sthibaul-guest/hurd-debian/./libpager/data-unlock.c:87 +#6 0x0105c1b4 in _Xmemory_object_data_unlock (InHeadP=0x261df20, OutHeadP=0x261bf10) at memory_objectServer.c:467 +#7 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x20000, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#8 0x0105adac in pager_demuxer (inp=0x261df20, outp=0x261bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#9 0x010b5163 in internal_demuxer (inp=0x261df20, outheadp=0x261bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#10 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#11 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#12 0x010b0058 in cthread_body (self=0x8198488) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#13 0x00000000 in ?? () + +Thread 306 (Thread 177.306): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x262bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3330, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11829, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x262df20, outheadp=0x262bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8198ce0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 307 (Thread 177.307): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x263df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8199538) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 308 (Thread 177.308): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x264bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3336, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11846, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x264df20, outheadp=0x264bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8199d90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 309 (Thread 177.309): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x265bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3339, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4797, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x265df20, outheadp=0x265bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x819a5e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 310 (Thread 177.310): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x266bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3342, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5883, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x266df20, outheadp=0x266bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x819ae40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 311 (Thread 177.311): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x267df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819b698) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 312 (Thread 177.312): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x268df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819bef0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 313 (Thread 177.313): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x269df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819c748) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 314 (Thread 177.314): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819cfa0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 315 (Thread 177.315): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819d7f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 316 (Thread 177.316): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819e050) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 317 (Thread 177.317): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819e8a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 318 (Thread 177.318): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819f100) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 319 (Thread 177.319): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x26fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x819f958) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 320 (Thread 177.320): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x270bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3372, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11822, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x270df20, outheadp=0x270bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a01b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 321 (Thread 177.321): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x271df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a0a08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 322 (Thread 177.322): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x272df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a1260) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 323 (Thread 177.323): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x273df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a1ab8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 324 (Thread 177.324): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x274bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3384, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11818, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x274df20, outheadp=0x274bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a2310) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 325 (Thread 177.325): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x275bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3387, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11818, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x275df20, outheadp=0x275bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a2b68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 326 (Thread 177.326): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x276df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a33c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 327 (Thread 177.327): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x277df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a3c18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 328 (Thread 177.328): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x278df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a4470) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 329 (Thread 177.329): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x279bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3399, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11856, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x279df20, outheadp=0x279bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a4cc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 330 (Thread 177.330): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a5520) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 331 (Thread 177.331): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3405, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5049, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27bdf20, outheadp=0x27bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a5d78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 332 (Thread 177.332): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a65d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 333 (Thread 177.333): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27dbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3411, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5127, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27ddf20, outheadp=0x27dbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a6e28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 334 (Thread 177.334): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3414, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6203, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x27edf20, outheadp=0x27ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a7680) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 335 (Thread 177.335): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x27fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a7ed8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 336 (Thread 177.336): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x280bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3420, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11878, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x280df20, outheadp=0x280bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81a8730) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 337 (Thread 177.337): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x281df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81a8f88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 338 (Thread 177.338): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x282bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3426, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3aa2370) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=10039, seqno=93, control=9839, offset=0, data=85422080, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=10039, seqno=93, control=9839, offset=0, data=85422080, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x282df20, OutHeadP=0x282bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x282df20, outp=0x282bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x282df20, outheadp=0x282bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81a97e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 339 (Thread 177.339): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x283df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aa038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 340 (Thread 177.340): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x284df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aa890) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 341 (Thread 177.341): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x285bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3435, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5963, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x285df20, outheadp=0x285bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ab0e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 342 (Thread 177.342): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x286df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ab940) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 343 (Thread 177.343): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x287df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ac198) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 344 (Thread 177.344): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x288df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ac9f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 345 (Thread 177.345): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x289bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3447, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x289df20, outheadp=0x289bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ad248) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 346 (Thread 177.346): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81adaa0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 347 (Thread 177.347): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ae2f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 348 (Thread 177.348): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81aeb50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 349 (Thread 177.349): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81af3a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 350 (Thread 177.350): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81afc00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 351 (Thread 177.351): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x28fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b0458) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 352 (Thread 177.352): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x290df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b0cb0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 353 (Thread 177.353): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x291df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b1508) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 354 (Thread 177.354): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x292df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b1d60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 355 (Thread 177.355): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x293df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b25b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 356 (Thread 177.356): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x294bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3480, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a35f50) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4864, seqno=93, control=11880, offset=0, data=81281024, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4864, seqno=93, control=11880, offset=0, data=81281024, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x294df20, OutHeadP=0x294bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x294df20, outp=0x294bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x294df20, outheadp=0x294bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81b2e10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 357 (Thread 177.357): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x295df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b3668) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 358 (Thread 177.358): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x296df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b3ec0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 359 (Thread 177.359): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x297df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b4718) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 360 (Thread 177.360): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x298bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3492, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82156d0) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11818, seqno=93, control=11814, offset=0, data=84856832, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11818, seqno=93, control=11814, offset=0, data=84856832, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x298df20, OutHeadP=0x298bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x298df20, outp=0x298bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x298df20, outheadp=0x298bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81b4f70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 361 (Thread 177.361): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x299bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3495, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11888, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x299df20, outheadp=0x299bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81b57c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 362 (Thread 177.362): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b6020) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 363 (Thread 177.363): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b6878) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 364 (Thread 177.364): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b70d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 365 (Thread 177.365): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b7928) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 366 (Thread 177.366): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b8180) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 367 (Thread 177.367): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x29fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b89d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 368 (Thread 177.368): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b9230) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 369 (Thread 177.369): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81b9a88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 370 (Thread 177.370): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a2bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3522, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11829, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a2df20, outheadp=0x2a2bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ba2e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 371 (Thread 177.371): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3525, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11856, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a3df20, outheadp=0x2a3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bab38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 372 (Thread 177.372): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bb390) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 373 (Thread 177.373): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3531, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4873, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a5df20, outheadp=0x2a5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bbbe8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 374 (Thread 177.374): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a6bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3534, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2a6df20, outheadp=0x2a6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bc440) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 375 (Thread 177.375): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bcc98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 376 (Thread 177.376): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bd4f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 377 (Thread 177.377): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2a9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bdd48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 378 (Thread 177.378): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2aadf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81be5a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 379 (Thread 177.379): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2abdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bedf8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 380 (Thread 177.380): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2acbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3552, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11819, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2acdf20, outheadp=0x2acbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81bf650) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 381 (Thread 177.381): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2addf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81bfea8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 382 (Thread 177.382): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2aedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c0700) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 383 (Thread 177.383): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2afbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3561, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4845, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2afdf20, outheadp=0x2afbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c0f58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 384 (Thread 177.384): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3564, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6972, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b0df20, outheadp=0x2b0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c17b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 385 (Thread 177.385): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c2008) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 386 (Thread 177.386): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c2860) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 387 (Thread 177.387): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3573, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4959, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b3df20, outheadp=0x2b3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c30b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 388 (Thread 177.388): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c3910) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 389 (Thread 177.389): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b5bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3579, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x3a1d730) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11847, seqno=93, control=6869, offset=0, data=84291584, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11847, seqno=93, control=6869, offset=0, data=84291584, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2b5df20, OutHeadP=0x2b5bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2b5df20, outp=0x2b5bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2b5df20, outheadp=0x2b5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81c4168) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 390 (Thread 177.390): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c49c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 391 (Thread 177.391): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3585, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11819, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b7df20, outheadp=0x2b7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c5218) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 392 (Thread 177.392): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c5a70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 393 (Thread 177.393): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2b9bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3591, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11866, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2b9df20, outheadp=0x2b9bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c62c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 394 (Thread 177.394): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2badf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c6b20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 395 (Thread 177.395): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c7378) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 396 (Thread 177.396): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3600, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11869, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2bcdf20, outheadp=0x2bcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81c7bd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 397 (Thread 177.397): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c8428) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 398 (Thread 177.398): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c8c80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 399 (Thread 177.399): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2bfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c94d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 400 (Thread 177.400): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81c9d30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 401 (Thread 177.401): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ca588) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 402 (Thread 177.402): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cade0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 403 (Thread 177.403): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c3bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3621, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4862, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c3df20, outheadp=0x2c3bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cb638) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 404 (Thread 177.404): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cbe90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 405 (Thread 177.405): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3627, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5360, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c5df20, outheadp=0x2c5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cc6e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 406 (Thread 177.406): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c6bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3630, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82b1050) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11824, seqno=93, control=5619, offset=0, data=84668416, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11824, seqno=93, control=5619, offset=0, data=84668416, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2c6df20, OutHeadP=0x2c6bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2c6df20, outp=0x2c6bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2c6df20, outheadp=0x2c6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81ccf40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 407 (Thread 177.407): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c7bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3633, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5288, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2c7df20, outheadp=0x2c7bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cd798) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 408 (Thread 177.408): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81cdff0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 409 (Thread 177.409): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2c9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ce848) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 410 (Thread 177.410): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3642, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4812, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cadf20, outheadp=0x2cabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cf0a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 411 (Thread 177.411): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3645, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5595, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cbdf20, outheadp=0x2cbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81cf8f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 412 (Thread 177.412): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ccbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3648, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8318a20) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6778, seqno=93, control=4919, offset=0, data=67067904, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6778, seqno=93, control=4919, offset=0, data=67067904, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2ccdf20, OutHeadP=0x2ccbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2ccdf20, outp=0x2ccbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2ccdf20, outheadp=0x2ccbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81d0150) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 413 (Thread 177.413): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d09a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 414 (Thread 177.414): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d1200) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 415 (Thread 177.415): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2cfbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3657, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4939, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2cfdf20, outheadp=0x2cfbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d1a58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 416 (Thread 177.416): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d22b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 417 (Thread 177.417): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d2b08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 418 (Thread 177.418): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d3360) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 419 (Thread 177.419): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d3bb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 420 (Thread 177.420): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d4bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3672, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5354, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2d4df20, outheadp=0x2d4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d4410) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 421 (Thread 177.421): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d4c68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 422 (Thread 177.422): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d54c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 423 (Thread 177.423): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d5d18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 424 (Thread 177.424): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d6570) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 425 (Thread 177.425): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2d9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d6dc8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 426 (Thread 177.426): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3690, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5288, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2dadf20, outheadp=0x2dabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d7620) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 427 (Thread 177.427): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d7e78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 428 (Thread 177.428): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3696, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5127, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2dcdf20, outheadp=0x2dcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81d86d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 429 (Thread 177.429): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d8f28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 430 (Thread 177.430): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d9780) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 431 (Thread 177.431): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2dfdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81d9fd8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 432 (Thread 177.432): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e0bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3708, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4797, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2e0df20, outheadp=0x2e0bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81da830) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 433 (Thread 177.433): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81db088) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 434 (Thread 177.434): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81db8e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 435 (Thread 177.435): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81dc138) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 436 (Thread 177.436): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e4bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3720, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x835c670) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11829, seqno=93, control=11823, offset=0, data=84480000, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11829, seqno=93, control=11823, offset=0, data=84480000, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2e4df20, OutHeadP=0x2e4bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2e4df20, outp=0x2e4bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2e4df20, outheadp=0x2e4bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81dc990) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 437 (Thread 177.437): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e5df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81dd1e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 438 (Thread 177.438): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e6bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3726, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4814, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2e6df20, outheadp=0x2e6bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81dda40) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 439 (Thread 177.439): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81de298) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 440 (Thread 177.440): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81deaf0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 441 (Thread 177.441): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2e9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81df348) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 442 (Thread 177.442): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2eabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3738, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6526, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2eadf20, outheadp=0x2eabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81dfba0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 443 (Thread 177.443): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ebdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e03f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 444 (Thread 177.444): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ecdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e0c50) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 445 (Thread 177.445): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2edbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3747, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6518, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2eddf20, outheadp=0x2edbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e14a8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 446 (Thread 177.446): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2eedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e1d00) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 447 (Thread 177.447): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2efdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e2558) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 448 (Thread 177.448): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f0df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e2db0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 449 (Thread 177.449): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f1df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e3608) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 450 (Thread 177.450): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f2df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e3e60) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 451 (Thread 177.451): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f3df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e46b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 452 (Thread 177.452): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f4df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e4f10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 453 (Thread 177.453): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f5bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3771, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5327, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2f5df20, outheadp=0x2f5bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e5768) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 454 (Thread 177.454): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f6df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e5fc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 455 (Thread 177.455): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f7df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e6818) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 456 (Thread 177.456): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f8df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e7070) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 457 (Thread 177.457): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2f9df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e78c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 458 (Thread 177.458): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fabdb8, option=2, send_size=0, rcv_size=24, rcv_name=3786, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11824, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2fadf20, outheadp=0x2fabf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e8120) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 459 (Thread 177.459): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fbdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81e8978) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 460 (Thread 177.460): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3792, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5315, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x2fcdf20, outheadp=0x2fcbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81e91d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 461 (Thread 177.461): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fdbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3795, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x824b9a8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4861, seqno=93, control=11977, offset=0, data=81657856, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4861, seqno=93, control=11977, offset=0, data=81657856, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2fddf20, OutHeadP=0x2fdbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2fddf20, outp=0x2fdbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2fddf20, outheadp=0x2fdbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81e9a28) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 462 (Thread 177.462): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2fedf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ea280) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 463 (Thread 177.463): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x2ffbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3801, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x82a5fa8) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11849, seqno=93, control=6975, offset=0, data=83914752, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11849, seqno=93, control=6975, offset=0, data=83914752, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x2ffdf20, OutHeadP=0x2ffbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x2ffdf20, outp=0x2ffbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x2ffdf20, outheadp=0x2ffbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81eaad8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 464 (Thread 177.464): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x300bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3804, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11860, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x300df20, outheadp=0x300bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81eb330) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 465 (Thread 177.465): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x301bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3807, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4861, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x301df20, outheadp=0x301bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ebb88) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 466 (Thread 177.466): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x302df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ec3e0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 467 (Thread 177.467): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x303df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ecc38) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 468 (Thread 177.468): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x304df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ed490) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 469 (Thread 177.469): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x305bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3819, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11816, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x305df20, outheadp=0x305bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81edce8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 470 (Thread 177.470): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x306bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3822, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11847, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x306df20, outheadp=0x306bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ee540) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 471 (Thread 177.471): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x307bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3825, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=5049, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x307df20, outheadp=0x307bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81eed98) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 472 (Thread 177.472): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x308df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ef5f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 473 (Thread 177.473): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x309df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81efe48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 474 (Thread 177.474): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3834, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11852, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x30adf20, outheadp=0x30abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f06a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 475 (Thread 177.475): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f0ef8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 476 (Thread 177.476): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3840, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11827, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x30cdf20, outheadp=0x30cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f1750) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 477 (Thread 177.477): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f1fa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 478 (Thread 177.478): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f2800) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 479 (Thread 177.479): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x30fbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3849, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x81432f0) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=6765, seqno=93, control=11752, offset=0, data=67751936, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=6765, seqno=93, control=11752, offset=0, data=67751936, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x30fdf20, OutHeadP=0x30fbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x30fdf20, outp=0x30fbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x30fdf20, outheadp=0x30fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x81f3058) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 480 (Thread 177.480): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x310bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3852, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4853, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x310df20, outheadp=0x310bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f38b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 481 (Thread 177.481): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x311bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3855, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11888, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x311df20, outheadp=0x311bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f4108) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 482 (Thread 177.482): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x312df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f4960) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 483 (Thread 177.483): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x313df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f51b8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 484 (Thread 177.484): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x314df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f5a10) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 485 (Thread 177.485): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x315df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f6268) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 486 (Thread 177.486): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x316bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3870, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4873, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x316df20, outheadp=0x316bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f6ac0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 487 (Thread 177.487): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x317df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f7318) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 488 (Thread 177.488): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x318df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f7b70) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 489 (Thread 177.489): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x319bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3879, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11827, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x319df20, outheadp=0x319bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f83c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 490 (Thread 177.490): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f8c20) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 491 (Thread 177.491): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81f9478) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 492 (Thread 177.492): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3888, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4851, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x31cdf20, outheadp=0x31cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81f9cd0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 493 (Thread 177.493): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fa528) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 494 (Thread 177.494): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31edf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fad80) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 495 (Thread 177.495): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x31fbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3897, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11849, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x31fdf20, outheadp=0x31fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81fb5d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 496 (Thread 177.496): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x320df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fbe30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 497 (Thread 177.497): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x321df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fc688) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 498 (Thread 177.498): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x322df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fcee0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 499 (Thread 177.499): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x323df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fd738) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 500 (Thread 177.500): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x324df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fdf90) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 501 (Thread 177.501): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x325df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81fe7e8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 502 (Thread 177.502): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x326bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3918, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6841, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x326df20, outheadp=0x326bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x81ff040) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 503 (Thread 177.503): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x327df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x81ff898) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 504 (Thread 177.504): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x328bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3924, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4864, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x328df20, outheadp=0x328bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x82000f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 505 (Thread 177.505): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x329df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8200948) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 506 (Thread 177.506): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32adf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82011a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 507 (Thread 177.507): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32bdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82019f8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 508 (Thread 177.508): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32cdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8202250) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 509 (Thread 177.509): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8202aa8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 510 (Thread 177.510): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3942, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6778, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x32edf20, outheadp=0x32ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8203300) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 511 (Thread 177.511): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x32fbbb8, option=2, send_size=0, rcv_size=24, rcv_name=3945, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8133628) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=4787, seqno=93, control=2767, offset=0, data=85045248, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=4787, seqno=93, control=2767, offset=0, data=85045248, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x32fdf20, OutHeadP=0x32fbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x32fdf20, outp=0x32fbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x32fdf20, outheadp=0x32fbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8203b58) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 512 (Thread 177.512): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x330df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82043b0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 513 (Thread 177.513): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x331bbb8, option=2, send_size=0, rcv_size=24, rcv_name=3951, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8260d48) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=11856, seqno=91, control=5370, offset=0, data=83353600, length=131072, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=11856, seqno=91, control=5370, offset=0, data=83353600, length=131072, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x331df20, OutHeadP=0x331bf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x1f, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x331df20, outp=0x331bf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x331df20, outheadp=0x331bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8204c08) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 514 (Thread 177.514): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x332df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8205460) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 515 (Thread 177.515): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x333df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8205cb8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 516 (Thread 177.516): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x334df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8206510) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 517 (Thread 177.517): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x335df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8206d68) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 518 (Thread 177.518): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x336df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x82075c0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 519 (Thread 177.519): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x337df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8207e18) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 520 (Thread 177.520): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x338df20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8208670) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 521 (Thread 177.521): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x339bdb8, option=2, send_size=0, rcv_size=24, rcv_name=3975, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11863, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x339df20, outheadp=0x339bf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8208ec8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 522 (Thread 177.522): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33abdb8, option=2, send_size=0, rcv_size=24, rcv_name=3978, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=4787, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33adf20, outheadp=0x33abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x8209720) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 523 (Thread 177.523): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33bbc48, option=2, send_size=0, rcv_size=24, rcv_name=3981, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b475a in ports_port_deref (portstruct=0x8060928) at /home/sthibaul-guest/hurd-debian/./libports/port-deref.c:33 +#5 0x01059331 in _pager_do_write_request (object=27, seqno=473815, control=28, offset=14811136, data=12541952, length=4096, dirty=1, kcopy=1, initializing=0) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:257 +#6 0x010599d6 in _pager_seqnos_memory_object_data_return (object=27, seqno=473815, control=28, offset=14811136, data=12541952, length=4096, dirty=1, kcopy=1) at /home/sthibaul-guest/hurd-debian/./libpager/data-return.c:272 +#7 0x0105bee7 in _Xmemory_object_data_return (InHeadP=0x33bdf20, OutHeadP=0x33bbf10) at memory_objectServer.c:837 +#8 0x0105bd4f in _pager_seqnos_memory_object_server (InHeadP=0x0, OutHeadP=0xffffffe7) at memory_objectServer.c:947 +#9 0x0105adac in pager_demuxer (inp=0x33bdf20, outp=0x33bbf10) at /home/sthibaul-guest/hurd-debian/./libpager/demuxer.c:34 +#10 0x010b5163 in internal_demuxer (inp=0x33bdf20, outheadp=0x33bbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:101 +#11 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#12 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#13 0x010b0058 in cthread_body (self=0x8209f78) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#14 0x00000000 in ?? () + +Thread 524 (Thread 177.524): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33cbdb8, option=2, send_size=0, rcv_size=24, rcv_name=3984, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=11860, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33cdf20, outheadp=0x33cbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x820a7d0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 525 (Thread 177.525): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33ddf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x820b028) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 526 (Thread 177.526): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33ebdb8, option=2, send_size=0, rcv_size=24, rcv_name=3990, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f8f0, port=6731, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x33edf20, outheadp=0x33ebf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x820b880) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 527 (Thread 177.527): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x33fdf20, option=2050, send_size=0, rcv_size=8192, rcv_name=24, timeout=0, notify=0) at msg.c:110 +#2 0x010e4db4 in __mach_msg_server_timeout (demux=0x134ff38, max_size=8192, rcv_name=24, option=2048, timeout=0) at msgserver.c:101 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x820c0d8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 528 (Thread 177.528): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x395bdb8, option=2, send_size=0, rcv_size=24, rcv_name=8764, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=11800, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x395bf10, outheadp=0x395df20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a006a0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 529 (Thread 177.529): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x39bbdb8, option=2, send_size=0, rcv_size=24, rcv_name=8881, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x39bbf10, outheadp=0x39bdf20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a016f0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 530 (Thread 177.530): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x40ebf10, option=2051, send_size=48, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x83a9420) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 531 (Thread 177.531): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x43adf20, option=2051, send_size=40, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x3a4efc0) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 532 (Thread 177.532): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x47abdb8, option=2, send_size=0, rcv_size=24, rcv_name=13165, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=11806, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x47adf20, outheadp=0x47abf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x3a31a48) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 533 (Thread 177.533): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x48cdf20, option=2051, send_size=40, rcv_size=8192, rcv_name=18, timeout=0, notify=0) at msg.c:110 +#2 0x010e4e29 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:151 +#3 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#4 0x010b0058 in cthread_body (self=0x8400f30) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#5 0x00000000 in ?? () + +Thread 534 (Thread 177.534): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x4bbbdb8, option=2, send_size=0, rcv_size=24, rcv_name=4850, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=13460, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x4bbdf20, outheadp=0x4bbbf10) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x83bb9c8) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () + +Thread 535 (Thread 177.535): +#0 0x010e3efc in mach_msg_trap () at /build/buildd-eglibc_2.11.2-6+b1-hurd-i386-sWVQAp/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 +#1 0x010e46f9 in __mach_msg (msg=0x4bcbdb8, option=2, send_size=0, rcv_size=24, rcv_name=5058, timeout=0, notify=0) at msg.c:110 +#2 0x010aecef in cproc_block () at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:638 +#3 0x010af17a in __mutex_lock_solid (ptr=0x10b9488) at /home/sthibaul-guest/hurd-debian/./libthreads/cprocs.c:950 +#4 0x010b4565 in ports_lookup_port (bucket=0x805f6c0, port=6692, class=0x0) at /home/sthibaul-guest/hurd-debian/./libports/lookup-port.c:32 +#5 0x010b50d0 in internal_demuxer (inp=0x4bcbf10, outheadp=0x4bcdf20) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:86 +#6 0x010e4dc6 in __mach_msg_server_timeout (demux=0x133ff38, max_size=8192, rcv_name=18, option=2048, timeout=0) at msgserver.c:109 +#7 0x010b4eb0 in thread_function (master=0) at /home/sthibaul-guest/hurd-debian/./libports/manage-multithread.c:136 +#8 0x010b0058 in cthread_body (self=0x82b9038) at /home/sthibaul-guest/hurd-debian/./libthreads/cthreads.c:300 +#9 0x00000000 in ?? () diff --git a/open_issues/ext2fs_libports_reference_counting_assertion.mdwn b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn new file mode 100644 index 00000000..ff1c4c38 --- /dev/null +++ b/open_issues/ext2fs_libports_reference_counting_assertion.mdwn @@ -0,0 +1,93 @@ +[[!meta copyright="Copyright © 2012 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]] + + libports/port-ref.c:31: ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed + +This is seen every now and then. + + +# [[gnumach_page_cache_policy]] + +With that patch in place, the assertion failure is seen more often. + + +## IRC, freenode, #hurd, 2012-07-14 + + <youpi> braunr: I'm getting ext2fs.static: + /usr/src/hurd-debian/./libports/port-ref.c:31: ports_port_ref: Assertion + `pi->refcnt || pi->weakrefcnt' failed. + <youpi> oddly enough, that happens on one of the buildds only + <braunr> :/ + <braunr> i fear the patch can wake many of these issues + + +## IRC, freenode, #hurd, 2012-07-15 + + <youpi> braunr: same assertion failed on a second buildd + <braunr> can you paste it again please ? + <youpi> ext2fs.static: /usr/src/hurd-debian/./libports/port-ref.c:31: + ports_port_ref: Assertion `pi->refcnt || pi->weakrefcnt' failed. + <braunr> or better, answer the ml thread for future reference + <braunr> thanks + <youpi> braunr: I can't keep your patch on the buildds, it makes them too + unreliable + <braunr> youpi: ok + <braunr> i never got this error though, that's weird + <braunr> youpi: was the failure during the same build ? + <youpi> no, it was during package installation, and not the same + <youpi> braunr: note that I've already seen such errors, it's not new, but + it was way rarer + <youpi> like every month only + <braunr> ah ok + <braunr> yes it's less surprising then + <braunr> a tricky reference counting / locking mistake somewhere in the + hurd :) ... + <braunr> ah ! just got it ! + <bddebian> braunr: Got the error or found the problem? :) + <braunr> the former unfortunately :/ + + +## IRC, freenode, #hurd, 2012-07-19 + + <braunr> hm, i think those ext2fs port refs errors may also be due to stack + overflows + <pinotree> --verbose + <braunr> hm ? + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html + <pinotree> i mean, why do you think they could be due to that? + <braunr> the error is that both strong and weak refs in a port are 0 when + adding a reference + <braunr> weak refs are almost never used so let's forget about them + <braunr> when a ref count drops to 0, the port is automatically deallocated + <braunr> so what other than memory corruption setting this counter to 0 + could possibly do that ? :) + <pinotree> one could also guess an unbalanced ref/unref logic, somehow + <braunr> what do you mean ? + <pinotree> that for a bug, an early return, etc a port gets unref'ed often + than it is ref'ed + <braunr> highly unlikely, as they're protected by a lock + <braunr> pinotree: ah you mean, the object gets deallocated early because + of an deref overflow ? + <braunr> pinotree: could be, yes + <braunr> pinotree: i wonder if it could happen because of the periodic sync + duplicating the node table without holding references + <braunr> rah, libports uses a big lock in many places :( + <pinotree> braunr: yes, i meant that + <braunr> we could try using libduma some day + <braunr> i wonder if it could work out of the box + <pinotree> but that wouldn't help to find out whether a port gets deref'ed + too often, for instance + <pinotree> although it could be adapted to do so, i guess + <braunr> reproducing + a call trace or core would be best, but i'm not even + sure we can get that easily lol + +[[automatic_backtraces_when_assertions_hit]]. diff --git a/open_issues/ext2fs_page_cache_swapping_leak.mdwn b/open_issues/ext2fs_page_cache_swapping_leak.mdwn new file mode 100644 index 00000000..7c4cf52d --- /dev/null +++ b/open_issues/ext2fs_page_cache_swapping_leak.mdwn @@ -0,0 +1,364 @@ +[[!meta copyright="Copyright © 2011, 2012 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_hurd]] + +There is a [[!FF_project 272]][[!tag bounty]] on this task. + +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2011-03-24 + + <youpi> I still believe we have an ext2fs page cache swapping leak, however + <youpi> as the 1.8GiB swap was full, yet the ld process was only 1.5GiB big + <pinotree> a leak at swapping time, you mean? + <youpi> I mean the ext2fs page cache being swapped out instead of simply + dropped + <pinotree> ah + <pinotree> so the swap tends to accumulate unuseful stuff, i see + <youpi> yes + <youpi> the disk content, basicallyt :) + + +# IRC, freenode, #hurd, 2011-04-18 + + <antrik> damn, a cp -a simply gobbles down swap space... + <braunr> really ? + <braunr> that's weird + <braunr> why would a copy use so much anonymous memory ? + <braunr> unless the external pager is so busy that the kernel falls back to + its default pager + <youpi> that's what I suggested some time ago + <braunr> maybe this case should be traced in the kernel + <braunr> a simple message in the kernel buffer to warn that this condition + happened may help + <youpi> I'm seeing swap space being kept used on buildds for no real reason + except possibly backing ext2fs pages + <youpi> that could help, yes + <antrik> youpi: I think it was actually slpz who suggested that... + <youpi> I think we're generally missing feedback from memory behavior + <antrik> youpi: do you think andrei's kernel instrumentation work might be + helpful with analyzing such things? + <youpi> antrik: I think I suggested it too, but never mind + <youpi> antrik: no, because it's not a trace of events that you want + <youpi> some specific events would be useful + <youpi> but then we don't really need a whole framework for that + <antrik> apt-get upgrade eats swap too + <youpi> the upgrade itself, or the computation of the ugprade? + <youpi> apt is a memory eater nowadays + <antrik> installing the packages + <antrik> seems to have stabilized though after a while... + <antrik> so perhaps it's not a leak in this case + <youpi> ideally we should have a way to know what was put in the swap + <braunr> how would you represent what's in the swap ? + <antrik> the apt-get process has 46M of virtual memory above the 128 M + baseline + <braunr> mostly libraries i guess + <braunr> are trheads stacks 8 MiB like on Linux ? + <youpi> braunr: at least knowing how much of each process is in the swap + <youpi> braunr: 2MiB + <braunr> ok + <youpi> vminfo could also report which parts of the address space are in + the swap + <antrik> youpi: would be nice to have some simple utility reporting how + much of a process' address space is anonymous + <antrik> (in fact, I wonder why it's not reported by standard tools such as + ps or top... this shouldn't be too difficult I would think?) + <antrik> it would be much more useful information than the total virt size, + which includes rather meaningless disk and device mappings... + <youpi> agreed + <braunr> well + <braunr> there are tools like pmap for this + <braunr> unfortunately, it's difficult in mach to know what backs a + non-anonymous mapping + <braunr> pagers should be able to name their mappings + <youpi> that'd be helpful for debugging yes + <braunr> there is almost no overhead in doing that, and it would be very + useful + <youpi> and could lead to /proc/pid/maps + <braunr> yes + <braunr> isn't there a maps already ? + <youpi> nope + <braunr> ok + <youpi> (probably not very useful without the names) + <braunr> ithought i remembered maps without names, and guessed it might + have been on the hurd for that reason + <braunr> but i'm not sure + <youpi> there's the vminfo command, yes + <braunr> 14:06 < youpi> braunr: at least knowing how much of each process + is in the swap + <braunr> wouldn't it be clearer to do it the other way around ? + <braunr> like a swapinfo tool indicating what it contains ? + <youpi> sure, but it's a lot more difficult + <braunr> really ? + <braunr> why ? + <youpi> because you have to traverse all the mappings + <youpi> etc + <youpi> (in all processes, I mean) + <youpi> and you have to name what is waht + <braunr> there are other ways + <braunr> the swap is a central structure + <youpi> while simply introducing the swap % in vminfo + <youpi> for a given process you know what is what + <braunr> right + <youpi> and doing that introduction is probably very simple + <braunr> that's a good point + <braunr> top-down is effectively easier than bottom-up resolution in Mach + VM + <antrik> hm... the memory use caused by cp doesn't seem to be reflected in + the virtual size of any particular process + <antrik> ghost memory + <braunr> what's cp vmsize at the time of the problem ? + <antrik> it's at 134 M right now... so considering the 128 M baseline, + nothing worth speaking of + <braunr> right + <braunr> maybe a copy map during I/O + <braunr> but I don't know Mach copy maps in detail, as they have been + eliminated from UVM + <antrik> BTW, the memory eatup happens even before swap comes into + play... swapping seems to be a result of the problem, not the cause + <braunr> what do you mean ? + <braunr> I thought swapping was the issue + <braunr> you mean RAM is full before swapping ? + <antrik> well, I don't know what the actual problem is... I just don't + understand why the memory use increases without any particular process + seeing an increase in size + <antrik> the "free" size in vmstat decreses + <antrik> once it's eatun up, swap space use increases + <braunr> well it doesn't change much of it + <braunr> the anonymous memory pager will use RAM before resorting to the + external default-pager + <antrik> I would suspect normal block caching... but then, shouldn't this + show up in the memory info of the ext2 process? + <braunr> although, again, I'm not sure of the behaviour of the anonymous + memory pager + <braunr> antrik: I don't know how block caching behaves + <antrik> BTW, is it a know problem that doing ^C on a "cp -a" seems to hang + the whole system?... + <antrik> (the whole hurd instance that is... the other instance is not + affected) + <youpi> not that I know of + <braunr> seems like a deadlock in the anonymous memory handling + <youpi> (and I've never seen that) + <antrik> happens both in my main system (using ancient hurd/libc) and in my + subhurd (recently upgraded to current stuff) + <antrik> this make testing this stuff quite a lot harder... [sigh] + <antrik> any suggestions how to debug this hang? + <braunr> antrik: no :/ + +2011-04-28: [[!taglink open_issue_documentation]] + + <antrik> hm... is it normal that "swap free" doesn't increase as a process' + memory is paged back in? + <youpi> yes + <youpi> there's no real use cleaning swap + <youpi> on the contrary, it makes paging the process out again longer + <antrik> hm... so essentially, after swapping back and forth a bit, a part + of the swap equal to the size of physical RAM will be occupied with stuff + that is actually in RAM? + <youpi> yes + <youpi> so that that RAM can be freed immediately if needed + <antrik> hm... that means my effective swap size is only like 300 MB... no + wonder I see crashes under load + <antrik> err... make that 230 actually + <antrik> indeed, quitting the application freed both the physical RAM and + swap space + <braunr> 02:28 < antrik> hm... is it normal that "swap free" doesn't + increase as a process' memory is paged back in? + <braunr> swap is the backing store of anonymous memory, like ext2fs is the + backing store of memory objects created from its pager + <braunr> so you can view swap as the file system for everything that isn't + an external memory object + + +# IRC, freenode, #hurd, 2011-11-15 + + <braunr> hm, now my system got unstable + <braunr> swap is increasing, without any apparent reason + <antrik> you mean without any load? + <braunr> with load, yes + <braunr> :) + <antrik> well, with load is "normal"... + <antrik> at least for some loads + <braunr> i can't create memory pressure to stress reclaiming without any + load + <antrik> what load are you using? + <braunr> ftp mirrorring + <antrik> hm... never tried that; but I guess it's similar to apt-get + <antrik> so yes, that's "normal". I talked about it several times, and also + wrote to the ML + <braunr> antrik: ok + <antrik> if you find out how to fix this, you are my hero ;-) + <braunr> arg :) + <antrik> I suspect it's the infamous double swapping problem; but that's + just a guess + <braunr> looks like this + <antrik> BTW, if you give me the exact command, I could check if I see it + too + <braunr> i use lftp (mirror -Re) from a linux git repository + <braunr> through sftp + <braunr> (lots of small files, big content) + <antrik> can't you just give me the exact command? I don't feel like + figuring it out myself + <braunr> antrik: cd linux-stable; lftp sftp://hurd_addr/ + <braunr> inside lftp: mkdir linux-stable; cd linux-stable; mirror -Re + <braunr> hm, half of physical memory just got freed + <braunr> our page cache is really weird :/ + <braunr> (i didn't delete any file when that happened) + <antrik> hurd_addr? + <braunr> ssh server ip address + <braunr> or name + <braunr> of your hurd :) + <antrik> I'm confused. you are mirroring *from* the Hurd box? + <braunr> no, to it + <antrik> ah, so you login via sftp and then push to it? + <braunr> yes + <braunr> fragmentation looks very fine + <braunr> even for the huge pv_entry cache and its 60k+ entries + <braunr> (and i'm running a kernel with the cpu layer enabled) + <braunr> git reset/status/diff/log/grep all work correctly + <braunr> anyway, mcsim's branch looks quite stable to me + <antrik> braunr: I can't reproduce the swap leak with ftp. free memory + idles around 6.5 k (seems to be the threshold where paging starts), and + swap use is constant + <antrik> might be because everything swappable is already present in swap + from previous load I guess... + <antrik> err... scratch that. was connected to the wrong host, silly me + <antrik> indeed swap gets eaten away, as expected + <antrik> but only if free memory actually falls below the + threshold. otherwise it just oscillates around a constant value, and + never touches swap + <antrik> so this seems to confirm the double swapping theory + <youpi> antrik: is that "double swap" theory written somewhere? + <youpi> (no, a quick google didn't tell me) + + +## IRC, freenode, #hurd, 2011-11-16 + + <antrik> youpi: + http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html talks + about "double paging". probably it's also the term others used for it; + however, the term is generally used in a completely different meaning, so + I guess it's not really suitable for googling either ;-) + <antrik> IIRC slpz (or perhaps someone else?) proposed a solution to this, + but I don't remember any details + <youpi> ok so it's the same thing I was thinking about with swap getting + filled + <youpi> my question was: is there something to release the double swap, + once the ext2fs pager managed to recover? + <antrik> apparently not + <antrik> the only way to free the memory seems to be terminating the FS + server + <youpi> uh :/ + + +# IRC, freenode, #hurd, 2011-11-30 + + <antrik> slpz: basically, whenever free memory goes below the paging + threshold (which seems to be around 6 MiB) while there is other I/O + happening, swap usage begins to increase continuously; and only gets + freed again when the filesystem translator in question exits + <antrik> so it sounds *very* much like pages go to swap because the + filesystem isn't quick enough to properly page them out + <antrik> slpz: I think it was you who talked about double paging a while + back? + <slpz> antrik: probably, sounds like me :-) + <antrik> slpz: I have some indication that the degenerating performance and + ultimate hang issues I'm seeing are partially or entirely caused by + double paging... + <antrik> slpz: I don't remember, did you propose some possible fix? + <slpz> antrik: hmm... perhaps it wasn't me, because I don't remember trying + to fix that problem... + <slpz> antrik: at which point do you think pages get duplicated? + <antrik> slpz: it was a question. I don't remember whether you proposed + something or not :-) + <antrik> slpz: basically, whenever free memory goes below the paging + threshold (which seems to be around 6 MiB) while there is other I/O + happening, swap usage begins to increase continuously; and only gets + freed again when the filesystem translator in question exits + <antrik> so it sounds *very* much like pages go to swap because the + filesystem isn't quick enough to properly page them out + <tschwinge> + http://www.bddebian.com:8888/~hurd-web/open_issues/ext2fs_page_cache_swapping_leak/ + <slpz> tschwinge: thanks + <slpz> antrik: I see + <tschwinge> Always at your service. ;-) + <slpz> antrik: I didn't addressed this problem directly, but when I've + modified the pageout mechanism to provide a special treatment for + external pages, I also removed the possibility of sending them to the + default pager + <slpz> antrik: this was in my experimental environment, of course + <antrik> slpz: oh, nice... so it may fix the issues I'm seeing? :-) + <antrik> anything testable yet? + <slpz> antrik: yes, only anonymous memory could be swapped with that + <slpz> antrik: it works, but is ugly as hell + <antrik> tschwinge: these is also your observation about compilations + getting slower on further runs, and my followups... I *suspect* it's the + same issue + +[[performance/degradation]]. + + <slpz> antrik: I'm thinking about establishing a repository for these + experimental versions, so they don't get lost with the time + <antrik> slpz: please do :-) + <slpz> antrik: perhaps in savannah's HARD project + <antrik> even if it's not ready for upstream, it would be nice if I could + test it -- right now it's bothering me more than any other Hurd issues I + think... + <slpz> also, there's another problem which causes performance degradation + with the simple use of the system + <tschwinge> slpz: Please just push to Savannah Hurd. Under your + slpz/... or similar. + <tschwinge> antrik: Might very well be, yes. + <slpz> and I almost sure it is the fragmentation of the task map + <slpz> tschwinge: ok + <slpz> after playing a bit with a translator, it can easily get more than + 3000 entries in its map + <antrik> slpz: yeah, other issues might play a role here as well. I + observed that terminating the problematic FS servers does free most of + the memory and remove most of the performance degradation, but in some + cases it's still very slow + <slpz> that makes vm_map_lookup a lot slower + <antrik> on a related note: any idea what can cause paging errors and a + system hang even when there is plenty of free swap? + <antrik> (I'm not entirely sure, but my impression is that it *might* be + related to the swap usage and performance degradation problems) + <slpz> I think this degree of fragmentation has something to do with the + reiterative mapping of memory objects which is done in pager-memcpy.c + <slpz> antrik: which kind of paging errors? + <antrik> hm... I don't think I ever noted down the exact message; but I + think it's the same you get when actually running out of swap + <slpz> antrik: that could be the default pager dying for some internal bug + <antrik> well, but it *seems* to go along with the performance degradation + and/or swap usage + <slpz> I also have the impression that we're using memory objects the wrong + way + <antrik> basically, once I get to a certain level of swap use and slowness + (after about a month of use), the system eventually dies + <slpz> antrik: I never had a system running for that time, so it could be a + completely different problem from what I've seen before :-/ + <slpz> Anybody has experience with block-level caches on microkernel + environments? + <antrik> slpz: yeah, it typically happens after about a month of my normal + use... but I can significantly accellerate it by putting some problematic + load on it, such as large apt-get runs... + <slpz> I wonder if it would be better to put them in kernel or in user + space. And in the latter, if it would be better to have one per-device + shared for all accesing translators, or just each task should have its + own cache... + <antrik> slpz: + http://lists.gnu.org/archive/html/bug-hurd/2011-09/msg00041.html is where + I described the issue(s) + <antrik> (should send another update for the most recent findings I + guess...) + <antrik> slpz: well, if we move to userspace drivers, the kernel part of + the question is already answered ;-) + <antrik> but I'm not sure about per-device cache vs. caching in FS server diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn new file mode 100644 index 00000000..a3a22b16 --- /dev/null +++ b/open_issues/extern_inline.mdwn @@ -0,0 +1,109 @@ +[[!meta copyright="Copyright © 2010, 2012 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]] + +[[!toc]] + + +# IRC, unknown channel, unknown date + + <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? + <youpi> why static inlines instead of extern lines ? + <youpi> +in + <youpi> static inlines can lead to space waste where it isn't inlined + <tschwinge> Are you sure about that -- I don't think so. + <tschwinge> At least with 99 inlining. + <youpi> what can the compiler do where it isn't inlined ? + <youpi> include a copy + <youpi> thus space waste + <youpi> 00000000004004b1 t f + <youpi> 00000000004004d5 t f + <youpi> I've juste checked + <youpi> two copies of my inline function + <youpi> one per .o + <tschwinge> Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch? + <tschwinge> It's been a long time that I had a look at this... + <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore. + <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance) + <youpi> but the duplication issue still holds + <youpi> the functions not ending up in the library is a concern indeed + <tschwinge> That's what my second patch fixes, I think. + <youpi> grah, callisto rebooted for no reason + <youpi> ah, indeed the second patch fixes things correctly + <youpi> uh, indeed it's --dbg-package=hurd in there + <youpi> how odd + <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline + <tschwinge> Is this true: + <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol. + <youpi> so as to not expose it + <youpi> for other cases we can keep an extern inline as they are just programs + <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available. + <youpi> and that avoids duplicate code + <youpi> yes + <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem + <tschwinge> Sure, that'd be the alternative. + <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines) + <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline? + <youpi> for programs, you can just keep them all extern inlines + <youpi> yes, it shares code + <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines + <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline? + <youpi> for programs just always use extern lines + <youpi> +in + <youpi> as you don't care about symbol exposure + <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern + <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places. + <youpi> yes + <tschwinge> But probably didn't notice so far, as the functions could always be inlined. + <youpi> probably because we used to have luck + <youpi> yes + <tschwinge> Yes, I was thinking about the term/munge.c thing. + <tschwinge> OK, I think I get it now. Then I'll try to fix this accordingly. + <tschwinge> But not now. Thanks for the help! + <youpi> ok, thanks + <tschwinge> It was quite a bit confusing to me. + <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think). + <youpi> inline definitely is confusing + <youpi> especially since the semantic has changed over time and according to standards :) + <tschwinge> And then GCC changing that according to C99. + <tschwinge> Yes. + + +# IRC, freenode, #hurd, 2012-03-14 + + <youpi> + http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=blob;f=debian/patches/extern_inline_fix.patch;h=b9eacbff97dc56e99a69ddb601a5fc948f6e44a7;hb=HEAD + <youpi> maybe review it, and then we apply it + <pinotree> + http://patch-tracker.debian.org/patch/series/view/hurd/20120222-1/extern_inline_fix.patch + ;) + <civodul> youpi: the #ifdef __USE_EXTERN_INLINES in there and the extra + "extern" decls look wrong to me + <youpi> iirc USE_EXTERN_INLINES is needed + <youpi> otherwise it's not compliant + <youpi> or maybe it's for -O0 + <youpi> anyway IIRC it's needed + <civodul> when !defined __USE_EXTERN_INLINES, you end up with extern decls + with no corresponding definition + <youpi> yes + <youpi> they are defined in the code + <civodul> where? + <youpi> there's a special .c file in each lib + <youpi> libdiskfs/extern-inline.c + <youpi> etc + <civodul> oooh, right + <youpi> extern inline means that anyway + <youpi> the compiler is allowed to not always inline + <civodul> yes + <civodul> that looks good to me, then + <civodul> youpi: can you apply it, with proper authorship & co.? + <civodul> (no rush, though) + <youpi> sure diff --git a/open_issues/faccessat.mdwn b/open_issues/faccessat.mdwn new file mode 100644 index 00000000..911acbb6 --- /dev/null +++ b/open_issues/faccessat.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 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_hurd]] + +`faccessat()` fails on some cases; in particular when: + +* flags does not have `AT_EACCESS` +* dirfd is not `AT_FDCWD` +* pathname is not an absolute path + +In such case, it will return -1 setting `ENOTSUP` as errno. + +[[faccessat.c]] diff --git a/open_issues/faccessat/faccessat.c b/open_issues/faccessat/faccessat.c new file mode 100644 index 00000000..24b1233c --- /dev/null +++ b/open_issues/faccessat/faccessat.c @@ -0,0 +1,26 @@ +#include <fcntl.h> +#include <unistd.h> +#include <stdio.h> +#include <errno.h> +#include <string.h> +#include <stdlib.h> + +#define TESTFN "faccessat-test-file" + +int main() +{ + int fd; + int ret; + + system("touch " TESTFN ); + fd = open(".", O_RDONLY); + printf("> open: %d\n", fd); + + errno = 0; + ret = faccessat(fd, TESTFN, R_OK, 0); + printf("> faccessat: %d, %d (%s)\n", ret, errno, strerror(errno)); + + close(fd); + + return 0; +} diff --git a/open_issues/fakeroot_eagain.mdwn b/open_issues/fakeroot_eagain.mdwn new file mode 100644 index 00000000..6b684a04 --- /dev/null +++ b/open_issues/fakeroot_eagain.mdwn @@ -0,0 +1,216 @@ +[[!meta copyright="Copyright © 2012 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_porting]] + + +# IRC, freenode, #hurd, 2012-12-05 + + <braunr> rbraun 18813 R 2hrs ln -sf ../af_ZA/LC_NUMERIC + debian/locales-all/usr/lib/locale/en_BW/LC_NUMERIC + <braunr> when building glibc + <braunr> is this a known issue ? + <tschwinge> braunr: No. Can you get a backtrace? + <braunr> tschwinge: with gdb you mean ? + <tschwinge> Yes. If you have any debugging symbols (glibc?). + <braunr> or the build log leading to that ? + <braunr> ok, i will next time i have it + <tschwinge> OK. + <braunr> (i regularly had it when working on the pthreads port) + <braunr> tschwinge: + http://www.sceen.net/~rbraun/hurd_glibc_build_deadlock_trace + <braunr> youpi: ^ + <youpi> Mmm, there's not so much we can do about this one + <braunr> youpi: what do you mean ? + <youpi> the problem is that it's really a reentrency issue of the libc + locale + <youpi> it would happen just the same on linux + <braunr> sure + <braunr> but hat doesn't mean we can't report and/or fix it :) + <youpi> (the _nl_state_lock) + <braunr> do you have any workaround in mind ? + <youpi> no + <youpi> actually that's what I meant by "there's not so much we can do + about this" + <braunr> ok + <youpi> because it's a bad interaction between libfakeroot and glibc + <youpi> glibc believe fxtstat64 would never call locale functions + <youpi> but with libfakeroot it does + <braunr> i see + <youpi> only because we get an EAGAIN here + <braunr> but hm, doesn't it happen on linux ? + <youpi> EAGAIN doesn't happen on linux for fxstat64, no :) + <braunr> why does it happen on the hurd ? + <youpi> I mean for fakeroot stuff + <youpi> probably because fakeroot uses socket functions + <youpi> for which we probably don't properly handleEAGAIN + <youpi> I've already seen such kind of issue + <youpi> in buildd failures + <braunr> ok + <youpi> (so the actual bug here is EAGAIN + <youpi> ) + <braunr> yes, so we can do something about it + <braunr> worth a look + <pinotree> (implement sysv semaphores) + <youpi> pinotree: if we could also solve all these buildd EAGAIN issues + that'd be nice :) + <braunr> that EAGAIN error might also be what makes exim behave badly and + loop forever + <youpi> possibly + <braunr> i've updated the trace with debugging symbols + <braunr> it fails on connect + <pinotree> like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=563342 ? + <braunr> it's EAGAIN, not ECONNREFUSED + <pinotree> ah ok + <braunr> might be an error in tcp_v4_get_port + + +## IRC, freenode, #hurd, 2012-12-06 + + <braunr> hmm, tcp_v4_get_port sometimes fails indeed + <gnu_srs> braunr: may I ask how you found out, adding print statements in + pfinet, or? + <braunr> yes + <gnu_srs> OK, so that's the only (easy) way to debug. + <braunr> that's the last resort + <braunr> gdb is easy too + <braunr> i could have added a breakpoint too + <braunr> but i didn't want to block pfinet while i was away + <braunr> is it possible to force the use of fakeroot-tcp on linux ? + <braunr> the problem seems to be that fakeroot doesn't close the sockets + that it connected to faked-tcp + <braunr> which, at some point, exhauts the port space + <pinotree> braunr: sure + <pinotree> change the fakeroot dpkg alternative + <braunr> ok + <pinotree> calling it explicitly `fakeroot-tcp command` or + `dpkg-buildpackage -rfakeroot-tcp ...` should work too + <braunr> fakeroot-tcp looks really evil :p + <braunr> hum, i don't see any faked-tcp process on linux :/ + <pinotree> not even with `fakeroot-tcp bash -c "sleep 10"`? + <braunr> pinotree: now yes + <braunr> but, does it mean faked-tcp is started for *each* process loading + fakeroot-tcp ? + <braunr> (the lib i mean) + <pinotree> i think so + <braunr> well the hurd doesn't seem to do that at all + <braunr> or maybe it does and i don't see it + <braunr> the stale faked-tcp processes could be those that failed something + only + <pinotree> yes, there's also that issue: sometimes there are stake + faked-tcp processes + <braunr> hum no, i see one faked-tcp that consumes cpu when building glibc + <pinotree> *stale + <braunr> it's the same process for all commands + <pinotree> <braunr> but, does it mean faked-tcp is started for *each* + process loading fakeroot-tcp ? + <pinotree> → everytime you start fakeroot, there's a new faked-xxx for it + <braunr> it doesn't look that way + <braunr> again, on the hurd, i see one faked-tcp, consuming cpu while + building so i assume it services libfakeroot-tcp requests + <pinotree> yes + <braunr> which means i probably won't reproduce the problem on linux + <pinotree> it serves that fakeroot under which the binary(-arch) target is + run + <braunr> or perhaps it's the normal fakeroot-tcp behaviour on sid + <braunr> pinotree: a faked-tcp that is started for each command invocation + will implicitely make the network stack close all its sockets when + exiting + <braunr> pinotree: as our fakeroot-tcp uses the same instance of faked-tcp, + it's a lot more likely to exhaust the port space + <pinotree> i see + <braunr> i'll try on sid and see how it behaves + <braunr> pinotree: on the other hand, forking so many processes at each + command invocation may make exec leak a lot :p + <braunr> or rather, a lot more + <braunr> (or maybe not, since it leaks only in some cases) + +[[exec_leak]]. + + <braunr> pinotree: actually, the behaviour under linux is the same with the + alternative correctly set, whereas faked-tcp is restarted (if used at + all) with -rfakeroot-tcp + <braunr> hm no, even that isn't true + <braunr> grr + <braunr> pinotree: i think i found a handy workaround for fakeroot + <braunr> pinotree: the range of local ports in our networking stack is a + lot more limited than what is configured in current systems + <braunr> by extending it, i can now build glibc \o/ + <pinotree> braunr: what are the current ours and the usual one? + <braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c + <braunr> the modern ones are the ones suggested in the comment + <braunr> sysctl_local_port_range is the symbol storing the range + <pinotree> i see + <pinotree> what's the current range on linux? + <braunr> 20:44 < braunr> the modern ones are the ones suggested in the + comment + <pinotree> i see + <braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range + <braunr> 32768 61000 + <braunr> so, i'm not sure why we have the problem, since even on linux, + netstat doesn't show open bound ports, but it does help + <braunr> the fact faked-tcp can remain after its use is more problematic + <pinotree> (maybe pfinet could grow a (startup-only?) option to change it, + similar to that sysctl) + <braunr> but it can also stems from the same issue gnu_srs found about + closed sockets that haven't been shut down + <braunr> perhaps + <braunr> but i don't see the point actually + <braunr> we could simply change the values in the code + + <braunr> youpi: first, in pfinet, i increased the range of local ports to + reduce the likeliness of port space exhaustion + <braunr> so we should get a lot less EAGAIN after that + <braunr> (i've not committed any of those changes) + <youpi> range of local ports? + <braunr> see pfinet/linux-src/net/ipv4/tcp_ipv4.c, tcp_v4_get_port function + and sysctl_local_port_range array + <youpi> oh + <braunr> EAGAIN is caused by tcp_v4_get_port failing at + <braunr> /* Exhausted local port range during search? */ + <braunr> if (remaining <= 0) + <braunr> goto fail; + <youpi> interesting + <youpi> so it's not a hurd bug after all + <youpi> just a problem in fakeroot eating a lot of ports + <braunr> maybe because of the same issue gnu_srs worked on (bad socket + close when no clean shutdown) + <braunr> maybe, maybe not + <braunr> but increasing the range is effective + <braunr> and i compared with what linux does today, which is exactly what + is in the comment above sysctl_local_port_range + <braunr> so it looks safe + <youpi> so that means that the pfinet just uses ports 1024- 4999 for + auto-allocated ports? + <braunr> i guess so + <youpi> the linux pfinet I meant + <braunr> i haven't checked the whole code but it looks that way + <youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_min[] = { 1, 1 + }; + <youpi> ./sysctl_net_ipv4.c:static int ip_local_port_range_max[] = { 65535, + 65535 }; + <youpi> looks like they have increased it since then :) + <braunr> hum :) + <braunr> $ cat /proc/sys/net/ipv4/ip_local_port_range + <braunr> 32768 61000 + <youpi> yep, same here + <youpi> ./inet_connection_sock.c: .range = { 32768, 61000 }, + <youpi> so there are two things apparently + <youpi> but linux now defaults to 32k-61k + <youpi> braunr: please just push the port range upgrade to 32Ki-61K + <braunr> ok, will do + <youpi> there's not reason not to do it + + +## IRC, freenode, #hurd, 2012-12-11 + + <braunr> youpi: at least, i haven't had any failure building eglibc since + the port range patch + <youpi> good :) diff --git a/open_issues/fakeroot_exit_0.mdwn b/open_issues/fakeroot_exit_0.mdwn new file mode 100644 index 00000000..c6075b17 --- /dev/null +++ b/open_issues/fakeroot_exit_0.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]]."]]"""]] + + $ fakeroot ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include + [...] + + LD_LIBRARY_PATH=/usr/lib/libfakeroot:/usr/lib64/libfakeroot:/usr/lib32/libfakeroot + + LD_PRELOAD=libfakeroot-tcp.so + + ./scripts/mkinstalldirs /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/debian/tmp-libc/usr/include + libfakeroot: connect: Interrupted system call + + RESULT=0 + + exit $RESULT + + exit 0 + kill -s HUP 23612 + + kill -s HUP 23612 + +(The `EINTR` issue has been [[!debbug desc="fixed" 641200]].) + +`connect() < 0` invokes `fail()` which invokes `exit(1)`. Not yet figured out +why the process exits 0 dispite that. `LD_PRELOAD` issue? ([[!taglink +open_issue_glibc]].) + + +# Build + +`libacl1-dev` is missing. + + $ DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -uc -b -d diff --git a/open_issues/fcntl_locking_dev_null.mdwn b/open_issues/fcntl_locking_dev_null.mdwn new file mode 100644 index 00000000..4c65a5c4 --- /dev/null +++ b/open_issues/fcntl_locking_dev_null.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2012 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="fcntl locking /dev/null"]] + +[[!tag open_issue_hurd]] + + +# IRC, OFTC, #debian-hurd, 2012-07-06 + + <pinotree> regarding the libwibble failure (which holds libbuffy → + libbuffy-bindings), the failing test happens because it logs to /dev/null + as test file, + <pinotree> and while doing that, it wants to lock it first, having a + ENOTSUP in return + <youpi> oh + <youpi> locking null, how interesting + <youpi> what is that supposed to do ? :o) + <pinotree> from what i was reading posix, it would seem that such object is + considered a "File" + <youpi> is it our unimplemented record lock, or just the lock operation + that /dev/null doesn't support ? + <youpi> what size is null supposed to be? zero, right? + <pinotree> the latter + <youpi> ah + <youpi> so we can simply make lock return 0 + <youpi> since there's no byte to lock? + <youpi> I don't remember whether you can lock unexistant bytes + <pinotree> indeed, if i change the libwibble unit test to use eg /tmp/foo, + they pas + <pinotree> s diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn new file mode 100644 index 00000000..ece8fc89 --- /dev/null +++ b/open_issues/fdisk.mdwn @@ -0,0 +1,19 @@ +[[!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]]."]]"""]] + + Command (m for help): w + The partition table has been altered! + + Calling ioctl() to re-read partition table. + *Segmentation fault* + +Changes have been saved, though. + +Perhaps realted to the [[BLKRRPART_IOCTL]]? 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/fifo_thread_explosion.mdwn b/open_issues/fifo_thread_explosion.mdwn new file mode 100644 index 00000000..08f682f2 --- /dev/null +++ b/open_issues/fifo_thread_explosion.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2012 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]] + +As reported in [[!message-id "87sj80yb3e.fsf@kepler.schwinge.homeip.net"]], +after a [[GCC]] build (native, so three stages bootstrap), we got: + + PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 449 1000 3 1 1 10118 782M 198M 0.0 0:40.78 2:26.65 /hurd/fifo + +The other processes, in particular two instances of ext2fs and one of [[exec]], +looked reasonable. diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn new file mode 100644 index 00000000..563307a4 --- /dev/null +++ b/open_issues/file_locking.mdwn @@ -0,0 +1,74 @@ +[[!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 +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_glibc]] + +IRC, #hurd, 2010-12-31. + + <pinotree> youpi: i found the issue with python-apt + <pinotree> s/with/of/ + <youpi> good! + <pinotree> lock file issue, though :/ + <youpi> :/ + <pinotree> this is the sample test case, derived from apt's code: + http://paste.debian.net/103536/ + <pinotree> basically, it seems asking for a file lock in the same process + where there's already such lock on the file, fails + <pinotree> youpi: ↑ + <youpi> uh, posix doesn't even define some nesting + <pinotree> it seems it just talks about concurrency with other processes + <youpi> posix tells more about it later + <youpi> saying that if a lock already exists, then it is replaced by the + new + <youpi> (when inside the same process) + <pinotree> yay, found a bug in hurd :p + <youpi> well, actually it's known + <youpi> i.e. setlk is completely bogus, based on flock + <youpi> and flock doesn't have the same semantic in that regard + <youpi> so we can't fix it without really implementing setlk + <pinotree> the XXX comment in glibc/sysdeps/mach/hurd/fcntl.c, by chance? + :) + <youpi> of course :) + <pinotree> youpi: hm, flock's man page says: + <pinotree> "A process may only hold one type of lock (shared or exclusive) + on a file. Subsequent flock() calls on an already locked file will + convert an existing lock to the new lock mode." + <pinotree> so a new lock in the same process over the original lock should + replace the old one? + <youpi> uh, that's not what I had seen + <pinotree> http://linux.die.net/man/2/flock + <youpi> An attempt to lock the file using one of these file descrip- + <youpi> tors may be denied by a lock that the calling process + has already + <youpi> placed via another descriptor. + <youpi> so it's really not that easy + <pinotree> that's in case of trying to create a lock on a file with a + different fd than the existing lock + <youpi> that's what your testcase does + <pinotree> which, hm, is python-apt's case + <youpi> that being said, the sentence I pasted does not seem to appear in + posix + <pinotree> flock() does not seem posix + <youpi> it may have been the behavior of Linux at some point in the past + <youpi> it's not , but F_SETLK is + <youpi> and in linux world, flock <=> F_SETLK, iirc + <youpi> in glibc world, even + <youpi> (just checked it, see sysdeps/posix/flock.c + <youpi> pinotree: I guess your testcase works on Linux? + <pinotree> which means we should get a proper F_SETLK working, and then + just use this flock version (instead of the custom one), no? + <pinotree> yes, it works on linux (and on kfreebsd, see that python-apt + builds) + <youpi> no, I mean our flock() should probably be happy with locking part + of a file several times + <youpi> (that is, hurd's file_lock() RPC) + <youpi> ah, no, on Linux flock is its own system call + <youpi> (which is independant from lockf from the locking point of view, + iirc) diff --git a/open_issues/file_system_exerciser.mdwn b/open_issues/file_system_exerciser.mdwn new file mode 100644 index 00000000..c51863b9 --- /dev/null +++ b/open_issues/file_system_exerciser.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +Test our file system implementations with the File System Exerciser. + + * <http://codemonkey.org.uk/projects/fsx/> + + +# Alternatives + + +## fs_mark + + +### IRC, freenode, #hurd, 2012-04-30 + + <pinotree> mcsim: http://sourceforge.net/projects/fsmark/ + <pinotree> mcsim: just saw it in debian's NEW queue and from the + description it seemed like something it could be helpful for you + <pinotree> (and in general to test fs'es) diff --git a/open_issues/fork_deadlock.mdwn b/open_issues/fork_deadlock.mdwn new file mode 100644 index 00000000..c1fa9208 --- /dev/null +++ b/open_issues/fork_deadlock.mdwn @@ -0,0 +1,96 @@ +[[!meta copyright="Copyright © 2012 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]] + +This started appearing when Jérémie's [[glibc]] signal patches were integrated: +very sporadically, but still now and then, `fork` will hang, as follows, and +typically in `/bin/sh`. + +From a `libtool` invocation: + + #0 0x0107b13c in swtch_pri () at /build/eglibc-Q9jlik/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0107c9c4 in __spin_lock_solid (lock=0x125080c) at spin-solid.c:27 + No locals. + #2 0x01091427 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1250008) at hurdsig.c:172 + No locals. + #4 0x011261ec in _hurd_critical_section_unlock (our_lock=<optimized out>) at ../hurd/hurd/signal.h:235 + No locals. + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18784244, 19197896, 1, 16925832, 16925460, 17980399}, __mask_was_saved = 0, __saved_mask = 33}} + pid = 0 + err = <optimized out> + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1250008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +Another one in `dash`: + + #0 0x0105927c in swtch_pri () at /media/erich/home/thomas/tmp/glibc/debian/eglibc-2.13/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x0105ac44 in __spin_lock_solid (lock=0x123580c) at spin-solid.c:27 + No locals. + #2 0x010701c7 in __spin_lock (__lock=<optimized out>) at ../mach/lock-intern.h:55 + No locals. + #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172 + No locals. + #4 0x011048f0 in _hurd_critical_section_unlock (our_lock=0x1235008) at ../hurd/hurd/signal.h:235 + ss = 0x1235008 + pending = <optimized out> + #5 __fork () at ../sysdeps/mach/hurd/fork.c:706 + env = {{__jmpbuf = {18780148, 19087304, 134621988, 0, 16938700, 17842902}, __mask_was_saved = 0, __saved_mask = 4294967295}} + pid = 0 + err = 0 + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1235008 + threads = 0x0 + nthreads = 0 + stopped = 1 + i = 6 + [...] + + +# IRC, OFTC, #debian-hurd, 2012-11-24 + + <youpi> the lockups are about a SIGCHLD which gets lost + <pinotree> ah, ok + <youpi> which makes bash spin + <pinotree> is that happening more often recently, or it's just something i + just noticed? + <youpi> it's more often recently + <youpi> where "recently" means "some months ago" + <youpi> I didn't notice exactly when + <pinotree> i see + <youpi> it's at most since june, apparently + <youpi> (libtool managed to build without a fuss, while now it's a pain) + <youpi> (libtool building is a good test, it seems to be triggering quite + reliably) + + +## IRC, freenode, #hurd, 2012-11-27 + + <youpi> we also have the shell wait issue + <youpi> it's particularly bad on libtool calls + <youpi> the libtool package (with testsuite) is a good reproducer :) + <youpi> the symptom is shell scripts eating CPU + <youpi> busy-waiting for a SIGCHLD which never gets received + <braunr> that could be what i got + <braunr> + http://www.gnu.org/software/hurd/microkernel/mach/gnumach/memory_management.html + <braunr> last part + <youpi> perhaps watch has the same issue as the shell, yes diff --git a/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn new file mode 100644 index 00000000..39003ae4 --- /dev/null +++ b/open_issues/fork_mach_port_mod_refs_ekern_urefs_owerflow.mdwn @@ -0,0 +1,185 @@ +[[!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 +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="fork: mach_port_mod_refs: EKERN_UREFS_OWERFLOW"]] + +[[!toc]] + + +# Original Report + +In the [[GCC testsuite|gcc]], at this point: + + Running /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp ... + +... `expect` had gone bonkers: + + $ ps --all --format=hurd-long -w + PID UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + [...] + 3567 1000 10295 3567 3567 2 137M 856K 98.2 5hrs 28 hours expect -- /usr/share/dejagnu/runtest.exp --tool gcc + [...] + +Last lines of `gcc/testsuite/gcc/gcc.sum`: + + PASS: gcc.c-torture/unsorted/q.c, -O2 -flto -flto-partition=none + PASS: gcc.c-torture/unsorted/q.c, -O2 -flto + PASS: gcc.c-torture/unsorted/r.c, -O0 + PASS: gcc.c-torture/unsorted/r.c, -O1 + PASS: gcc.c-torture/unsorted/r.c, -O2 + PASS: gcc.c-torture/unsorted/r.c, -O3 -fomit-frame-pointer + PASS: gcc.c-torture/unsorted/r.c, -O3 -g + PASS: gcc.c-torture/unsorted/r.c, -Os + PASS: gcc.c-torture/unsorted/r.c, -O2 -flto -flto-partition=none + +Last lines of `gcc/testsuite/gcc/gcc.log`: + + Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c (timeout = 300) + spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -flto-partition=none -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c + PASS: gcc.c-torture/unsorted/r.c, -O2 -flto -flto-partition=none + Executing on host: /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c (timeout = 300) + spawn /media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/xgcc -B/media/data/home/tschwinge/tmp/gcc/hurd.build/gcc/ -w -O2 -flto -c -o /home/tschwinge/tmp/gcc/hurd.build/gcc/testsuite/gcc/r.o /home/tschwinge/tmp/gcc/hurd/gcc/testsuite/gcc.c-torture/unsorted/r.c + +The root filesystem is sort-of deadlocked: `syncfs -c /` doesn't finish +-- even without `-s`. But it is fine to spawn new processes, execute new +commands, etc. + +GDB on 3567: + + (gdb) info threads + 2 Thread 3567.2 0x011aaf4c in mach_msg_trap () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + * 1 Thread 3567.1 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + (gdb) bt + #0 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + #1 0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27 + #2 0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31 + #3 0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89 + #4 __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814 + #5 0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86 + #6 0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 + #7 0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62 + #8 0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466 + #9 0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119 + #10 0x0105bea6 in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #11 0x0105bf6d in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #12 0x0105c229 in exp_getptyslave () from /usr/lib/libexpect.so.5.44.1.15 + #13 0x0103e4b2 in ?? () from /usr/lib/libexpect.so.5.44.1.15 + #14 0x01087d79 in ?? () from /usr/lib/libtcl8.5.so.0 + #15 0x01088beb in ?? () from /usr/lib/libtcl8.5.so.0 + #16 0x0108826a in Tcl_EvalEx () from /usr/lib/libtcl8.5.so.0 + #17 0x0108985f in TclEvalObjEx () from /usr/lib/libtcl8.5.so.0 + [...] + (gdb) bt full + #0 0x011aaf9c in swtch_pri () at /build/buildd-eglibc_2.11.2-7-hurd-i386-6JVoJz/eglibc-2.11.2/build-tree/hurd-i386-libc/mach/swtch_pri.S:2 + No locals. + #1 0x011ac824 in __spin_lock_solid (lock=0x131e8e0) at spin-solid.c:27 + No locals. + #2 0x011aca1d in __mutex_lock_solid (lock=0x131e8e0) at mutex-solid.c:31 + No locals. + #3 0x0122dd0b in __mutex_lock (oldmem=0x8076458, bytes=94) at ../mach/lock-intern.h:89 + No locals. + #4 __libc_realloc (oldmem=0x8076458, bytes=94) at malloc.c:3814 + ar_ptr = <value optimized out> + nb = 104 + newp = 0x68 + oldp = 0x8076450 + oldsize = 104 + __func__ = "__libc_realloc" + #5 0x0121de62 in _IO_vasprintf (result_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n", args=0x15f3c9c "") at vasprintf.c:86 + sf = {_sbf = {_f = {_flags = -72515584, + _IO_read_ptr = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_read_end = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_read_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_write_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_write_ptr = 0x80764b5 "", _IO_write_end = 0x80764bc "\201\004", + _IO_buf_base = 0x8076458 "expect: ../sysdeps/mach/hurd/fork.c:466: __fork: Unexpected error: (os/kern) urefs overflow.\n", + _IO_buf_end = 0x80764bc "\201\004", _IO_save_base = 0x0, _IO_backup_base = 0x0, _IO_save_end = 0x0, _markers = 0x0, _chain = 0x0, _fileno = 20046008, + _flags2 = 0, _old_offset = 23018464, _cur_column = 0, _vtable_offset = 49 '1', _shortbuf = "\001", _lock = 0x0, _offset = 85643859813466072, + _codecvt = 0x1304583, _wide_data = 0x15f3bc0, _freeres_list = 0x0, _freeres_buf = 0x15f3c58, _freeres_size = 0, _mode = -1, + _unused2 = "\240;_\001\236D0\001\005\000\000\000\340;_\001(K3\001\000\000\000\000\005\000\000\000\000\000\000\000\250\230\060\001\260\303\031\001"}, + vtable = 0x131b9c0}, _s = {_allocate_buffer = 0x122cdf0 <__libc_malloc>, _free_buffer = 0x122cd20 <__libc_free>}} + ret = <value optimized out> + needed = 94 + #6 0x01206d1b in ___asprintf (string_ptr=0x15f40c0, format=0x13098a8 "%s%s%s:%u: %s%sUnexpected error: %s.\n") at asprintf.c:37 + done = 1 + #7 0x011e2fc8 in __assert_perror_fail (errnum=19, file=0x1305a98 "../sysdeps/mach/hurd/fork.c", line=466, function=0x1305acf "__fork") at assert-perr.c:62 + errbuf = "\334\r", '\000' <repeats 14 times>, "\f\265\032\001\000\000\000\000x\262\004\b\000\000\000\000\000\000\000\000\377\377\377\377 \262\004\b\250\065\063\001\070A_\001k\000\000\000\000\000\000\000ı2\001\002", '\000' <repeats 11 times>"\366, \377\377\377\270\235\004\bk\000\000\000X=_\001\037\343\037\001\377\377\377\377\000\000\000\000s=_\001\361\t\006\001\070A_\001\362\t\006\001\350\t\006\001\000\000\000\000\304B_\001\350\t\006\001\330\377_\001\033\000\000\000)\036\024\001\364\267\025\001x=_\001Bq\022\001\000\000\000\000\350:\b\b\230=_\001\364\267\025\001X\313\031\b S\005\b\230=_\001\004\334\f\001X\313\031\b\000\022\030\b\300L\005\b\364\267\025\001\370\021\030\b S\005\b\bB_\001\a\365\f\001 S\005\b\320\021\030\b\001\000\000\000\274A_\001,\316\024\001\001\000\000\000\001\000\000\000\344"... + buf = <value optimized out> + #8 0x012586c8 in __fork () at ../sysdeps/mach/hurd/fork.c:466 + newproc = 122 + sigthread_refs = 4 + portnames = 0x63000 + porttypes = 0x64000 + sigthread = 130 + state = {gs = 1, fs = 18236712, es = 20390776, ds = 17004532, edi = 1, esi = 143348, ebp = 23020160, esp = 0, ebx = 23020088, edx = 23020016, + ecx = 23020028, eax = 3966371413, eip = 23020088, cs = 18236712, efl = 0, uesp = 20138312, ss = 18488015} + newtask = 121 + thread = 139 + thread_refs = 65534 + statecount = <value optimized out> + nportnames = 142 + nporttypes = 142 + env = {{__jmpbuf = {20037620, 23068628, 23020252, 23020128, 23019736, 19231503}, __mask_was_saved = 0, __saved_mask = 4222451713}} + pid = <value optimized out> + err = EKERN_INVALID_ADDRESS + __PRETTY_FUNCTION__ = "__fork" + ss = 0x1376808 + threads = 0x65000 + nthreads = 2 + stopped = 0 + i = 2 + #9 0x011f92e9 in do_system (line=0x15f42dc "/bin/stty sane > /dev/ttypa") at ../sysdeps/posix/system.c:119 + status = <value optimized out> + save = <value optimized out> + pid = <value optimized out> + sa = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = 524288, sa_flags = 0} + omask = 0 + [...] + +`fork` failed here: + + 458 /* We have one extra user reference created at the beginning of this + 459 function, accounted for by mach_port_names (and which will thus be + 460 accounted for in the child below). This extra right gets consumed + 461 in the child by the store into _hurd_sigthread in the child fork. */ + 462 if (thread_refs > 1 && + 463 (err = __mach_port_mod_refs (newtask, ss->thread, + 464 MACH_PORT_RIGHT_SEND, + 465 thread_refs))) + 466 LOSE; + +This is in the parent, before signal thread setup, registering with the +proc server, and starting the new process. + +The error is 19, `EKERN_UREFS_OVERFLOW`. + +(This is likely also the reason why the error path did not execute +successfully.) + +[[!tag open_issue_glibc]] + +On 2010-11-30 and 2010-12-04, when I had again started the GCC testsuite, it +failed again, but at another position (understandably), but with the same +symptoms as shown below. In particular, the `thread_refs` values were the same +ones. + + +# Discussion + + * <http://lists.gnu.org/archive/html/bug-hurd/2010-11/msg00028.html> + + * <http://lists.gnu.org/archive/html/bug-hurd/2010-12/msg00002.html> + +This is likely *simply* a programming error in glibc's fork implementation. + + +# Bounty + +There is a [[!FF_project 273]][[!tag bounty]] on this task. diff --git a/open_issues/formal_verification.mdwn b/open_issues/formal_verification.mdwn new file mode 100644 index 00000000..474670c3 --- /dev/null +++ b/open_issues/formal_verification.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]]."]]"""]] + +*Formal verification* ([[!wikipedia Formal_verification desc="Wikipedia +article"]]) deals with formally reasoning about a program's correctness. + +Especially in the field of [[DSL]]s, this is used for asserting program codes' +correctness, as explained in {{$microkernel/barrelfish#fof_plos09}}, for +example. + +See also [[code_analysis]]. + +[[!toc]] + + +# Issues + + * [[locking_issues]] + + * [[term_blocking]] + + +# Bounty + +There is a [[!FF_project 276]][[!tag bounty]] on some of these tasks. diff --git a/open_issues/fsync.mdwn b/open_issues/fsync.mdwn new file mode 100644 index 00000000..d36a75ad --- /dev/null +++ b/open_issues/fsync.mdwn @@ -0,0 +1,22 @@ +[[!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 + + <youpi> azeem: I think I found why apt-get throws Hurd down sometimes + <youpi> the problem is that it basically write(file, 20MB); fsync(); + <youpi> i.e. it throws a storm of dirty-writeback to ext2fs + <youpi> which thus goes into throttling threads + <youpi> since posix explicitely says that fsync() can be void, I think I'll patch apt-get on the buildd + <youpi> (that bug has bitten me too many times in the past days to let it go further) + <youpi> for now it works + * youpi crosses fingers diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 76832165..66fad780 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,20 +1,132 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 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 open_issue_gcc fixed_in_debian]] +[[!tag open_issue_gcc]] -For GCC trunk: +Here's what's to be done for maintaining GCC. -Debian package has patches (for 4.3). Some have been forwarded upstream. (And -have been ignored.) [[Thomas_Schwinge|tschwinge]] is working on getting them -integrated. +Apart from the target-specific configuration machinery, there shouldn't be any +major differences within GCC between the GNU/Hurd and GNU/Linux ports, for +example. Especially all the compiler magic is all the same. + +[[!toc levels=2]] + + +# [[General information|/gcc]] + + +# [[Sources|source_repositories/gcc]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..upstream/trunk +-i +/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs: + +--> + +Last reviewed up to the [[Git mirror's be3860ba8df48cca3253da4f02fd2d42d856ce80 +(2012-12-10) sources|source_repositories/gcc]]. + +<http://gcc.gnu.org/install/configure.html> has documentation for the +`configure` switches. + + * Configure fragments that have `*linux*` cases might/should often contain + those for us (and GNU/k*BSD) as well. + + * `configure.ac` + + * `libgomp/configure.tgt` + + * `libstdc++-v3/configure.host` + + `abi_baseline_pair` etc. setting. + + * `libstdc++-v3/config/os/gnu-linux/*` + + Is used for all GNU systems, as per `libstdc++-v3/configure.host`. + Should rename to `gnu-user` to reflect this? + + * `gcc/acinclude.m4`:`gcc_GAS_FLAGS`: always pass `--32` to assembler for + x86 Linux. (Why?) + + * `hurd/usr` + + `NATIVE_SYSTEM_HEADER_DIR`, `638454a19c1c08f01c10517bc72a114250fc4f33`, + [[!message-id "mcrzkhcbftp.fsf@coign.corp.google.com"]]. + + Debian. + + * Eventually: get rid of this special-casing. [[!message-id + "gckk1s$e0b$1@ger.gmane.org"]]. + + * [[`libmudflap`|libmudflap]]. + + * [`-fsplit-stack`](http://nickclifton.livejournal.com/6889.html) + + * Also see `libgcc/config/i386/morestack.S`: comments w.r.t + `TARGET_THREAD_SPLIT_STACK_OFFSET`/`%gs:0x30` usage; likely needs + porting. + + * As per `libgcc/config/i386/t-stack-i386`, the former file is only used + for `-fsplit-stack` support -- which is currently enabled for us in + `libgcc/config.host`. + + * `gcc/config/gnu-user.h` defines `*SPLIT_STACK*` macros -- which aren't + valid for us (yet), I think. + + * Might `-fsplit-stack` be useful for us with respect to our + [[multithreaded|multithreading]] libraries? + + * `--enable-languages=[...]` + + * [[Ada (GNAT)|GNAT]] support is work in progress. + + * The [[Google Go's libgo|gccgo]] (introduced in + e440a3286bc89368b8d3a8fd6accd47191790bf2 (2010-12-03)) needs + OS configuration / support. + + * `--enable-frame-pointer` + + `gcc/configure.ac`: `enable_frame_pointer=no` + + * `--with-dwarf2`? + + * `--enable-werror` + + * `--enable-checking` + + * `--enable-linker-build-id` + + * `--enable-gnu-unique-object` + + * `--enable-lto` + + * `--enable-indirect-function` + + [[IFUNC]] + + * <http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html>, + <http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00672.html> + + * `gcc/config/t-linux` should be named `gcc/config/t-gnu-user` or + similar. Likewise for `gcc/config/i386/t-linux`. + + * Debian's GCC package has Hurd-specific patches. Some have been forwarded + upstream (and have been ignored). [[Thomas_Schwinge|tschwinge]] is working + on getting them integrated. * [\[meta-bug\] bootstrap bugs for \*-gnu\*](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21824) @@ -25,26 +137,564 @@ integrated. * [-fstack-protector shouldn't use TLS in freestanding mode](http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838) - * [Tool chain configuration: GNU/\* sharing stuff with - GNU/Linux](http://gcc.gnu.org/ml/gcc/2007-11/msg00289.html) + * See also commit bf1c0af128f33bd342636c4afeaa8f3a8a7cf8ca (reverted in + commit a204f0622242865ffea889bd698bc7c7bd236bd1), commit + 05c1aa95e6c37b3b281d749c76c673392941a031. + * Check before/after Joseph changes. (Should be fine.) + * 34618b3190c110b8926cc2b1db4b4eac95451995 »config-list.mk« -Additionally: + What's this used for? (Check ML.) Ask to include i686-pc-gnu (once it is + buildable out of the box)? See also + 73905b5de0d9a086f22ded7638bb1c0ae1b91326. - * Configure fragments that have `*linux*` cases might/should often contain - those for us (and GNU/k*BSD) as well. + * Various testsuite bits should include `*-*-gnu*`, too. - * `libgcc/configure.ac` [might - need](http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00315.html) to be - aligned for us to the `*linux*` cases. As well as at the end of - `libgcc/config.host`. Check. + * [low] [[toolchain/cross-gnu]] toolchain bootstrap vs. `fenv.h` in libgcc's + libbid: - checking whether decimal floating point is supported... no - checking whether fixed-point is supported... no + [...]/xgcc [...] -DIN_LIBGCC2 -fbuilding-libgcc [...] -Dinhibit_libc [...] -o bid_decimal_globals.o [...] -c [...]/libgcc/config/libbid/bid_decimal_globals.c + [...]/libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory + compilation terminated. + make[1]: *** [bid_decimal_globals.o] Error 1 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/i686-pc-gnu/libgcc' + make: *** [all-target-libgcc] Error 2 - * `libgomp/configure.tgt` + See threads at [[!message-id + "AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]], + [[!message-id "20110328225532.GE5293@synopsys.com"]], [[!message-id + "4D52D522.1040804@gmail.com"]]. Can simply configure the first GCC with + `--disable-decimal-float`. - * [[`libmudflap`|libmudflap]]. + Alternatively, can we use `#ifndef inhibit_libc` for this (these?) file(s)? + See `generic-nonstrack.c`, for example. The latter (and also + `generic-morestack-thread.c`) also has a nice explanation of `inhibit_libc` + which could be centralized at one place, for example definition of + `inhibit_libc`. + + * [low] [[toolchain/cross-gnu]] + + The directory that should contain system headers does not exist: + /media/boole-data/thomas/tmp/gnu-0/sys_root/usr/include + make[2]: *** [stmp-fixinc] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj/gcc' + make[1]: *** [all-gcc] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/gcc.obj' + + `mkdir` the directory for now, but what is really going on? GCC has *use + `/usr/include` patch*, but glibc still installs into `/include/`? + + * `__GLIBC__` + + IRC, freenode, #hurd, 2012-01-05: + + <civodul> on GNU/kFreeBSD, it's GCC that defines __GLIBC__, funny + <youpi> ?? + <youpi> not from features.h ? + <civodul> in gcc/config/kfreebsd-gnu.h + <civodul> :-) + <pinotree> correct, it's enabled in gcc's config + <pinotree> i discovered that after banging my head on the wall trying + to find out why some stuff wasn't compiling even after kfreebsd + porting patches adding preprocessors checks for __GLIBC__ + + GNU/kFreeBSD and GNU/kNetBSD: commit + 6396cc37141180db4d2c8f73cab4f5977d8a1e19 (2004-06-24, r83577), + GNU/kOpenSolaris: commit 3bef40126fb1633018fce47828df0fa9f65f110c + (2009-01-29, r143768). See also GDB commits + fda1b24c62843f81d31de2af57b1ed9c55f1e348 and + 1acb4f4ff73d20850a7524fc939d2651be75f47b, and binutils commits + e3081899be7570eb90ccfd5d767950d3a62871ee, + 127c4d4a4fe65bd17ea64db1be7f3c93d393afcb, + 47dbf5b634b955c2db1221715d15751e1281546a, and + ad2be7e8b846f4cd67fa1e032f98d5dc1cdb6b8d. + + IRC, freenode, #hurd, 2012-05-25: + + <gnu_srs> Hi, looks like __GLIBC__ is not defined by default for GNU? + <gnu_srs> touch foo.h; cpp -dM foo.h|grep LIBC: empty + <braunr> gnu_srs: well, this only tells your the compiler defaults + <tschwinge> gnu_srs: See the email I just sent. + + [[!message-id "87396od3ej.fsf@schwinge.name"]] + + <braunr> __GLIBC__ would probably be introduced by a glibc header + <gnu_srs> tschwinge: I saw your email. I wonder if features.h is + included in the kFreeBSD build of webkit. + <gnu_srs> It is defined in their build, but not in the Hurd build. + <pinotree> gcc on kfreebsd unconditionally defines __GLIBC__ + <pinotree> (a bit stupid choice imho, but hardly something that could + be changed now...) + <braunr> :/ + <braunr> personally i don't consider this only "a bit" stupid, as + kfreebsd is one of the various efforts pushing towards portability + <braunr> and using such hacks actually hinders portability ... + <pinotree> yeah don't tell me, i can remember at least half dozen of + occasions when a code wouldn't have been compiling at all on other + glibc platforms otherwise + <pinotree> sure, i have nothing against kfreebsd's efforts, but making + gcc define something which is proper of the libc used is stupid + <braunr> it is + <pinotree> i spotted changes like: + <pinotree> -#ifdef __linux + <pinotree> +#if defined(__linux__) || defined(__GLIBC__) + <pinotree> and wondered why they wouldn't work at all for us... and + then realized there were no #include in that file before that + preprocessor check + <tschwinge> This is even in upstream GCC gcc/config/kfreebsd-gnu.h: + <tschwinge> #define GNU_USER_TARGET_OS_CPP_BUILTINS() \ + <tschwinge> do \ + <tschwinge> { \ + <tschwinge> builtin_define ("__FreeBSD_kernel__"); \ + <tschwinge> builtin_define ("__GLIBC__"); \ + <tschwinge> builtin_define_std ("unix"); \ + <tschwinge> builtin_assert ("system=unix"); \ + <tschwinge> builtin_assert ("system=posix"); \ + <tschwinge> } \ + <tschwinge> while (0) + <tschwinge> I might raise this upstream at some point. + <pinotree> tschwinge: i could guess the change was proposed by the + kfreebsd people, so asking them before at d-bsd@d.o would be a start + <tschwinge> pinotree: Ack. + <pinotree> especially that they would need to fix stuff afterwards + <pinotree> imho we could propose them the change, and if they agree put + that as local patch to debian's gcc4.6/.7 after wheezy, so there is + plenty of time for them to fix stuff + <pinotree> what should be done first is, however, find out why that + define has been added to gcc + + [[!message-id "201211061305.02565.pino@debian.org"]]. + + * [low] Does `-mcpu=native` etc. work? (For example, + 2ae1f0cc764e998bfc684d662aba0497e8723e52.) + + * transactional memory, 4c0315d05fa0f707875686abc4f91f7a979a7c7b + + * `config/mmap.m4` + + * In `libitm/config/`, is the generic stuff (`tls.h`, etc.) enough for + us? + + * f29a2041f32773464e226a83f41762c2e9cf658e + (e53a96c2136f7cdff4699475fea41afeed9dece3) + + Testresults same as for GNU/Linux. + + * [high] 3efc00f6f17778172d3fa7ac737fa1473b3b4d5a, `Check __GLIBC__ when + using __SIGRTMIN`. GCC PR52390. Fixed by + 8d2259c83f94c082ad8a00b5d00bb639ce24efce. + + * 15ac1e637ad0cb92bf7629205c617ea847a4b810 `Build 64-bit libffi multilib for + i?86-linux`. + + * `libstdc++`: uses `_GLIBCXX_HAVE_TLS`, but where is this defined? Supposed + to come from `config/tls.m4:GCC_CHECK_TLS`? + + * `libgcc/gthr-posix.h:__gthread_active_p` -- is this suitable for us? This + is used in libgcc for ObjC wrapper stuff and similar in libstdc++. + C.f. [[!message-id "x57jobtqx89w.fsf@frobland.mtv.corp.google.com"]], + [[!message-id "x57jd359fkx3.fsf@frobland.mtv.corp.google.com"]] as well as + [[!debbug 629866]]/[[!message-id + "20110609002620.GA16719@const.famille.thibault.fr"]]. commit + 026e608ecebcb2a6193971006a85276307d79b00. + + * 549e2197b118efb2d947aaa15d445b05c1b5ed62 `Import the asan runtime library + into GCC tree`. Linux-specific things: + `ASAN_USE_ALIAS_ATTRIBUTE_FOR_INDEX`, `ASAN_LINUX`, `ASAN_POSIX`, + `libsanitizer/asan/asan_linux.cc`, + `libsanitizer/asan/asan_malloc_linux.cc`, + `libsanitizer/asan/asan_posix.cc`, + `libsanitizer/interception/interception.h`, + `libsanitizer/interception/interception_linux.cc`, + `libsanitizer/interception/interception_linux.h`, + `libsanitizer/sanitizer_common/sanitizer_allocator.cc`, + `libsanitizer/sanitizer_common/sanitizer_linux.cc`, + `libsanitizer/sanitizer_common/sanitizer_posix.cc`, + `libsanitizer/sanitizer_common/sanitizer_procmaps.h`, + `libsanitizer/sanitizer_common/sanitizer_symbolizer_linux.cc`. + 4afab99bf0fe2d6905a9fa9d6ab886ca102312df `Enable libsanitizer just on x86 + linux for now`. 492e75a7336b4dbfe38207ea3abf8d5bd72376a9 `Move + libsanitizer configure logic to subdirectory`. + 6aea389d84c2172668af5f108e2b17e131120d0b `Add STATIC_LIBASAN_LIBS for + -static-libasan`. Further commits later on. + + * 9cf754572854d9d9cd43c277eb7afb12e4911358 `Import tsan runtime from + llvm`. Linux-specific things: `libsanitizer/tsan/tsan_platform.h`, + `libsanitizer/tsan/tsan_platform_linux.cc`, + `libsanitizer/tsan/tsan_symbolize_addr2line_linux.cc`. + a96132f29aa3dfe94141a87537f62ea73ce0fc19 `Set TSAN_SUPPORTED=yes for + x86_64/i686-linux for 64-bit multilib`. Further commits later on. + + +# Build + +Here's a log of a GCC build run; this is from our [[Git repository's +a1d48e100791bc67ff355e0931a604e767c827b7 (2012-12-10; +be3860ba8df48cca3253da4f02fd2d42d856ce80 (2012-12-10)) +sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ (cd ../master/ && contrib/gcc_update --touch) + $ ../master/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --enable-languages=all,ada 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +This takes up around 3.5 GiB, and needs roughly 3.25 h on kepler.SCHWINGE and +14.25 h on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k RUNTESTFLAGS=-v check 2>&1 | tee log_test + +--> + + +## Analysis + + $ toolchain/logs/process gcc build + + * [[`checking if gcc static flag -static + works... no`|glibc_madvise_vs_static_linking]] + + Addressed in Debian glibc. + + * `host-linux.c` vs. `host-default.c` + + * *fixincludes* stuff + + * malloc? + + -cat ../../hurd/gcc/config/i386/pmm_malloc.h > mm_malloc.h + +cat ../../hurd/gcc/config/i386/gmm_malloc.h > mm_malloc.h + + Comes from `gcc/config.gcc`: `i386/t-pmm_malloc` vs. `i386/t-gmm_malloc` + for `i[34567]86-*-linux*` vs. `i[34567]86-*-*`. + + * *libgomp* + + * `libgomp/config/linux/`, `libgomp/config/linux/x86` + + `sed`ed away. + + * `-ftls-model=initial-exec -march=i486 -mtune=i686` + + `sed`ed away. + + * Missing `EOWNERDEAD`, `ENOTRECOVERABLE`. What're they used for? + + * `RLIMIT_VMEM`. Usage kosher? + + * `libtool: link: ar rc .libs/libstdc++.a [...]` + + Just different order of object files, or another problem? TODO + + * `libobjc/encoding.c`: + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/encoding.c -c [...] + +[...]/hurd/master/libobjc/encoding.c:128:1: warning: '_darwin_rs6000_special_round_type_align' defined but not used [-Wunused-function] + + * `libobjc/thr.c`: `gcc/gthr-posix.h` + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] [...]/hurd/master/libobjc/thr.c -c [...] + +In file included from [...]/hurd/master/libobjc/../libgcc/gthr.h:142:0, + + from [...]/hurd/master/libobjc/thr.c:45: + +../libgcc/gthr-default.h: In function '__gthread_objc_thread_set_priority': + +../libgcc/gthr-default.h:388:41: warning: unused parameter 'priority' [-Wunused-parameter] + + * `/proc/self/*` + + -checking for /proc/self/exe... yes + -checking for /proc/self/maps... yes + +checking for /proc/self/exe... no + +checking for /proc/self/maps... no + + * GCJ: `java-signal.h`, `java-signal-aux.h` + + -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal.h + -config.status: linking ../../../hurd/libjava/include/i386-signal.h to include/java-signal-aux.h + +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal.h + +config.status: linking ../../../hurd/libjava/include/default-signal.h to include/java-signal-aux.h + + * GCJ: `jni_md.h` + + -checking jni_md.h support... yes + +checking jni_md.h support... configure: WARNING: no + + * *default library search path* + + -checking for the default library search path... /lib /usr/lib /lib/i386-linux-gnu /usr/lib/i386-linux-gnu /lib/i486-linux-gnu /usr/lib/i486-linux-gnu /usr/local/lib + +checking for the default library search path... /lib /usr/lib + + [[binutils]] issue? Should be aligned by Samuel's binutils patch. + + * `./classpath/[...]/*.properties` + + Just different order of files, or another problem? + + * `libjava/gnu/gcj/util/natGCInfo.cc` + + libtool: compile: [...]/hurd/master.build/./gcc/xgcc [...] -c ../../../master/libjava/gnu/gcj/util/natGCInfo.cc [...] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:440:1: warning: unused parameter 'name' [-Wunused-parameter] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:446:1: warning: unused parameter 'name' [-Wunused-parameter] + +../../../master/libjava/gnu/gcj/util/natGCInfo.cc:452:1: warning: unused parameter 'name' [-Wunused-parameter] + + * `libgcj.la` + + Just different order of object files, or another problem? + + Is there a pattern that GNU/Hurd hands out the files alphabetically sorted + where it wouldn't need to ([[!taglink open_issue_hurd]])? + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` + + * `jar` + + make[2]: Entering directory `[...]/hurd/master.build/[ARCH]/libjava' + -: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=[...]/hurd/master.build/[ARCH]/libjava/scripts/jar" DO=all multi-do + +: make ; exec make "AR_FLAGS=rc" [...] "RANLIB=ranlib" "DESTDIR=" "JAR=jar" DO=all multi-do + + Probably because kepler.SCHWINGE has an OpenJDK `/usr/bin/jar`, and + coulomb.SCHWINGE a GCJ one. + + There are other instances of this in the following. + + * `value-unwind.h` + + -DEFINES='' HEADERS='../../../master/libgcc/config/i386/value-unwind.h' \ + +DEFINES='' HEADERS='' \ + ../../../master/libgcc/mkheader.sh > tmp-libgcc_tm.h + + Comes from `gcc/config.gcc`: for `i[34567]86-*-linux*` + vs. `i[34567]86-*-*`, but apparently is important only for *x86_64* anyway. + + * `soft-fp` prototypes + + ../../../master/libgcc/soft-fp/eqtf2.c:34:9: warning: no previous prototype for '__eqtf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/eqtf2.c:50:1: warning: no previous prototype for '__netf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/getf2.c:34:9: warning: no previous prototype for '__getf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/getf2.c:50:1: warning: no previous prototype for '__gttf2' [-Wmissing-prototypes] + + ../../../master/libgcc/soft-fp/letf2.c:34:9: warning: no previous prototype for '__letf2' [-Wmissing-prototypes] + +../../../master/libgcc/soft-fp/letf2.c:50:1: warning: no previous prototype for '__lttf2' [-Wmissing-prototypes] + + * `libatomic` on GNU/Linux compiles several more files than on GNU/Hurd. Is + that correct? Probably futex support. + + * 2e2db3f92b534460c68c2f9ae64455884424beb6..3336556d2cb32f46322922a83015f760cfb79d8f + + Both GNU/Linux and GNU/Hurd: + + -checking assembler for rep and lock prefix... yes + +checking assembler for rep and lock prefix... no + + TODO. + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 1 GiB, and needs roughly 5 min on kepler.SCHWINGE and 37 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc install + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + [[libtool]]. + + * `libjvm.la`, `.libs/libjvm.so`, `libgij.la`, `.libs/libgij.so.12.0.0` + + `-Wl,-Bsymbolic` vs. `-Wl,-Bsymbolic-functions` (as above) + + * `jar`: as above. + + +# Testsuite + +<http://gcc.gnu.org/install/test.html> + +Testing on GNU/Hurd is blocked on +[[fork_mach_port_mod_refs_ekern_urefs_owerflow]]. + +TODO. On GNU/Hurd, it is advisable to reboot after having built and installed +GCC, before running the testsuite, as otherwise there seems to be a tendency +that the system crashes during the `gcc.c-torture/compile/limits-structnest.c` +tests, which are rather memory hungry, see [[!message-id +"87bol6aixd.fsf@schwinge.name"]]. Likewise, it also seems advisable to add +further reboots in between, that is, separate `make check`'s `check-host` into +several separate runs, and then one for `check-target` (see +`[build]/Makefile:do-check`, `[build]/gcc/Makefile:CHECK_TARGETS`), as +otherwise there seems to be a tendency for the system crashing sooner or later. +(Running `check-host` accumulates to something like 44 hours worth of +forking/execing of GCC and testcases.) On GNU/Linux we run it in one go, so +that we'll catch any fundamental rearrangements of/additions to the testsuites. + +kepler.SCHWINGE: + + $ make -k check 2>&1 | tee log_test + [...] + +coulomb.SCHWINGE: + + $ awk '/^maybe-check-target/ { next; }; /^maybe-check-[^:]*:./ { print; };' < Makefile + maybe-check-fixincludes: check-fixincludes + maybe-check-gcc: check-gcc + maybe-check-intl: check-intl + maybe-check-libbacktrace: check-libbacktrace + maybe-check-libcpp: check-libcpp + maybe-check-libdecnumber: check-libdecnumber + maybe-check-libiberty: check-libiberty + maybe-check-zlib: check-zlib + maybe-check-gnattools: check-gnattools + maybe-check-lto-plugin: check-lto-plugin + $ grep ^CHECK_TARGETS gcc/Makefile + CHECK_TARGETS = check-ada check-c check-c++ check-fortran check-java check-lto check-objc + + $ export LC_ALL=C + + $ make -k check-fixincludes 2>&1 | tee log_test_1_check-fixincludes + [...] + $ make -k -C gcc check-ada 2>&1 | tee log_test_2_gcc_check-ada + [...] + [reboot] + $ make -k -C gcc check-c 2>&1 | tee log_test_2_gcc_check-c + [...] + [reboot] + $ make -k -C gcc check-c++ 2>&1 | tee log_test_2_gcc_check-c++ + [...] + [reboot] + $ make -k -C gcc check-fortran check-java check-lto check-objc 2>&1 | tee log_test_2_gcc_check-fortran,check-java,check-lto,check-objc + [...] + [reboot] + $ make -k check-intl check-libbacktrace check-libcpp check-libdecnumber check-libiberty check-zlib check-gnattools check-lto-plugin 2>&1 | tee log_test_3 + [...] + $ make -k check-target 2>&1 | tee log_test_4_check-target + [...] + +This needs roughly 7 h on kepler.SCHWINGE and 4 h (`check-fixincludes`, +`gcc/check-ada`) + 12.5 h (`gcc/check-c`) + 4.25 h (`gcc/check-c++`) + 5.5 h +(`gcc/check-fortran`, `gcc/check-java`, `gcc/check-lto`, `gcc/check-objc`) + +9 h (`check-intl`, [...], `check-lto-plugin`, `check-target`) = 35.25 h on +coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc test + + * PTYs + + Occasionally tests FAIL due to: + + spawn -open -1 failed, 1 5, The system has no more ptys. Ask your system administrator to create more. + + TODO. + + * As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26; + 769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), all + `gcc.dg/guality` and `g++.dg/guality` and a few more are no longer tested + on coulomb.SCHWINGE and kepler.SCHWINGE. + + * As of b401cb7ed15602d244a6807835b0b9d740a302a8 (2012-11-26; + 769bf18a20ee2540ca7601cdafabd62b18b9751b (2012-10-01)), there are + regressions (FAILs) in libgomp execution tests on coulomb.SCHWINGE. + + * 769bf18a20ee2540ca7601cdafabd62b18b9751b..be3860ba8df48cca3253da4f02fd2d42d856ce80 + + On GNU/Hurd: + + Running [...]/hurd/master/gcc/testsuite/g++.dg/tls/tls.exp ... + +FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test + +FAIL: g++.dg/tls/thread_local3g.C -std=gnu++11 execution test + +FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test + +FAIL: g++.dg/tls/thread_local4g.C -std=gnu++11 execution test + +FAIL: g++.dg/tls/thread_local5.C -std=gnu++11 execution test + +FAIL: g++.dg/tls/thread_local5g.C -std=gnu++11 execution test + + They used to PASS. + + * TODO + + +## Enhancements + + +### `contrib/testsuite-management/`, `contrib/regression/` + + * 35a27ee8c4b349fea44fd1fadc9614ab3cc9d578 `Add an xfail manifest for + x86_64-unknown-linux-gnu to trunk.` + + +### Parallel Testing + +[[!message-id "20110331070322.GI11563@sunsite.ms.mff.cuni.cz"]]. + + +### Distributed Testing + + +#### IRC, OFTC, #gcc, 2012-05-31 + + <dnovillo> jsm28: in your mentor testing, you have the source and build + tree available for make check? or it's a pure installed-tree test? + <jsm28> dnovillo: Source tree, install tree, no build tree. + <dnovillo> jsm28: so, you run make check on top of the source tree or copy + the */testsuite trees to a testing area? + <jsm28> Create a site.exp and do runtest in a temporary directory. runtest + is pointed to the source tree to find sources. + <jsm28> For cross testing for GNU/Linux targets, the temporary directory is + mounted at the same path on host and target. + <dnovillo> jsm28: thanks. i guess i'll have to find the slice of the + source tree i need to copy. + <dnovillo> jsm28: for libstdc++ do you write a different site.exp? + <dnovillo> i noticed that it generates a different site,exp there. + <jsm28> The site.exp is mostly the same for all testsuites (so includes + settings that only some testsuites use). + <dnovillo> ok, thanks. + <dnovillo> and when you say "pointed to the source tree" you mean "set + srcdir /path/to/top/of/gcc" ? + <dnovillo> (in site.exp) + <jsm28> The GDB testsuite requires that you run the GDB testsuite's + configure script in the temporary directory where you will run runtest. + I don't think any GCC testsuites we use have requirements like that. + <jsm28> dnovillo: --srcdir option to runtest. + <dnovillo> ah, yes. + <jsm28> (and --tool, --target_board etc.) + <dnovillo> right + <dnovillo> since i'm distributing the tests. i want each node to only do a + bunch of files. this means that i either use 'tool.exp=file-pattern' or + simply copy the subset of files i want tool.exp to find. + <dnovillo> i chose the second approach, but that breaks in a handful of + cases that need files from other sub-directories. + <dnovillo> like g++.dg gcc.dg using stuff from c-c++-common. + <dnovillo> for libstdc++, the possibilities for splitting are enormous as + it has many directories. + <dnovillo> but i'm not setting it right. runtest runs without even trying + to test anything. + <dnovillo> i'm not having it pick up the right driver. + <jsm28> Probably all .exp files should be copied to anywhere running + testsuites, since some read .exp files from other directories. + <dnovillo> jsm28: that could be it too. it's irritating that libstdc++ + does not even error out. runtest just does nothing and returns 0. + +##### IRC, OFTC, #gcc, 2012-06-06 + + <dnovillo> any libstdc++ maintainer around? + <dnovillo> or, does anyone know when the testsuite/data files are copied + into the running testsuite/ dir? + <dnovillo> seems to be done in advance by make. - * [[C++]]. +##### [[!message-id "4FC7791E.6040407@gmail.com"]] diff --git a/open_issues/gcc/c++.mdwn b/open_issues/gcc/c++.mdwn deleted file mode 100644 index cab4c1f1..00000000 --- a/open_issues/gcc/c++.mdwn +++ /dev/null @@ -1,41 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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_porting open_issue_gcc fixed_in_debian]] - -Modify the [[hurd/building/cross-compiling]] shell script to configure GCC for -building GCC with C++ support when building its second (i.e., final) version. - -Compiling a most-trivial C++ program used to work with GCC 4.2 and 4.3 (and the -resulting binaries would also work), but linking fails with GCC SVN trunk: - - $ $TARGET-g++ -Wall a.cc -lpthread - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__multf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fixunstfsi' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__subtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__divtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__copysigntf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__addtf3' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__lttf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__netf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__floatunsitf' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__eqtf2' - /home/thomas/tmp/gnu-0/lib/gcc/i586-pc-gnu/4.4.0/../../../../i586-pc-gnu/lib/libgcc_s.so: undefined reference to `__fabstf2' - collect2: ld returned 1 exit status - -Whether this defect report also applies to a natively-build GCC from SVN trunk -has not yet been checked. - -[[Thomas_Schwinge|tschwinge]] suspects the problem to be a configuration issue -of a GCC helper library, whose configuration setup has changed after GCC 4.3. - -The need for `-lpthread` is another story. See the Debian glibc patches -repository for details. diff --git a/open_issues/gcc/pie.mdwn b/open_issues/gcc/pie.mdwn new file mode 100644 index 00000000..a4598d1e --- /dev/null +++ b/open_issues/gcc/pie.mdwn @@ -0,0 +1,40 @@ +[[!meta copyright="Copyright © 2012 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="Position-Independent Executables"]] + +[[!tag open_issue_gcc]] + + +# IRC, freenode, #debian-hurd, 2012-11-08 + + <pinotree> tschwinge: i'm not totally sure, but it seems the pie options + for gcc/ld are causing issues + <pinotree> namely, producing executables that sigsegv straight away + <tschwinge> pinotree: OK, I do remember some issues about these, too. + <tschwinge> Also for -pg. + <tschwinge> These have in common that they use different crt*.o files for + linking. + <tschwinge> Might well be there's some bugs there. + <pinotree> one way is to try the w3m debian build: the current build + configuration enables also pie, which in turns makes an helper executable + (mktable) sigsegv when invoked + <pinotree> if «,-pie» is appended to the DEB_BUILD_MAINT_OPTIONS variable + in debian/rules, pie is not added and the resulting mktable runs + correctly + + +## IRC, OFTC, #debian-hurd, 2012-11-09 + + <pinotree> youpi: ah, as i noted to tschwinge earlier, it seems -fPIE -pie + miscompile stuff + <youpi> uh + <pinotree> this causes the w3m build failure and (indirectly, due to elinks + built with -pie) aptitude diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn new file mode 100644 index 00000000..0ecc1228 --- /dev/null +++ b/open_issues/gccgo.mdwn @@ -0,0 +1,45 @@ +[[!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="Enable Google Go programming (GCC: gccgo)"]] + +[[!tag open_issue_gcc]] + +Make the [Google Go programming language](http://golang.org/) available on +GNU/Hurd in its [[GCC]] *gccgo* implementation, and enable Hurd-specific +features. + +There is a [[!FF_project 263]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/gccgo feeds=no]] + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in the Google Go programming language. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/gdb-heap.mdwn b/open_issues/gdb-heap.mdwn new file mode 100644 index 00000000..75c31bbe --- /dev/null +++ b/open_issues/gdb-heap.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_gdb]] + +Might be interesting to have a look at +[*gdb-heap*](https://fedorahosted.org/gdb-heap/) with respect to our +long-lived [[hurd/translator]] processes. diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn new file mode 100644 index 00000000..f5daff48 --- /dev/null +++ b/open_issues/gdb.mdwn @@ -0,0 +1,315 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 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_gdb]] + +Here's what's to be done for maintaining GNU GDB. + +[[!toc levels=2]] + + +# [[General information|/gdb]] + + +# [[Sources|source_repositories/gdb]] + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master +-i +/^commit |^merge:|^---$|hurd|linux|nacl|nptl|glibc|gs:|gnu-nat|i386gnu + +--> + +Last reviewed up to the [[Git mirror's ded7dfe6274b281d92a6ed76cedf29d06c918dec +(2012-12-10) sources|source_repositories/gdb]]. + + * Globally + + * a.out, COFF, PE image support and 64 bit support are not interesting. + + * In the testsuites, `.exp` and `.d` files very likely should not only + care for `*-*-linux*`, but also `*-*-gnu*`. (If the need to be + conditionalized like this at all.) + + * `bfd/` + + See [[binutils]]. + + * `libdecnumber/` + + Should/can probably align to GNU/Linux. + + * Have a look at config/i386/i386gnu.mh. + + * configure.tgt + + * glibc-tdep et al. also for GNU/Hurd? + + * [[gdbserver]] + + * 82763a3d329b0d342d0273941b1521be9ef0c604 »MODIFIED is unknown, pass it as + true.« + + * Configure so that Debian system's `/usr/lib/debug/[...]` will be loaded + automatically. + + +# Build + +Here's a log of a GDB build run; this is from our [[Git +repository|source_repositories/gdb]]'s `tschwinge/Ferry_Tagscherer` branch, +commit ded7dfe6274b281d92a6ed76cedf29d06c918dec (2012-12-10), run on +kepler.SCHWINGE and coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../Ferry_Tagscherer/configure --prefix="$PWD".install SHELL=/bin/dash CC=gcc-4.6 CXX=g++-4.6 --disable-werror 2>&1 | tee log_build + [...] + $ make 2>&1 | tee log_build_ + [...] + +Different hosts may default to different shells and compiler versions; thus +harmonized. + +There are several occurences of *error: dereferencing type-punned pointer will +break strict-aliasing rules* in the MIG-generated stub files; thus no `-Werror` +until that is resolved ([[strict_aliasing]]). + +This takes up around 200 MiB and needs roughly 7 min on kepler.SCHWINGE and 23 +min on coulomb.SCHWINGE. + +<!-- + + $ (make && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && make -k check 2>&1 | tee log_test + +--> + + +## Analysis + +x86 GNU/Linux' and GNU/Hurd's configurations are slightly different, thus mask +out most of the differences that are due to GNU/Linux supporting more core file +formats and more emulation vectors. + + $ toolchain/logs/process gdb build + + * Why do we specify `-D_GNU_SOURCE`, and GNU/Linux doesn't? + + * GNU/Linux: `gdb/symfile-mem.c` for vDSO. + + * GNU/Linux: `gdb/i386-nat.c` for hardware breakpoints, etc. -- we should + probably use that, too. Related to Samuel's Hurd GDB patch? + + * `gdb/gnu-nat.c` + + gnu-nat.c: In function 'proc_set_exception_port': + gnu-nat.c:409:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat] + gnu-nat.c: In function 'proc_steal_exc_port': + gnu-nat.c:449:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat] + gnu-nat.c:470:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat] + gnu-nat.c: In function 'make_proc': + gnu-nat.c:583:7: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat] + gnu-nat.c:586:7: warning: format '%d' expects argument of type 'int', but argument 8 has type 'mach_port_t' [-Wformat] + gnu-nat.c: In function 'inf_set_pid': + gnu-nat.c:761:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'task_t' [-Wformat] + gnu-nat.c: In function 'inf_validate_procs': + gnu-nat.c:1085:6: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat] + gnu-nat.c: In function 'inf_signal': + gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat] + gnu-nat.c:1349:4: warning: format '%d' expects argument of type 'int', but argument 8 has type 'thread_t' [-Wformat] + gnu-nat.c: In function 'S_exception_raise_request': + gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'thread_t' [-Wformat] + gnu-nat.c:1668:3: warning: format '%d' expects argument of type 'int', but argument 8 has type 'task_t' [-Wformat] + gnu-nat.c:1705:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat] + gnu-nat.c:1711:8: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat] + gnu-nat.c: In function 'do_mach_notify_dead_name': + gnu-nat.c:1762:3: warning: format '%d' expects argument of type 'int', but argument 7 has type 'mach_port_t' [-Wformat] + gnu-nat.c: In function 'gnu_write_inferior': + gnu-nat.c:2383:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat] + gnu-nat.c:2393:8: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'vm_address_t' [-Wformat] + gnu-nat.c: In function 'steal_exc_port': + gnu-nat.c:2864:5: warning: format '%d' expects argument of type 'int', but argument 2 has type 'mach_port_t' [-Wformat] + + + * fe19822761b4635f392875a186e48af446b40f41..7a63e9515491f21eaf07301df87d389def20e317): + + `-Wmissing-prototypes` + + gnu-nat.c: At top level: + gnu-nat.c:643:1: warning: no previous prototype for 'make_inf' [] + gnu-nat.c: At top level: + gnu-nat.c:879:1: warning: no previous prototype for 'inf_set_traced' [] + gnu-nat.c:980:1: warning: no previous prototype for 'inf_port_to_thread' [] + gnu-nat.c: At top level: + gnu-nat.c:1748:1: warning: no previous prototype for 'inf_task_died_status' [] + gnu-nat.c: At top level: + gnu-nat.c:2273:1: warning: no previous prototype for 'gnu_read_inferior' [] + gnu-nat.c:2319:1: warning: no previous prototype for 'gnu_write_inferior' [] + gnu-nat.c: At top level: + gnu-nat.c:3415:1: warning: no previous prototype for '_initialize_gnu_nat' [] + notify_S.c:305:24: warning: no previous prototype for 'notify_server' [] + notify_S.c:341:28: warning: no previous prototype for 'notify_server_routine' [] + process_reply_S.c:343:24: warning: no previous prototype for 'process_reply_server' [] + process_reply_S.c:379:28: warning: no previous prototype for 'process_reply_server_routine' [] + msg_reply_S.c:165:24: warning: no previous prototype for 'msg_reply_server' [] + msg_reply_S.c:201:28: warning: no previous prototype for 'msg_reply_server_routine' [] + exc_request_S.c:157:24: warning: no previous prototype for 'exc_server' [] + exc_request_S.c:193:28: warning: no previous prototype for 'exc_server_routine' [] + + * `dlopen`/`-ldl` + + -checking for library containing dlopen... none required + +checking for library containing dlopen... -ldl + + * `O_NOFOLLOW` + + First seen in + 20f498edfd7e57d3297febcf9c7c7d667cc74239..69a5e2b022c7d15ec4c7c49e6f53a8d924d3b72b: + + -checking for working fcntl.h... yes + +checking for working fcntl.h... no (bad O_NOFOLLOW) + + [[!taglink open_issue_glibc]]? + + * Why does GNU/Linux have an additional `-ldl -rdynamic` when linking `gdb`? + + +# Install + + $ make install 2>&1 | tee log_install + [...] + +This takes up around 50 MiB, and needs roughly 1 min on kepler.SCHWINGE and 2 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gdb install + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + + +# Testsuite + + $ make -k check + [...] + +This needs roughly 14 min on kepler.SCHWINGE and 110 min on coulomb.SCHWINGE. + +When running `make -k check 2>&1 | tee log_test`, at the end of the testsuite +the `tee` process does not terminate if there are still stray leftover +processes that [have their stdout/stderr +open](http://sourceware.org/ml/gdb-patches/2012-10/msg00489.html). `kill`ing +these (`SIGKILL` may be needed), makes the `tee` process terminate, too. On +GNU/Hurd, these generally are `gdb.multi/watchpoint-multi`, and an unknown +(`?`) one ("57 PIDs before" `expect [...] gdb.cp`). + + +## Analysis + + $ toolchain/logs/process gdb test + + * Disabled + + * `gdb.base/readline.exp` + + [[term_blocking]] issue. + + * `gdb.base/sigall.exp` + + From `send signal TSTP` on, all FAIL running into timeouts. + + * `gdb.python/py-inferior.exp` (mostly disabled) + + Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.exp ... + [...] + python print 'result =', i0.was_attached + result = False + (gdb) PASS: gdb.python/py-inferior.exp: test Inferior.was_attached + python print i0.threads () + (<gdb.InferiorThread object at 0x61170>, <gdb.InferiorThread object at 0x61160>) + (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads + break check_threads + Breakpoint 2 at 0x8048869: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 61. + (gdb) continue + Continuing. + [New Thread 25670.6] + [New Thread 25670.7] + [New Thread 25670.8] + [New Thread 25670.9] + [New Thread 25670.10] + [New Thread 25670.11] + [New Thread 25670.12] + [New Thread 25670.13] + + Breakpoint 2, check_threads (barrier=0x15ff144) at ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c:61 + 61 pthread_barrier_wait (barrier); + (gdb) PASS: gdb.python/py-inferior.exp: continue to breakpoint: cont to check_threads + python print len (i0.threads ()) + 10 + (gdb) FAIL: gdb.python/py-inferior.exp: test Inferior.threads 2 + break 28 + Breakpoint 3 at 0x80487c2: file ../../../Ferry_Tagscherer/gdb/testsuite/gdb.python/py-inferior.c, line 28. + (gdb) continue + Continuing. + FAIL: gdb.python/py-inferior.exp: continue to breakpoint: cont to Break here. (timeout) + python addr = gdb.selected_frame ().read_var ('str') + FAIL: gdb.python/py-inferior.exp: read str address (timeout) + [All following tests FAIL with timeout.] + FAIL: gdb.python/py-inferior.exp: Switch to first inferior (timeout) + remove-inferiors 3 + FAIL: gdb.python/py-inferior.exp: Remove second inferior (timeout) + + At this point, the system hangs; no new processes can be spawned, so + perhaps an issue with the exec server. + + * `UNSUPPORTED: gdb.threads/ia64-sigill.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/ia64-sigill.c: unrecognized error` + + ../../../master/gdb/testsuite/gdb.threads/ia64-sigill.c:29:24: fatal error: asm/unistd.h: No such file or directory + + * `UNSUPPORTED: gdb.threads/multi-create.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/multi-create.c: unrecognized error` + ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'create_function': + ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) + ../../../master/gdb/testsuite/gdb.threads/multi-create.c:46:39: note: each undeclared identifier is reported only once for each function it appears in + ../../../master/gdb/testsuite/gdb.threads/multi-create.c: In function 'main': + ../../../master/gdb/testsuite/gdb.threads/multi-create.c:73:39: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) + + * `UNSUPPORTED: gdb.threads/staticthreads.exp: Couldn't compile ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: unrecognized error` + + ../../../master/gdb/testsuite/gdb.threads/staticthreads.c: In function 'main': + ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: error: 'PTHREAD_STACK_MIN' undeclared (first use in this function) + ../../../master/gdb/testsuite/gdb.threads/staticthreads.c:52:37: note: each undeclared identifier is reported only once for each function it appears in + + * `UNSUPPORTED: gdb.threads/watchpoint-fork.exp: parent: multithreaded: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-parent.c: unrecognized error` + + ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:29:24: fatal error: asm/unistd.h: No such file or directory + + * `UNSUPPORTED: gdb.threads/create-fail.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/create-fail.c: unrecognized error` + + [...]/gdb.threads/create-fail.c:77: undefined reference to `pthread_attr_setaffinity_np' + [...]/gdb.threads/create-fail.c:83: undefined reference to `pthread_create' + + * `UNSUPPORTED: gdb.threads/siginfo-threads.exp: Couldn't compile ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/siginfo-threads.c: unrecognized error` + + ../../../Ferry_Tagscherer/gdb/testsuite/gdb.threads/sigstep-threads.c:22:24: fatal error: asm/unistd.h: No such file or directory + + * `UNTESTED: gdb.base/longest-types.exp: longest-types.exp` + + ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/longest-types.c:20:8: error: size of array 'buf' is too large + + Also on GNU/Linux. + +TODO. diff --git a/open_issues/gdb/gdbserver.mdwn b/open_issues/gdb/gdbserver.mdwn new file mode 100644 index 00000000..fe239bbc --- /dev/null +++ b/open_issues/gdb/gdbserver.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2012 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_gdb]] + +Needs porting. Can probably use/share most code from GDB proper. + +# Miscellaneous Issues + + * ``m addr,length'` + + What is `errno`? Is is *the* `errno`? If yes, of the system GDB is + running on, or the system gdbserver is running on? Clarify documentation. diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn new file mode 100644 index 00000000..4e4f2ea0 --- /dev/null +++ b/open_issues/gdb_attach.mdwn @@ -0,0 +1,41 @@ +[[!meta copyright="Copyright © 2012 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="GDB: attach"]] + +[[!tag open_issue_gdb]] + + +# [[gdb_thread_ids]] + + +# IRC, freenode, #hurd, 2012-06-30 + + <braunr> hm, gdb isn't able to determine which thread is running when + attaching to a process + + +# IRC, freenode, #hurd, 2012-07-02 + + <braunr> woah, now that's a weird message ! + <braunr> when using gdb on a hanged ext2fs : + <braunr> Pid 938 has an additional task suspend count of 1; clear it? (y or + n) + <braunr> when hanged, gdb thinks the target task is already being debugged + :/ + <braunr> no wonder why it's completely stuck + <braunr> hm, the task_suspend might actually be the crash-dump-core server + attempting to create the core :/ + <braunr> hm interesting, looks like a problem with the + diskfs_catch_exception macro + <pinotree> braunr: what's up with it? + <braunr> pinotree: it uses setjmp + <braunr> hm random corruptions :/ + <braunr> definitely looks like a concurrency problem diff --git a/open_issues/gdb_catch_syscall.mdwn b/open_issues/gdb_catch_syscall.mdwn new file mode 100644 index 00000000..366c88f5 --- /dev/null +++ b/open_issues/gdb_catch_syscall.mdwn @@ -0,0 +1,18 @@ +[[!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="GDB: catch syscall"]] + + (gdb) catch syscall + The feature 'catch syscall' is not supported on this architeture yet. + +[[!tag open_issue_gdb]] + +Perhaps can ``marry'' that one with [[hurd/debugging/rpctrace]]? diff --git a/open_issues/gdb_gcore.mdwn b/open_issues/gdb_gcore.mdwn new file mode 100644 index 00000000..69211ac0 --- /dev/null +++ b/open_issues/gdb_gcore.mdwn @@ -0,0 +1,26 @@ +[[!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 +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="GDB: gcore"]] + +[[!tag open_issue_gdb]] + +GDB's `gcore` command doesn't work / needs to be implemented / ported in GDB: + + tschwinge@flubber:~ $ gcore 8371 + [New Thread 8371.1] + [New Thread 8371.2] + [New Thread 8371.3] + /media/data/home/tschwinge/core.cA0ICY:2: Error in sourced command file: + Undefined command: "gcore". Try "help". + gcore: failed to create core.8371 + +If someone is working in this area, they may want to port +<http://code.google.com/p/google-coredumper/>, too. diff --git a/open_issues/gdb_noninvasive_mode_new_threads.mdwn b/open_issues/gdb_noninvasive_mode_new_threads.mdwn new file mode 100644 index 00000000..9b3992f4 --- /dev/null +++ b/open_issues/gdb_noninvasive_mode_new_threads.mdwn @@ -0,0 +1,15 @@ +[[!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_gdb]] + +Debugging a translator. `gdb binary`. `set noninvasive on`. `attach [PID]`. +Translator does some work. GDB doesn't notice new threads. `detach`. `attach +[PID]` -- now new threads are visible. diff --git a/open_issues/gdb_qemu_debugging_gnumach.mdwn b/open_issues/gdb_qemu_debugging_gnumach.mdwn new file mode 100644 index 00000000..d3105f50 --- /dev/null +++ b/open_issues/gdb_qemu_debugging_gnumach.mdwn @@ -0,0 +1,19 @@ +[[!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_gdb open_issue_gnumach]] + +\#hurd, freenode, June (?) 2010 + + <jkoenig> is there a way to get gdb to map addresses as required when debugging mach with qemu ? + <jkoenig> I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... + <youpi> jkoenig: I haven't found a way + <youpi> I'm mostly using the internal kdb + diff --git a/open_issues/gdb_signal_thread_bt.mdwn b/open_issues/gdb_signal_thread_bt.mdwn new file mode 100644 index 00000000..74065922 --- /dev/null +++ b/open_issues/gdb_signal_thread_bt.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2009 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="GDB: bt on the signal thread"]] + +[[!tag open_issue_gdb]] + + (gdb) r + Starting program: /media/data/home/tschwinge/tmp/h + [New Thread 26731.15] + + Breakpoint 1, 0x08048236 in main () + (gdb) info threads + 5 Thread 26731.15 0x080a97fc in mach_msg_trap () + * 4 Thread 26731.14 0x08048236 in main () + (gdb) thread 5 + [Switching to thread 5 (Thread 26731.15)]#0 0x080a97fc in mach_msg_trap () + (gdb) bt + #0 0x080a97fc in mach_msg_trap () + #1 0x080a272e in mach_msg () + #2 0x080a9934 in mach_msg_server_timeout () + #3 0x080a99ff in mach_msg_server () + #4 0x080a327e in _hurd_msgport_receive () + Cannot access memory at address 0x1012000 diff --git a/open_issues/gdb_thread_ids.mdwn b/open_issues/gdb_thread_ids.mdwn index eeb67f30..c04a10ee 100644 --- a/open_issues/gdb_thread_ids.mdwn +++ b/open_issues/gdb_thread_ids.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 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]]."]]"""]] [[!meta title="GDB: thread ids"]] @@ -19,3 +20,12 @@ GNU GDB's Pedro Alves: > was, if gnu-nat.c couldn't be using the port's id as thread ids instead of a > locally auto-generated number. Maybe the thread id of the main thread would > be preserved across execs this way + + +Also see [[thread numbering of ps and GDB]]. + +--- + +`attach` to a multi-threaded process. See threads 1 to 5. `detach`. `attach` +again -- thread numbers continue where they stopped last time: now they're +threads 6 to 10. diff --git a/open_issues/git-core-2.mdwn b/open_issues/git-core-2.mdwn index 84e002b5..2d8ad96b 100644 --- a/open_issues/git-core-2.mdwn +++ b/open_issues/git-core-2.mdwn @@ -1,17 +1,25 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 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]]."]]"""]] -[[!meta title="Hiccup of git clone when checking out files"]] +[[!meta title="Hiccups of Git"]] [[!tag open_issue_porting]] +[[!toc]] + + +# Log + +December, 2008. + On the otherwise-idle flubber: $ git clone git://sources.redhat.com/git/glibc.git @@ -40,7 +48,7 @@ On the otherwise-idle flubber: -rw-r--r-- 1 tschwinge tschwinge 0 2008-12-15 15:49 localedata/charmaps/IBM862 So these files are indeed of zero-length in the checked-out tree. Is this -git's fault or something else's? +Git's fault or something else's? Fixing this situation is easy enough: @@ -48,3 +56,135 @@ Fixing this situation is easy enough: $ git status # On branch master nothing to commit (working directory clean) + +Still seen on 2010-03-16. + +--- + +A very similar issue, seen on 2010-11-17. The working tree had a lot of +differences to HEAD. + + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/darwin.h' (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/iq2000/iq2000.md' (Interrupted system call) + error: git checkout-index: unable to create file gcc/config/lm32/lm32.c (File exists) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ ls -l gcc/config/iq2000/iq2000.md gcc/config/lm32/lm32.c + ls: cannot access gcc/config/iq2000/iq2000.md: No such file or directory + -rw-r--r-- 1 tschwinge tschwinge 32159 Nov 17 19:09 gcc/config/lm32/lm32.c + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: git checkout-index: unable to create file gcc/fortran/expr.c (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: git checkout-index: unable to create file gcc/config/sol2.h (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + error: unable to unlink old 'gcc/config/i386/i386.c' (Interrupted system call) + Checking out files: 100% (1149/1149), done. + fatal: Could not reset index file to revision 'HEAD'. + tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD + Checking out files: 100% (1149/1149), done. + HEAD is now at fe3e43c Merge commit 'refs/top-bases/hurd/master' into hurd/master + +--- + +2010-12-22, grubber: + + $ git remote update + Fetching savannah + remote: Counting objects: 582331, done. + remote: Compressing objects: 100% (124133/124133), done. + remote: Total 582331 (delta 460856), reused 578352 (delta 457598) + Receiving objects: 100% (582331/582331), 525.15 MiB | 204 KiB/s, done. + fatal: cannot pread pack file: Interrupted system call + fatal: index-pack failed + error: Could not fetch savannah + +--- + +2011-06-10, coulomb.SCHWINGE, checking out [[binutils]]' master branch, +starting from an empty working directory (after an external `git push`): + + $ git checkout -f + fatal: cannot create directory at 'gas/testsuite/gas/bfin': Interrupted system call + $ git checkout -f + error: unable to create file gas/testsuite/gas/i386/ilp32/x86-64-sse4_1-intel.d (File exists) + warning: unable to unlink gas/testsuite/gas/m68k-coff: Operation not permitted + fatal: cannot create directory at 'gas/testsuite/gas/m68k-coff': Operation not permitted + $ git checkout -f + error: unable to create file gas/testsuite/gas/h8300/h8300.exp (File exists) + error: unable to create file gas/testsuite/gas/i386/x86-64-addr32-intel.d (File exists) + error: unable to create file gas/testsuite/gas/ia64/secname.d (File exists) + error: unable to create file gas/testsuite/gas/m68k/pr11676.s (File exists) + Checking out files: 100% (12315/12315), done. + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: gas/testsuite/gas/h8300/h8300.exp + # modified: gas/testsuite/gas/i386/x86-64-addr32-intel.d + # modified: gas/testsuite/gas/ia64/secname.d + # modified: gas/testsuite/gas/m68k/pr11676.s + # + no changes added to commit (use "git add" and/or "git commit -a") + $ rm gas/testsuite/gas/h8300/h8300.exp gas/testsuite/gas/i386/x86-64-addr32-intel.d gas/testsuite/gas/ia64/secname.d gas/testsuite/gas/m68k/pr11676.s + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + + +# Analysis + +2011-06-13 + +Running `git checkout -f` under GDB: + + error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse-check.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i386/x86-64-sse4_1.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/ppc/astest.d (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (File exists) + warning: unable to unlink include/cgen: Operation not permitted + fatal: cannot create directory at 'include/cgen': Operation not permitted + +Again: + + error: git checkout-index: unable to create file gas/config/te-vxworks.h (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/cris/string-1.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/d10v/warning-019.s (File exists) + error: git checkout-index: unable to create file gas/testsuite/gas/i860/dual03.s (File exists) + error: git checkout-index: unable to create file ld/testsuite/ld-mmix/sec-7a.s (File exists) + warning: unable to unlink ld/testsuite/ld-powerpc: Operation not permitted + fatal: cannot create directory at 'ld/testsuite/ld-powerpc': Operation not permitted + +And: [[git_duplicated_content]]. + +All these (very likely) have the same root cause: `SA_RESTART` restarting too +much. + +With `git checkout`, Git uses in progress.c a SIGALRM handler (`SA_RESTART`; +invoked every second via `setitimer(ITIMER_REAL)`) to display status messages: +*x % already checked out*. + +To avoid the status update signals every second, in +`[git]/progress.c:start_progress_delay` we can just return `NULL` (manually in +GDB, for example), then both the *error: git checkout-index* and the +[[duplicated content|git_duplicated_content]] issues go away. + +I'm guessing that when returning from a `SA_RESTART` signal handler, too much +of the \`\`syscall''s is being restarted. For example, if a file has already +been created, the restarted creation attempt would fail: *File exists*. If +data has been written, it might get written again (duplication issue). Then, +there are cases where `unlink` apparently returns EINTR, which is not kosher +either. Etc. + +Do we have problems with `SA_RESTART` vs. the atomicity of our syscall-alikes? diff --git a/open_issues/git_duplicated_content.mdwn b/open_issues/git_duplicated_content.mdwn new file mode 100644 index 00000000..cbc171a7 --- /dev/null +++ b/open_issues/git_duplicated_content.mdwn @@ -0,0 +1,131 @@ +[[!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_porting]] + + $ git-new-workdir ~/tmp/binutils/git /media/hd1s1/tmp/master master + error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call) + Checking out files: 100% (12315/12315), done. + Already on 'master' + $ cd /media/hd1s1/tmp/master + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d + # + no changes added to commit (use "git add" and/or "git commit -a") + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + +([[Git issue|git-core-2]] is known.) + + $ git-new-workdir ~/tmp/binutils/git /media/hd1s2/tmp/master master + error: unable to create file bfd/elf32-dlx.c (Interrupted system call) + error: unable to create file bfd/sunos.c (Interrupted system call) + error: unable to create file gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d (Interrupted system call) + error: unable to create file gas/testsuite/gas/mmix/regx-op.d (Interrupted system call) + error: unable to create file gas/testsuite/gas/tic6x/reloc-bad-4.s (Interrupted system call) + error: unable to create file gold/testsuite/script_test_2.t (Interrupted system call) + error: unable to create file ld/testsuite/ld-mmix/loc7m.d (Interrupted system call) + error: unable to create file ld/testsuite/ld-powerpc/tlsexe.g (Interrupted system call) + Checking out files: 100% (12315/12315), done. + Already on 'master' + $ cd /media/hd1s2/tmp/master + $ git status + # On branch master + # Changes not staged for commit: + # (use "git add <file>..." to update what will be committed) + # (use "git checkout -- <file>..." to discard changes in working directory) + # + # modified: bfd/elf32-dlx.c + # modified: bfd/sunos.c + # modified: gas/testsuite/gas/arm/attr-mfpu-vfpv3-d16.d + # modified: gas/testsuite/gas/mmix/regx-op.d + # modified: gas/testsuite/gas/tic6x/reloc-bad-4.s + # modified: gold/testsuite/script_test_2.t + # modified: ld/testsuite/ld-mmix/loc7m.d + # modified: ld/testsuite/ld-powerpc/tlsexe.g + # + no changes added to commit (use "git add" and/or "git commit -a") + $ git checkout -f + $ git status + # On branch master + nothing to commit (working directory clean) + +Now you'd expect these directories to have identical content, but: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff + $ ls -l /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + $ grep '^[^ @+-]' < /tmp/diff + diff -x .git -ru /media/hd1s1/tmp/master//ld/configure /media/hd1s2/tmp/master//ld/configure + +(Note that this isn't a file that Git had issues with.) + +Try again: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff_ + $ ls -l /tmp/diff* + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_ + $ cmp /tmp/diff{,_}; echo $? + 0 + +At least it's consistent. Force a reload: + + # settrans -ag /media/hd1s1 + # settrans -ag /media/hd1s2 + +Try again: + + $ diff -x .git -ru /media/hd1s{1,2}/tmp/master/ > /tmp/diff__ + $ ls -l /tmp/diff* + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:12 /tmp/diff + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:17 /tmp/diff_ + -rw-r--r-- 1 thomas thomas 613677 10. Jun 19:30 /tmp/diff__ + $ cmp /tmp/diff{,__}; echo $? + 0 + +Consistent; thus very likely corrupt on-disk. + +After a few tries, the pattern generally is that for the files where there are +differences, once the file regularely ends, its content appears once more. +That is, the files' content appears once (regularely), and then the same again. + +Some more copying: + + $ (cd /media/hd1s1/tmp/ && cp -a master master_) + $ (cd /media/hd1s2/tmp/ && cp -a master master_) + $ diff -x .git -ru /media/hd1s1/tmp/master{,_}/ > /tmp/diff1 + $ diff -x .git -ru /media/hd1s2/tmp/master{,_}/ > /tmp/diff2 + $ ls -l /tmp/diff{1,2} + -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff1 + -rw-r--r-- 1 thomas thomas 0 10. Jun 19:46 /tmp/diff2 + +No further difference. + +--- + + $ git-new-workdir git master master + $ diff -x .git -ur tar_master/ master/ > master.diff + + $ rm -rf ar_master* && (cd git/ && git archive master) | (mkdir ar_master && cd ar_master/ && tar -x) && diff -x .git -ru tar_master/ ar_master/ > ar_master.diff; ls -l ar_master.diff + $ (cd git/ && git archive master) | md5sum + +--- + +2011-06-13 + +-> [[git-core-2]] diff --git a/open_issues/git_nfs_mmap.mdwn b/open_issues/git_nfs_mmap.mdwn new file mode 100644 index 00000000..21067022 --- /dev/null +++ b/open_issues/git_nfs_mmap.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2011, 2012 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_porting]] + + $ git-new-workdir /media/kepler-data/home/thomas/tmp/source/binutils/git master master + fatal: Out of memory? mmap failed: No such device + $ echo $? + 128 + $ showtrans /media/kepler-data + /hurd/nfs kepler.schwinge.homeip.net:/media/data + +With `sh -x`: + + [...] + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/remotes master/.git/remotes + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/rr-cache master/.git/rr-cache + + ln -s /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/svn master/.git/svn + + cd master + + cp /media/kepler-data/home/thomas/tmp/source/binutils/git/.git/HEAD .git/HEAD + + git checkout -f master + fatal: Out of memory? mmap failed: No such device + +As one can easily guess (and confirm with [[hurd/debugging/rpctrace]]), `git` +tries to [[glibc/mmap]] a file via the [[hurd/translator/nfs]] translator, this +fails, and it isn't prepared to cope with that: + + [...] + 88->dir_lookup (".git/objects/pack/pack-37ca560e7877fa0cc6e5ddcd556aa73e5a3e3f40.idx" 2049 0) = 0 3 "/media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37" (null) + 62->dir_lookup ("media/kepler-data/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37c" 2049 0) = 0 1 "/home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5" 61 + 61->dir_lookup ("home/thomas/tmp/source/binutils/git/.git/objects/pack/pack-37ca560e7877fa0cc6e5d" 2049 0) = 0 1 "" 84 + task3741-> 3206 (pn{ 33}) = 0 + 84->term_getctty () = 0xfffffed1 ((ipc/mig) bad request message ID) + 84->io_stat_request () = 0 {1 704 0 36308992 0 0 -1 33060 1 1000 1000 4712 0 1307711395 0 1307657003 0 1307657003 0 4096 16 0 1000 0 0 100663296 1836017780 29537 0 0 0 0} + 84->io_map_request () = 0x4000002d (Operation not supported) + 84->io_map_request () = 0x4000002d (Operation not supported) + 76->io_write_request ("fatal: Out of memory? mmap failed: No such device + " -1) = 0 50 + 64->proc_mark_exit_request (32768 0) = 0 + task3741-> 2008 () = 0 + Child 3741 exited with 128 + +This is the [[libnetfs: `io_map`|open_issues/libnetfs_io_map]] issue. + +There is a `NO_MMAP` conditional in Git's source code, but it is a compile-time +conditional. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn new file mode 100644 index 00000000..e2b968c9 --- /dev/null +++ b/open_issues/glibc.mdwn @@ -0,0 +1,1712 @@ +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 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]] + +Here's what's to be done for maintaining glibc. + +[[!toc levels=2]] + + +# [[General information|/glibc]] + + +# [[Sources|source_repositories/glibc]] + + +# [[Debian]] Cheat Sheet + + +# Configuration + +<!-- + +git checkout reviewed +git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master +-i +/^commit |^Merge:|^---$|hurd|linux|gs:|__ASSUME + +--> + +Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8 +(2012-11-03) sources|source_repositories/glibc]]. + + * `t/hurdsig-fixes` + + hurdsig.c: In function '_hurd_internal_post_signal': + hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized] + hurdsig.c:1168:12: note: 'pending' was declared here + + * `t/host-independency` + + [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id + "20120525202732.GA31088@intel.com"]], commit + 918b56067a444572f1c71b02f18255ae4540b043. [[!GCC_PR 53183]], GCC commit + c05436a7e361b8040ee899266e15bea817212c37. + + * `t/sysvshm` + + ../sysdeps/mach/hurd/shmat.c: In function '__shmat': + ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] + ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive': + ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable] + ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized] + ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized] + + * [[`t/tls`|t/tls]] + + * [[`t/tls-threadvar`|t/tls-threadvar]] + + * t/verify.h + + People didn't like this too much. + + Other examples: + + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert` + + * [[toolchain/cross-gnu]], without `--disable-multi-arch` + + i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...] + ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages: + ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string' + + Might simply be a missing patch(es) from master. + + * `--disable-multi-arch` + + IRC, freenode, #hurd, 2012-11-22 + + <pinotree> tschwinge: is your glibc build w/ or w/o multiarch? + <tschwinge> pinotree: See open_issues/glibc: --disable-multi-arch + <pinotree> ah, because you do cross-compilation? + <tschwinge> No, that's natively. + <tschwinge> There is also a not of what happened in cross-gnu when I + enabled multi-arch. + <tschwinge> No idea whether that's still relevant, though. + <pinotree> EPARSE + <tschwinge> s%not%note + <tschwinge> Better? + <pinotree> yes :) + <tschwinge> As for native builds: I guess I just didn't (want to) play + with it yet. + <pinotree> it is enabled in debian since quite some time, maybe other + i386/i686 patches (done for linux) help us too + <tschwinge> I though we first needed some CPU identification + infrastructe before it can really work? + <tschwinge> I thought [...]. + <pinotree> as in use the i686 variant as runtime automatically? i guess + so + <tschwinge> I thought I had some notes about that, but can't currently + find them. + <tschwinge> Ah, I probably have been thinking about open_issues/ifunc + and open_issues/libc_variant_selection. + + * --build=X + + `long double` test: due to `cross_compiling = maybe` wants to execute a + file, which fails. Thus `--build=X` has to be set. + + * Check what all these are: + + running configure fragment for sysdeps/mach/hurd + checking Hurd header version... ok + running configure fragment for sysdeps/mach + checking for i586-pc-gnu-mig... i586-pc-gnu-mig + checking for mach/mach_types.h... yes + checking for mach/mach_types.defs... yes + checking for task_t in mach/mach_types.h... task_t + checking for thread_t in mach/mach_types.h... thread_t + checking for creation_time in task_basic_info... yes + checking for mach/mach.defs... yes + checking for mach/mach4.defs... yes + checking for mach/clock.defs... no + checking for mach/clock_priv.defs... no + checking for mach/host_priv.defs... no + checking for mach/host_security.defs... no + checking for mach/ledger.defs... no + checking for mach/lock_set.defs... no + checking for mach/processor.defs... no + checking for mach/processor_set.defs... no + checking for mach/task.defs... no + checking for mach/thread_act.defs... no + checking for mach/vm_map.defs... no + checking for mach/memory_object.defs... yes + checking for mach/memory_object_default.defs... yes + checking for mach/default_pager.defs... yes + checking for mach/i386/mach_i386.defs... yes + checking for egrep... grep -E + checking for host_page_size in mach_host.defs... no + checking for mach/machine/ndr_def.h... no + checking for machine/ndr_def.h... no + checking for i386_io_perm_modify in mach_i386.defs... yes + checking for i386_set_gdt in mach_i386.defs... yes + checking whether i586-pc-gnu-mig supports the retcode keyword... yes + + * `sysdeps/i386/stackguard-macros.h` + + See [[t/tls|t/tls]]. + + * Verify 77c84aeb81808c3109665949448dba59965c391e against + `~/shared/glibc/make_TAGS.patch`. + + * `HP_SMALL_TIMING_AVAIL` not defined anywhere. + + * Unify `CPUCLOCK_WHICH` stuff in `clock_*` files. + + * Not all tests are re-run in a `make -k tests; make tests-clean; make -k + tests` cycle. For example, after `make tests-clean`: + + $ find ./ -name \*.out + ./localedata/tst-locale.out + ./localedata/sort-test.out + ./localedata/de_DE.out + ./localedata/en_US.out + ./localedata/da_DK.out + ./localedata/hr_HR.out + ./localedata/sv_SE.out + ./localedata/tr_TR.out + ./localedata/fr_FR.out + ./localedata/si_LK.out + ./localedata/tst-mbswcs.out + ./iconvdata/iconv-test.out + ./iconvdata/tst-tables.out + ./stdlib/isomac.out + ./posix/wordexp-tst.out + ./posix/annexc.out + ./posix/tst-getconf.out + ./elf/check-textrel.out + ./elf/check-execstack.out + ./elf/check-localplt.out + ./c++-types-check.out + ./check-local-headers.out + ./begin-end-check.out + + * `CPUCLOCK_WHICH`, `t/cpuclock` + + /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime': + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH' + /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH' + collect2: error: ld returned 1 exit status + make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1 + make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt' + make[1]: *** [rt/others] Error 2 + make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' + make: *** [all] Error 2 + + * Missing interfaces, amongst many more. + + Many more are missing, some of which have been announced in `NEWS`, others + typically haven't (like new flags to existing functions). Typically, + porters will notice missing functionaly. But in case you're looking for + something to work on, here's a list. + + `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`, + `CLOCK_REALTIME_ALARM`, `O_PATH`, + `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27, + b1b2aaf8eb9eed301ea8f65b96844568ca017f8b), + `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`) + `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`, + `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`, + `setns`, `sync_file_range` + + Check also the content of `gnu/stubs.h`, which lists all the functions + marked as stub which only return `ENOSYS`. + + * `chflags` + + Patch sent, [[!message-id "20120427012130.GZ19431@type.famille.thibault.fr"]]. + + IRC, OFTC, #debian-hurd, 2012-04-27: + + <Steap> Does anyone have any idea why int main(void) { return + chflags(); } will compile with gcc but not with g++ ? It says + that "chflags" was not declared in this scope. + <Steap> I get the same error on FreeBSD, but including sys/stat.h + makes it work + <Steap> Can't find a solution on Hurd though :/ + <youpi> the Hurd doesn't have chflags + <youpi> apparently linux neither + <youpi> what does it do? + <Steap> change flags :) + <Steap> Are you sure the Hurd does not have chflags ? Because gcc + does not complain + <youpi> there is no chflags function in /usr/include + <youpi> but what flags does it change? + <Steap> According to the FreeBSD manpage, it can set flags such as + UF_NODUMP, UF_IMMUTABLE etc. + <youpi> Hum, there is actually a chflags() definition + <youpi> but no declaration + <youpi> so actually chflags is supported, but the declaration was + forgotten + <youpi> probably because since linux doens't have it, it has never + been a problem up to now + <youpi> so I'd say ignore the error for now, we'll add the + declaration + + * `getcontext`/`setcontext` + + Needed for [[gccgo]]. + + IRC, freenode, #hurd, 2012-04-19: + + <gnu_srs> How much work/knowledge is needed to implement + getcontext/setcontext? + <gnu_srs> Any already implemented alternatives available? + <youpi> x86 registers knowledge, as well as unix signal masks + <youpi> there's the linux implementation that can be taken as an + exxample, but the signal part has to be rewritten + <gnu_srs> Well, it's a pity they are not implemented. That's the + remaining hurdle to get gccgo working :-( + <youpi> uh :/ + <gnu_srs> Everything builds, but the testsuite fails due to these + missing functions. + <gnu_srs> Regarding getcontext/setcontext they seem to be written + in assembly for linux but the code is not very long. + <gnu_srs> How much effort would it be to write something similar + for Hurd? Anybody fluent in asm? + <gnu_srs> And registers and signals. + <tschwinge> gnu_srs: Signals is the key thing -- everything else we + can probably just copy. I have never/not yet looked at it, + though. + <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in + one file: getcontext, setcontext, swapcontext, not makecontext. + <gnu_srs> Dunno how much assembly calls used though. + <gnu_srs> Hi, any preferences about implementing get/setcontext in + C or Asm? + <tschwinge> gnu_srs: I think these will have to be implemented in + assembly. Based on the Linux x86 variants. + + IRC, freenode, #hurd, 2012-04-20: + + <tschwinge> youpi: Your understanding of that is better than mine + -- the *context stuff can't be very useful at the moment, because + when the user changes uc_stack.ss_sp (which the glibc tests are + doing), we're losing access to the _hurd_threadvars. Correct? + <tschwinge> At least the getcontext test works, the other get a + SIGILL. + <tschwinge> others + <tschwinge> _hurd_threadvars issue is just guessing. + <youpi> tschwinge: yes, threadvars are on the stack + <youpi> threadvars is not much code, it should just work, but care + has to be taken on the libpthread/libthread side, which does some + initialization + <tschwinge> OK, that at least matches my understanding. + + * [[`mremap`|mremap]] + + * `futimesat` + + If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`. + + * `bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT` + + * `io/fcntl.h [__USE_ATFILE]` + + Do we support `AT_FDCWD` et al.? + (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.) + + * `MAP_POPULATE` (`mmap`, `sys/mman.h`) -- *Populate (prefault) + pagetables.* + + Some Linux kernel version, `mm/mmap.c`: + + if (vm_flags & VM_LOCKED) { + if (!mlock_vma_pages_range(vma, addr, addr + len)) + mm->locked_vm += (len >> PAGE_SHIFT); + } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK)) + make_pages_present(addr, addr + len); + return addr; + + Is only advisory, so can worked around with `#define MAP_POPULATE 0`, + 8069478040336a7de3461be275432493cc7e4c91. + + * `t/opendirat`: `opendirat` (`scandirat`, `scandirat64`) + + Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 + + 14d96785125abee5e9a49a1c3037f35a581750bd. + + * `madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP` + + [[glibc_madvise_vs_static_linking]]. + + * `msync` + + Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`. + + * `sys/epoll.h` + + Used by [[wayland]], for example. + + * `sys/eventfd.h` + + * `sys/inotify.h` + + * `sys/signalfd.h` + + * `sys/timerfd.h` + + * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51) + + * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`) + + IRC, freenode, #hurd, 2012-04-20: + + <pinotree> in glibc, we use the generic waitflags.h which, unlike + linux's version, does not define WEXITED, WNOWAIT, WSTOPPED, + WCONTINUED + <pinotree> should the generic bits/waitflags.h define them anyway, + since they are posix? + <youpi> well, we'd have to implement them anyway + <youpi> but otherwise, I'd say yes + <pinotree> sure, but since glibc headers should expose at least + everything declared by posix, i thought they should be defined + anyway + <youpi> that might bring bugs + <youpi> some applications might be #ifdefing them + <youpi> and break when they are defined but not working + <pinotree> i guess they would define them to 0, andd having them to + non-zero values shouldn't break them (since those values don't do + anything, so they would act as if they were 0.. or not?) + <youpi> no, I mean they would do something else, not define them to + 0 + <pinotree> like posix/tst-waitid.c, you mean? + <youpi> yes + + * `getconf` things + + IRC, freenode, #hurd, 2012-10-03 + + <pinotree> getconf -a | grep CACHE + <Tekk_> pinotree: I hate spoiling data, but 0 :P + <pinotree> had that feeling, but wanted to be sure -- thanks! + <Tekk_> http://dpaste.com/809519/ + <Tekk_> except for uhh + <Tekk_> L4 linesize + <Tekk_> that didn't have any number associated + <pinotree> weird + <Tekk_> I actually didn't even know that there was L4 cache + <pinotree> what do you get if you run `getconf + LEVEL4_CACHE_LINESIZE`? + <Tekk_> pinotree: undefined + <pinotree> expected, given the output above + + For specific packages: + + * [[octave]] + + * Create `t/cleanup_kernel-features.h`. + + * Add tests from Linux kernel commit messages for `t/dup3` et al. + + * In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of + `-DHAVE_SENDFILE` -- but we do have `sendfile`, too. + + Define `__ASSUME_SENDFILE` to 1 in `kernel-features.h`, if `sendfile` + works. + + * `/usr/include/pthread.h` overwrite issue + + `make`, after editing `nss/nss_db/db-initgroups.c`: + + [...] + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv' + make subdir=nss -C nss ..=../ others + make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h + /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied + make[2]: *** [/usr/include/pthread.h] Error 1 + make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss' + make[1]: *** [nss/others] Error 2 + make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker' + make: *** [all] Error 2 + + See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]]. Passing + `install_root=/INVALID` to `make`/`make check` is a cheap cure. For `make + install`, prepending an additional slash to `install_root` (that is, + `install_root=//[...]`) is enough to obfuscate the Makefile rules. + + * `sysdeps/unix/sysv/linux/syslog.c` + + * `fsync` on a pipe + + IRC, freenode, #hurd, 2012-08-21: + + <braunr> pinotree: i think gnu_srs spotted a conformance problem in + glibc + <pinotree> (only one?) + <braunr> pinotree: namely, fsync on a pipe (which is actually a + socketpair) doesn't return EINVAL when the "operation not supported" + error is returned as a "bad request message ID" + <braunr> pinotree: what do you think of this case ? + <pinotree> i'm far from an expert on such stuff, but seems a proper E* + should be returned + <braunr> (there also is a problem in clisp falling in an infinite loop + when trying to handle this, since it uses fsync inside the error + handling code, eww, but we don't care :p) + <braunr> basically, here is what clisp does + <braunr> if fsync fails, and the error isn't EINVAL, let's report the + error + <braunr> and reporting the error in turn writes something on the + output/error stream, which in turn calls fsync again + <pinotree> smart + <braunr> after the stack is exhausted, clisp happily crashes + <braunr> gnu_srs: i'll alter the clisp code a bit so it knows about our + mig specific error + <braunr> if that's the problem (which i strongly suspect), the solution + will be to add an error conversion for fsync so that it returns + EINVAL + <braunr> if pinotree is willing to do that, he'll be the only one + suffering from the dangers of sending stuff to the glibc maintainers + :p + <pinotree> that shouldn't be an issue i think, there are other glibc + hurd implementations that do such checks + <gnu_srs> does fsync return EINVAL for other OSes? + <braunr> EROFS, EINVAL + <braunr> fd is bound to a special file which does not + support synchronization. + <braunr> obviously, pipes and sockets don't + <pinotree> + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html + <braunr> so yes, other OSes do just that + <pinotree> now that you speak about it, it could be the failure that + the gnulib fsync+fdatasync testcase have when being run with `make + check` (although not when running as ./test-foo) + <braunr> hm we may not need change glibc + <braunr> clisp has a part where it defines a macro IS_EINVAL which is + system specific + <braunr> (but we should change it in glibc for conformance anyway) + <braunr> #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) || + defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA + ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV)) + <pinotree> i'd rather add nothing to clisp + <braunr> let's see what posix says + <braunr> EINVAL + <braunr> so right, we should simply convert it in glibc + <gnu_srs> man fsync mentions EINVAL + <braunr> man pages aren't posix, even if they are usually close + <gnu_srs> aha + <pinotree> i think checking for MIG_BAD_ID and EOPNOTSUPP (like other + parts do) will b enough + <pinotree> *be + <braunr> gnu_srs: there, it finished correctly even when piped + <gnu_srs> I saw that, congrats! + <braunr> clisp is quite tricky to debug + <braunr> i never had to deal with a program that installs break points + and handles segfaults itself in order to implement growing stacks :p + <braunr> i suppose most interpreters do that + <gnu_srs> So the permanent change will be in glibc, not clisp? + <braunr> yes + + IRC, freenode, #hurd, 2012-08-24: + + <gnu_srs1> pinotree: The changes needed for fsync.c is at + http://paste.debian.net/185379/ if you want to try it out (confirmed + with rbraun) + <youpi> I agree with the patch, posix indeed documents einval as the + "proper" error value + <pinotree> there's fdatasync too + <pinotree> other places use MIG_BAD_ID instead of EMIG_BAD_ID + <braunr> pinotree: i assume that if you're telling us, it's because + they have different values + <pinotree> braunr: tbh i never seen the E version, and everywhere in + glibc the non-E version is used + <gnu_srs1> in sysdeps/mach/hurd/bits/errno.h only the E version is + defined + <pinotree> look in gnumach/include/mach/mig_errors.h + <pinotree> (as the comment in errno.h say) + <gnu_srs1> mig_errors.h yes. Which comment: from errors.h: /* Errors + from <mach/mig_errors.h>. */ and then the EMIG_ stuff? + <gnu_srs1> Which one is used when building libc? + <gnu_srs1> Answer: At least in fsync.c errno.h is used: #include + <errno.h> + <gnu_srs1> Yes, fdatasync.c should be patched too. + <gnu_srs1> pinotree: You are right: EMIG_ or MIG_ is confusing. + <gnu_srs1> /usr/include/i386-gnu/bits/errno.h: /* Errors from + <mach/mig_errors.h>. */ + <gnu_srs1> /usr/include/hurd.h:#include <mach/mig_errors.h> + + IRC, freenode, #hurd, 2012-09-02: + + <antrik> braunr: regarding fsync(), I agree that EOPNOTSUPP probably + should be translated to EINVAL, if that's what POSIX says. it does + *not* sound right to translate MIG_BAD_ID though. the server should + explicitly return EOPNOTSUPP, and that's what the default trivfs stub + does. if you actually do see MIG_BAD_ID, there must be some other + bug... + <braunr> antrik: right, pflocal doesn't call the trivfs stub for socket + objects + <braunr> trivfs_demuxer is only called by the pflocal node demuxer, for + socket objects it's another call, and i don't think it's the right + thing to call trivfs_demuxer there either + <pinotree> handling MAG_BAD_ID isn't a bad idea anyway, you never know + what the underlying server actually implements + <pinotree> (imho) + <braunr> for me, a bad id is the same as a not supported operation + <pinotree> ditto + <pinotree> from fsync's POV, both the results are the same anyway, ie + that the server does not support a file_sync operation + <antrik> no, a bad ID means the server doesn't implement the protocol + (or not properly at least) + <antrik> it's usually a bug IMHO + <antrik> there is a reason we have EOPNOTSUPP for operations that are + part of a protocol but not implemented by a particular server + <pinotree> antrik: even if it could be the case, there's no reason to + make fsync fail anyway + <antrik> pinotree: I think there is. it indicates a bug, which should + not be hidden + <pinotree> well, patches welcome then... + <antrik> thing is, if sock objects are actually not supposed to + implement the file interface, glibc shouldn't even *try* to call + fsync on them + <pinotree> how? + <pinotree> i mean, can you check whether the file interface is not + implemented, without doing a roundtrip^ + <pinotree> ? + <antrik> well, the sock objects are not files, i.e. they were *not* + obtained by file_name_lookup(), but rather a specific call. so glibc + actually *knows* that they are not files. + <braunr> antrik: this way of thinking means we need an "fd" protocol + <braunr> so that objects accessed through a file descriptor implement + all fd calls + <antrik> now I wonder though whether there are conceivable use cases + where it would make sense for objects obtained through the socket + call to optionally implement the file interface... + <antrik> which could actually make sense, if libc lets through other + file calls as well (which I guess it does, if the sock ports are + wrapped in normal fd structures?) + <braunr> antrik: they are + <braunr> and i'd personally be in favor of such an fd protocol, even if + it means implementing stubs for many useless calls + <braunr> but the way things are now suggest a bad id really means an + operation is simply not supported + <antrik> the question in this case is whether we should make the file + protocol mandatory for anything that can end up in an FD; or whether + we should keep it optional, and add the MIG_BAD_ID calls to *all* FD + operations + <antrik> (there is no reason for fsync to be special in this regard) + <braunr> yes + <antrik> braunr: BTW, I'm rather undecided whether the right approach + is a) requiring an FD interface collection, b) always checking + MIG_BAD_ID, or perhaps c) think about introducing a mechanism to + explicitly query supported interfaces... + + IRC, freenode, #hurd, 2012-09-03: + + <braunr> antrik: querying interfaces sounds like an additional penalty + on performance + <antrik> braunr: the query usually has to be done only once. in fact it + could be integrated into the name lookup... + <braunr> antrik: once for every object + <braunr> antrik: yes, along with the lookup would be a nice thing + + [[!message-id "1351231423.8019.19.camel@hp.my.own.domain"]]. + + * `t/no-hp-timing` + + IRC, freenode, #hurd, 2012-11-16 + + <pinotree> tschwinge: wrt the glibc topgit branch t/no-hp-timing, + couldn't that file be just replaced by #include + <sysdeps/generic/hp-timing.h>? + + * `flockfile`/`ftrylockfile`/`funlockfile` + + IRC, freenode, #hurd, 2012-11-16 + + <pinotree> youpi: uhm, in glibc we use + stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg + the nptl versions, which do lock/trylock/unlock); do you know more + about them? + <youpi> pinotree: ouch + <youpi> no, I don't know + <youpi> well, I do know what they're supposed to do + <pinotree> i'm trying fillig them, let's see + <youpi> but not why we don't have them + <youpi> (except that libpthread is "recent") + <youpi> yet another reason to build libpthread in glibc, btw + <youpi> oh, but we do provide lockfile in libpthread, don't we ? + <youpi> pinotree: yes, and libc has weak variants, so the libpthread + will take over + <pinotree> youpi: sure, but that in stuff linking to pthreads + <pinotree> if you do a simple application doing eg main() { fopen + + fwrite + fclose }, you get no locking + <youpi> so? + <youpi> if you don't have threads, you don't need locks :) + <pinotree> ... unless there is some indirect recursion + <youpi> ? + <pinotree> basically, i was debugging why glibc tests with mtrace() and + ending with muntrace() would die (while tests without muntrace call + wouldn't) + <youpi> well, I still don't see what a lock will bring + <pinotree> if you look at the muntrace implementation (in + malloc/mtrace.c), basically fclose can trigger a malloc hook (because + of the free for the FILE*) + <youpi> either you have threads, and it's need, or you don't, and it's + a nop + <youpi> yes, and ? + <braunr> does the signal thread count ? + <youpi> again, in linux, when you don't have threads, the lock is a nop + <youpi> does the signal thread use IO ? + <braunr> that's the question :) + <braunr> i hope not + <youpi> IIRC the signal thread just manages signals, and doesn't + execute the handler itself + <braunr> sure + <braunr> i was more thinking about debug stuff + <youpi> can't hurt to add them anyway, but let me still doubt that it'd + fix muntrace, I don't see why it would, unless you have threads + <pinotree> that's what i'm going next + <pinotree> pardon, it seems i got confused a bit + <pinotree> it'd look like a genuine muntrace bug (muntrace → fclose → + free hook → lock lock → fprint (since the FILE is still set) → malloc + → malloc hook → lock lock → spin) + <pinotree> at least i got some light over the flockfile stuff, thanks + ;) + <pinotree> youpi: otoh, __libc_lock_lock (etc) are noop in the base + implementation, while doing real locks on hurd in any case, and on + linux only if nptl is loaded, it seems + <pinotree> that would explain why on linux you get no deadlock + <youpi> unless using nptl, that is? + <pinotree> hm no, even with pthread it works + <pinotree> but hey, at least the affected glibc test now passes + <pinotree> will maybe try to do investigation on why it works on linux + tomorrow + + [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]]. + + * `t/pagesize` + + IRC, freenode, #hurd, 2012-11-16 + + <pinotree> tschwinge: somehow related to your t/pagesize branch: due to + the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h + switches the allocation modes from mmap to malloc + + * `LD_DEBUG` + + IRC, freenode, #hurd, 2012-11-22 + + <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and + then sigsegv + <tschwinge> Yeah, that's known for years... :-D + <tschwinge> Probably not too difficult to resolve, though. + + * Verify baseline changes, if we need any follow-up changes: + + * a11ec63713ea3903c482dc907a108be404191a02 + * 7e2b0c8562b35155820f87b5ff02a8b6850344cc + * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9 + * 5a2a1d75043138e696222ced4560de2fb90b8024 + * 5ae958d74180e2572d198bd7872c86f391de6da7 + * 5b08ac571ff8e94fe96511a532f0d20997de5f52 + * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26 + * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf + * 63c4ed22b5048c8701d8806026c23cc95f0df756 + * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c + * e35fcef8b739ed24e083ff8a3078ac14e101cf67 + * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba + * 8a492a675e566dc1e666df0a86cbf541442cb179 + * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef + * c86434ccb576a3ce35b5a74f72b9f03bd45b522a + * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53 + * 15bac72bac03faeb3b725b1d208c62160f0c3ad7 + * c08fb0d7bba4015078406b28d3906ccc5fda9d5a + * 10b3bedcb03386cc280113f552479793e4bac35f + * 754f7da38b0904b4b989d3500cc8dd5be625cf6a + * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d + * 962dba7828cf251a9025ccb43bc6effa30379b72 + * 3162f12e58c3a848db883916843b332b9f8c9d39 + * 1c06ba3100847da6bd1f2e011dc24fa8debd9615 + * 84b9230c404aed4fd3a7bb3d045ca367043dde8c + * 090555538d4347a52807ba9f08cf20ed13206afe + * 817328eea788c746131cf151b64fd250200da333 + * c3758feebf7c8786231465da664743c6f0ec79cc + * 1ac7a2c7b448c851eb8976fcc290a906a4075203 + * c21cc9bcb38a87ff638d1099ca871d94a2192b31 + * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde + * b8b4863d78bf26b39918fc753b03ed98ef262903 + * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1 + * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in + `sysdeps/mach/hurd/dl-sysdep.c` + * 0e516e0e14f2f9783a21cd1727bc53776341f857 + * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc + * cf7c9078a5acdbb435498ace92cd81009637a971 + * db753e2cfb2051ebf20dc089f87c5b1297cc2cff + * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good. + * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b + * 451f001b50870604e1f2daef12f04f9f460d3997 + + a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484. `nptl/Versions + [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`. We don't even + define it yet. Also see + [[glibc___libc_alloca_cutoff_should_be_lowered]]. + * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34 + * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca + * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f + * 68dc949774cb651d53541df4abdc60327f7e096b + * 70181fddf1467996bea393d13294ffe76b8a0853 + * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca + * 32465c3ea007065acd8ca8199f130cdf4068130d + * 18ba70a559c52719fd94a713cc380514d9d19125 + * 620a05296fe3380b7441ba7720e8b25c48a8c28c + * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in + TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c` + hunk? + * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 + + 1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix + pathconf(_PC_BUF_SIZE).` + * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.` + * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 + + 6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long + paths` + * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler + call in spawn implementation` + * 3b85df27870a47ed1db84e948e37a5a50a178a92 + + f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf + * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid + timeouts in emulated pselect` + * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`; + strndupa? + * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative + error numbers in strerror_r`. Change needed for + `sysdeps/mach/_strerror.c`? + * 7ea72f99966a65a56aedba817ee2413ff9b1f23c + + adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer + in XPG strerror function`. Change needed for + `sysdeps/mach/xpg-strerror.c`? + * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss. Does it work? + * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 + + 80e2212d8e59933a1641f029ebd360526ff0e074 + + 4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code + used for raise()`. Also for `bits/siginfo.h`? + * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work? + Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`, + `/proc/[PID]/mem` ([[!tag open_issue_hurd]], + [[hurd/translator/procfs]]). + * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`. + Watch what happens. + * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`. Watch + what happens. Native build: apparently OK. + * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) + + 1b74661a6b93a892ecb1c717dedeedba5c2a976c + + fd5e21c75d8e9221d766f4bc922a237265514ec2. Watch what happens. Native + build: `use-default-link = no`. + * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`), + 4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in + {,f}pathconf`). What about stuff like that for us? + * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with + AC_CHECK_TOOL`). Aren't there more in other configure.in and Makefile + files? + * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in + cancellation initialization`). Is this needed in other places, too? + * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64 + bytes`). Probably we have hidden somewhere such a constant, too (in + libpthread). + * d96de9634a334af16c0ac711074c15ac1762b23c + + ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn* + only in compat mode`). Change looks good, but what about + `SPAWN_XFLAGS_TRY_SHELL` for us? + * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features + mandatory and simplify the code.`). Generally looks good. + * `locale/global-locale.c`: Apparently, no one is using + `_HURD_THREADVAR_LOCALE`. But it is exported via + `hurd/threadvar.h`. + * `mach/devstream.c`: reversed. Fixed in + `t/repair-mach_devstream.c`. + * `malloc/arena.c`: should be OK. + * `Remove support for !USE___THREAD`. + d063d164335938d557460bebaa7cfe388157b627 (generally looks good; + `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) + + (de82006d43e198fd162807c9adc720c7ebd728a3 + + 037e9fe21c92216ef7032ea2796781ec27ca182a) + + 995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) + + bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok). + * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all + kinds of unused configuration options and dead code.`). `NO_STARTER` + changes (should be OK). + * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify + malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237, + [[!sourceware_PR 11929]]. Is this all kosher for us? See + [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]. + * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls + option, TLS support is required`). + * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in + __cmsg_nxthdr`). Probably just a C++ thing and not relevant for us; + see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]]. + * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7. Kosher with + respect to our [[glibc/mmap]] peculiarities? + * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`, + aa78043a4aafe5db1a1a76d544a833b63b4c5f5c + + 49a43d80ec5c97cf6136b1ee2687414773b2d5aa + + 3871f58f065dac3917eb18220a479e9591769c8c + + 9beb2334930db81ceada5aa6051fe5ac0554db32 + + 0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 + + edc5984d4d18296d7aa3d8f4ed8f7336a743170e + + 57769839788e2c62b68d9dfbf4b35052321278ba. + <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>. + * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 + + 4efeffc1d583597e4f52985b9747269e47b754e2 + + d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror + `bits/siginfo.h` changes. + * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe, + [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for + us? + * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 -- + probably should do similar changes, also to the generic file. + * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id + "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]] + 02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same + for the generic version as used by GNU Hurd. + * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4, + [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what + about other architectures? + * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to + adapt for (conditional?) Sun RPC reversion (if that was the original + cause for the patch)? + * [low] `Add __fsword_t and use it in bits/statfs.h`, + 3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id + "20120517134700.GA19046@intel.com"]] -- only updates one copy of + `bits/statfs.h`; update the others, too, for consistency. + * [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove + `libc_hidden_def` in `sysdeps/mach/hurd/accept4.c`? + * 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4, + b80af2f40631871cf53a5e39d08d5d5516473b96, + 04570aaa8ad88caad303f8afe469beb4cf851e17 `_dl_initial_dtv`: OK? + * [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 `Implement + POSIX-generic sleep via nanosleep rather than SIGARLM.`: any benefit + using that one (with `sysdeps/mach/nanosleep.c`) instead of + `sysdeps/mach/sleep.c`? + * *baseline* + * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd, + 2012-11-20, pinotree: »tschwinge: i agree on your comments on + ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's + sleep.c is buggy (not considers interruption, extra time() (= RPC) + call)«. + + +## Update + +`baseline`, `t/regenerate_configure` (could now be removed), +`t/master_backports`, `t/eglibc_backports`, `t/host-independency`, +`tschwinge/Roger_Whittaker` + + +# Build + +Here's a log of a glibc build run; this is from our [[Git repository's +28b74f8dbc3eb639d35fc0f93021ac5eb1fde9a4 (2012-11-03; +fbeafedeea37e0af1984a6511018d159f5ceed6a (2012-11-03)) +sources|source_repositories/glibc]], run on coulomb.SCHWINGE. + + $ export LC_ALL=C + $ ../Roger_Whittaker/configure AUTOCONF=: --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.6 CXX=g++-4.6 2>&1 | tee log_build + [...] + $ make install_root=/INVALID 2>&1 | tee log_build_ + [...] + +This takes up around 500 MiB, and needs roughly X min on kepler.SCHWINGE and +100 min on coulomb.SCHWINGE. + +<!-- + + $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test + +Mask out gcc-4.X (with possibly a backslash before the dot), GCC 4.5's column +output for (warning, error) messages, GCC 4.6's `[-Wsomething]` or `[enabled by +default]` identifiers which warning flag triggered. + + $ for f in log_*; do sed -e 's%gcc-4\\\?.[456]%[GCC]%g' -e 's%g++-4\\\?.[456]%[G++]%g' -e 's%\(:[0-9]\+:\)[0-9]\+:%\1%' -e 's% \[\(-W[a-z-]\+\|enabled by default\)\]$%%' < "$f" > "$f".nv; done + + $ 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 + +--> + + +## Analysis + + $ toolchain/logs/process gcc build fetch coulomb.SCHWINGE + +TODO. + + * With GCC >= 4.5, there's a ton of these warnings: + + hurd/hurd.h: In function '__hurd_fail': + hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t' + + ... as well as a few individual instances: + + hurdselect.c: In function '_hurd_select': + hurdselect.c:265: warning: case value '0' not in enumerated type 'error_t' + get-host.c: In function '_hurd_get_host_config': + get-host.c:38: warning: case value '0' not in enumerated type 'error_t' + hurdmsg.c: In function '_S_msg_get_init_ints': + hurdmsg.c:186: warning: case value '0' not in enumerated type 'error_t' + hurdmsg.c: In function '_S_msg_set_init_ints': + hurdmsg.c:273: warning: case value '0' not in enumerated type 'error_t' + intr-msg.c: In function '_hurd_intr_rpc_mach_msg': + intr-msg.c:363: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/setitimer.c: In function 'timer_thread': + sysdeps/mach/hurd/setitimer.c:117: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/wait4.c: In function '__wait4': + sysdeps/mach/hurd/wait4.c:40: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/fork.c: In function '__fork': + sysdeps/mach/hurd/fork.c:423: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/spawni.c: In function '__spawni': + sysdeps/mach/hurd/spawni.c:600: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/setpriority.c: In function 'setonepriority': + sysdeps/mach/hurd/setpriority.c:66: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/ioctl.c: In function 'send_rpc': + sysdeps/mach/hurd/ioctl.c:177: warning: case value '0' not in enumerated type 'error_t' + sysdeps/mach/hurd/ioctl.c: In function '__ioctl': + sysdeps/mach/hurd/ioctl.c:306: warning: case value '0' not in enumerated type 'error_t' + + [[!message-id "20120723195143.7F8142C0B9@topped-with-meat.com"]]. + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + (or probably Samuel's mmap backport) introduces: + + ../sysdeps/mach/hurd/mmap.c: In function '__mmap': + ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default] + ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default] + + * baseline + fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b + introduces: + + nscd_gethst_r.c: In function '__nscd_get_nl_timestamp': + nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] + + This was already present before: + + nscd_gethst_r.c: In function 'nscd_gethst_r': + nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration] + + * baseline + 2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032 + introduces: + + tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] + + * baseline + fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a + introduces + + +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4. + +tst-printf-round.c: In function 'do_test': + +tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] + +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' + +tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] + +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' + +tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] + +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' + +tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default] + +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*' + + gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + +In file included from test-wcschr.c:2:0: + +../string/test-strchr.c: In function 'check1': + +../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default] + +../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *' + +../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default] + +../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default] + +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *' + +../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default] + +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *' + + +# Install + +TODO. + + $ make install_root="$PWD".install install 2>&1 | tee log_install + [...] + +This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16 +min on coulomb.SCHWINGE. + + +## Analysis + + $ toolchain/logs/process gcc install fetch coulomb.SCHWINGE + +TODO. + +<!-- + $ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-linux.sed) <(ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_install | sed "s%\(/media/erich\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-hurd.sed) > open_issues/gdb/log_install.diff + +[[log_install.diff]]. + + * `libtool: finish`: `ldconfig` is not run for the Hurd. + +--> + + +# Testsuite + + $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test + [...] + +This needs roughly X min on kepler.SCHWINGE and 60 min on coulomb.SCHWINGE. + +Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out +of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't +our most critical issue to solve. + +<!-- + $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/data\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_linux + $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_hurd + +Comparing the results files, [[sum_linux]] to [[sum_hurd]]: + + $ diff -u -F ^Running open_issues/gdb/sum_linux open_issues/gdb/sum_hurd > open_issues/gdb/sum.diff + +[[open_issues/gdb/sum.diff]]. +--> + + +## Analysis + + $ toolchain/logs/process gcc test fetch coulomb.SCHWINGE + +There is quite a baseline of failures. + + * `annexc.out` + + TODO + + * `bug22.out` + + TODO + + * `bug-atexit3.out` + + TODO + + * `bug-getcontext.out` + + getcontext failed, errno: 1073741902. + + Is not implemented; see above. In 8958805c11c741d9211e20612c86271d906c9a0b + testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support + for FP exceptions.*, in cba1c83ad62a11347684a9daf349e659237a1741 testing, + it's back to the previous failure. + + * `bug-regex31-mem`, `tst-error1-mem`, `tst-fnmatch-mem`, + `tst-fopenloc.check` + + *output* files: some memory not freed. + + Caused by different memory allocation way in libio, see also + [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]] + + * `bug-ulimit1.out` + + Buggy sysdeps/unix/bsd/ulimit.c return values. + + [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]] + + * `check-execstack.out` + + $BUILDDIR/libc.so.phdr: *** executable stack signaled + + * `check-local-headers.out` + + Most of the external headers used are: + + * `/usr/include/device/bpf.h` + + * `/usr/include/device/device_types.h` + + * `/usr/include/device/net_status.h` + + * `/usr/include/cthreads.h` + + * `/usr/include/hurd/hurd_types.h` + + * `/usr/include/hurd/ioctls.defs` + + * `/usr/include/hurd/ioctl_types.h` + + * `/usr/include/hurd/paths.h` + + * `check-localplt.out` + + Around 500 or so `Extra PLT reference`. + + * `check-textrel.out` + + $BUILDDIR/libc.so.dyn: *** text relocations used + + * `opendir-tst1.out`, `tst-fdopendir2.out` + + `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a directory. + + * `test-assert-perr.out` + + TODO + + * `math/test-idouble`, `math/test-ifloat`, `math/test-ildoubl`, + `math/test-ldouble` + + SIGSEGV. + + * `test-float.out` + + TODO + + * `test-lfs.out` + + TODO + + * `test-multiarch.out` + + Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]] + providing the `flags` line. + + * `tst-aio2`, `tst-aio3`, + `tst-mqueue3`, `tst-mqueue6`, + `tst-mqueue8`, `tst-thrlock`, `tst-timer3`, + `libnss_test1.so` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + * `tst-aio8.out`, `tst-aio9.out`, `tst-aio10` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + Most will compile and work (except `tst-aio`, `tst-aio9`, `tst-aio10`) with + [[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread. + + * `tst-array*` + + Failures also seen on GNU/Linux; [[!message-id + "50950082.1070906@df1tl.local.here"]]. + + gcc-4.6 tst-array1.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out] Error 1 + gcc-4.6 tst-array2.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 tst-array2dep.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -fPIC -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc + gcc-4.6 -shared -static-libgcc -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,defs -B[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -L[...]/tschwinge/Roger_Whittaker.build-gcc-4.6 + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out tst-array2.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out] Error 1 + gcc-4.6 tst-array3.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out] Error 1 + gcc-4.6 tst-array4.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out tst-array4.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out] Error 1 + + `tst-array5` passes. + + gcc-4.6 tst-array1-static.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4 + gcc-4.6 -nostdlib -nostartfiles -static -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crt0.o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crti + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static > [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out] Error 1 + + `tst-array5-static` passes. + + * `tst-audit1.out`, `tst-audit2.out` + + SIGKILL. + + * `tst-chk1.out` + + TODO + + * `tst-chk2.out` + + TODO + + * `tst-chk3.out` + + TODO + + * `tst-chk4.out` + + TODO + + * `tst-chk5.out` + + TODO + + * `tst-chk6.out` + + TODO + + * `tst-cputimer1.o`, `tst-cputimer2.o`, `tst-cputimer3.o`, + `tst-timer4.o`, `tst-timer5.o` + + Missing `SIGRTMIN`. + + All these tests #include `tst-timer4.c`. + + * `tst-timer5.o` + + TODO + + * `tst-dlmopen1.out` + + TODO + + * `tst-ether_line.o` + + tst-ether_line.c:19: error: 'ETH_ALEN' undeclared (first use in this function) + + Will either need a `hurd/netinet/if_ether.h` that includes + `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`? + See also [[!sourceware_PR 11142]]. + + * `tst-fdopendir.out` + + directory atime changed + + TODO + + * `tst-futimesat.out` + + `futimesat` is a stub. + + * `tst-getconf.out` + + Ends with: + + getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument + + It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`, + `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`, + `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`. + + `_CS_GNU_LIBPTHREAD_VERSION` will be cleanly solved with + [[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] and libpthread + compiled as add-on. + + * `tst-grantpt.out` + + posix_openpt(O_RDWR) failed + errno 1073741902 (Function not implemented) + + `posix_openpt` is a stub. + + grantpt(): expected: return = -1, errno = 1073741846 + got: return = -1, errno = -303 + + `grantpt` (actually `ptsname_r`), does not fail with `ENOTTY` when the `fd` + does not refer to a PTY master. + + * `tst-lfschk2.out` + + TODO + + * `tst-lfschk3.out` + + TODO + + * `tst-lfschk4.out` + + TODO + + * `tst-lfschk5.out` + + TODO + + * `tst-lfschk6.out` + + TODO + + * `tst-longjmp_chk2.out` + + TODO + + * `tst-mqueue5.o` + + Missing `SIGRTMIN`. + + * `tst-pselect.o` + + Missing `SA_NOCLDWAIT`. + + * `tst-secure-getenv.out` + + Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]]. + + * `tst-sprofil.out` + + Floating point exception + + * `tst-stackguard1.out` + + TODO + + * `tst-stackguard1-static.out` + + TODO + + * `tststatic2.out` + + TODO + + * `tststatic.out` + + TODO + + * `tst-strtod-round.out` + + TODO + + * `tst-timer2.o` + + Missing `SIGRTMIN`. + + * `tst-timer.out` + + TODO + + * `tst-tls9-static.out` + + TODO + + * `tst-unique3lib.so`, `tst-unique3lib2.so`, `tst-unique4lib.so` + + Only with GCC 4.4; no longer with 4.5 or 4.6: + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/elf/tst-unique3lib.os:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0' + + * `tst-vfork3-mem` + + + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + + 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8] + + 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389] + + 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963] + - 0x0804c8d8 Free 84 was never alloc'd 0x10955fc + - 0x0804c960 Free 87 was never alloc'd 0x115672f + - 0x0804c9b8 Free 88 was never alloc'd 0x1156737 + + Memory not freed: + ----------------- + Address Size Caller + 0x0804cfa8 0x73 at 0x10df0c8 + 0x00000008 0 at 0x10df0c8 + + TODO + + * `tst-waitid.out` + + Fails sometimes (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`). + + +### Additional Failures Compared to Debian (OLD) + + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test > log_test.filtered + $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered + + * `bug-atexit3.out`, `debug/tst-chk4`, `debug/tst-chk5`, `debug/tst-chk6`, + `debug/tst-lfschk4`, `debug/tst-lfschk5`, `debug/tst-lfschk6` + + dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory + + See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]]. + Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6 + /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`. + This is a bug in the glibc test harness. Should probably use some + `configure` magic akin to the `fixincludes` stuff (`gcc-4.4 + -print-file-name=libstdc++.so.6`, etc.). + + Even if that that is being worked around, the tests fail with: + + dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6) + dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1) + + [[packaging_libpthread]]. + + * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`, + `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`, + `grp/tst_fgetgrent`, `dlfcn/tststatic`, `dlfcn/tststatic2`, + `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory + + Looking into `localedata/bug-setlocale1.c`, it is clear what it going on: + only the root of the build directory is added for `--library-path`, but + none of the other directories that are additionally used. This is a bug in + the glibc test harness. Hacked around by `ln -s mach/libmachuser.so.1 + hurd/libhurduser.so.0.3 ./`. Hopefully the other instances are similar. + + * `posix/tst-getconf` + + It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`, + `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`, + `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`. + + `_CS_GNU_LIBPTHREAD_VERSION` will be cleanly solved with + [[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] and libpthread + compiled as add-on. + + Ends with: + + getconf POSIX_ALLOC_SIZE_MIN /: /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/posix/getconf: pathconf: /: Invalid argument + + * `dlfcn/tststatic`, `dlfcn/tststatic2` + + No output, SEGFAULT. + + * `math/test-idouble`, `math/test-ifloat`, `math/test-ildoubl`, + `math/test-ldouble` + + SIGSEGV. + + * `rt-tst-aio2`, `rt-tst-aio3`, `rt/tst-aio10`, `rt/tst-aio9` + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `do_test': + tst-aio10.c:(.text+0x1b): undefined reference to `pthread_self' + tst-aio10.c:(.text+0x78): undefined reference to `pthread_barrier_init' + tst-aio10.c:(.text+0xf7): undefined reference to `pthread_create' + tst-aio10.c:(.text+0x10b): undefined reference to `pthread_barrier_wait' + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `tf': + tst-aio10.c:(.text+0x5ae): undefined reference to `pthread_barrier_wait' + tst-aio10.c:(.text+0x5ef): undefined reference to `pthread_kill' + collect2: ld returned 1 exit status + make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10] Error 1 + + * `rt/tst-mqueue3`, `rt/tst-mqueue6`, + `rt/tst-mqueue8`, `elf/tst-thrlock`, `rt/tst-timer3`, + `nss//libnss_test1.so` + + Compilation: missing `pthread_attr_init`, `pthread_barrier_init`, + `pthread_create`, etc. + + * `elf/tst-audit1`, `elf/tst-audit2` + + SIGKILL. + + * `inet/tst-ether_line` + + tst-ether_line.c:19: error: 'ETH_ALEN' undeclared (first use in this function) + + Will either need a `hurd/netinet/if_ether.h` that includes + `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`? + See also [[!sourceware_PR 11142]]. + + * `gmon/tst-sprofil` + + Floating point exception + + * `posix/bug-regex31-mem`, `posix/tst-fnmatch-mem`, `misc/tst-error1-mem`, + `libio/tst-fopenloc.check` + + *output* files: some memory not freed. + + [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]] + + * `assert/test-assert.out` + + Fails sometimes... + + * `stdlib/bug-getcontext.out` + + getcontext failed, errno: 1073741902. + + Is not implemented; see above. In 8958805c11c741d9211e20612c86271d906c9a0b + testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support + for FP exceptions.*, in cba1c83ad62a11347684a9daf349e659237a1741 testing, + it's back to the previous failure. + + * `elf/tst-unique3lib.so`, `elf/tst-unique3lib2.so`, `elf/tst-unique4lib.so` + + Only with GCC 4.4; no longer with 4.5 or 4.6: + + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/elf/tst-unique3lib.os:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0' + + * `math/test-fenv.out` + + Used to fail (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`), but something between + 22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and + 005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely + Jérémie's signaling work. + + * `posix/tst-waitid.out` + + Fails sometimes (is listed in Debian eglibc-2.13-21's + `expected-results-i486-gnu-libc`). + + * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d, + [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]]) + + Unused direct dependencies: + /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2 + + As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes -- + correct? + + * `stdlib/tst-secure-getenv.out` + + Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]]. + + * `elf/tst-array*` + + Failures also seen on GNU/Linux; [[!message-id + "50950082.1070906@df1tl.local.here"]]. + + gcc-4.6 tst-array1.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out] Error 1 + gcc-4.6 tst-array2.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 tst-array2dep.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -fPIC -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc + gcc-4.6 -shared -static-libgcc -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,defs -B[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/ -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -L[...]/tschwinge/Roger_Whittaker.build-gcc-4.6 + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out tst-array2.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out] Error 1 + gcc-4.6 tst-array3.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out] Error 1 + gcc-4.6 tst-array4.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/ + gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4 -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486 + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[ + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out tst-array4.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out] Error 1 + + `tst-array5` passes. + + gcc-4.6 tst-array1-static.c -c -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4 + gcc-4.6 -nostdlib -nostartfiles -static -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crt0.o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crti + [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static > [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out + cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out tst-array1.exp > /dev/null + make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out] Error 1 + + `tst-array5-static` passes. + + +## OLD + +`configure --without-cvs --prefix= --disable-profile --build=i486-gnu +--host=i486-gnu` + +`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to +c9fd33ef070def49c078c94f8d9bc9f8a8e267f7. + +Configured with `--prefix=/usr` instead of `--prefix=`. + +Resolved failures: + + * localedata/tst_mblen.out + * localedata/tst_mbrlen.out + * localedata/tst_mbrtowc.out + * localedata/tst_mbsrtowcs.out + * localedata/tst_mbstowcs.out + * localedata/tst_mbtowc.out + * localedata/tst_swscanf.out + * localedata/tst_wcrtomb.out + * localedata/tst_wcsrtombs.out + * localedata/tst_wcstombs.out + * localedata/tst_wctob.out + * localedata/tst_wctomb.out + * localedata/bug-iconv-trans.out + * localedata/tst-wctype.out + * math/test-float.out + * math/test-double.out + * posix/tst-vfork3-mem + * io/tst-mkdirat.out + +New: + + * A lot of `error while loading shared libraries: libmachuser.so.1: cannot + open shared object file: No such file or directory`. Is it perhaps picking + that library up from `$prefix/lib/`? + + New failures; likely due to that: + + * iconvdata/iconv-test.out + * iconvdata/tst-tables.out + * malloc/tst-mtrace.out + * grp/tst_fgetgrent.out + * posix/globtest.out + * posix/wordexp-tst.out + * io/ftwtest.out + * elf/tst-pathopt.out + + Changed failures; likely due to that: + + * debug/tst-chk4.out / debug/tst-chk5.out + + -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory + +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory + +--- + +Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting. + +--- + +Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting. + +New failures: + + * posix/bug-glob3.out (SEGFAULT; but also on Linux) + * wctype/bug-wctypeh.o (compile error; but also on Linux) diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn new file mode 100644 index 00000000..331632f3 --- /dev/null +++ b/open_issues/glibc/debian.mdwn @@ -0,0 +1,64 @@ +[[!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]]."]]"""]] + + +# Open Issues + +`threads = yes` is set in `debian/sysdeps/linux.mk` and +`debian/sysdeps/kfreebsd.mk`, `debian/sysdeps/hurd.mk` set to `no`. But this +is only read in `debian/rules` for deciding some `nscd` package issue? + +`debian/sysdeps/hurd.mk`'s `libc_extra_install` for `ld.so`: check with GCC +configuration. + +Could add a toggle to `$(stamp)build_%` in `debian/rules.d/build.mk` to skip +locale stuff. + +`--disable-compatible-utmp`? + + +# Building + +Run `debian/rules patch` to apply patches (instead of having it done during the +build). Then you can edit files manually. + +Several passes: `libc`, `i686`, `xen`; `EGLIBC_PASSES='libc i686'`, etc. + +If building with `EGLIBC_PASSES=libc` (more specifically, without `xen`), the +`libc0.3-dev_extra_pkg_install` rule in `debian/sysdeps/hurd-i386.mk` will +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, 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. + +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/mremap.mdwn b/open_issues/glibc/mremap.mdwn new file mode 100644 index 00000000..874c7ae0 --- /dev/null +++ b/open_issues/glibc/mremap.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +The Hurd does not currently support the `mremap` function. + +For the `MREMAP_MAYMOVE` case it is easy to work around; see +`[binutils]/gold/mremap.c`, for example. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-01-12 + + <antrik> maybe it would be easiest actually to implement mremap()?... + <braunr> antrik: i'm nto sure + <braunr> antrik: implementing mremap could be relatively easy to do + actually + <braunr> antrik: IIRC, vm_map() supports overlapping + <antrik> braunr: yes, I think so too + <antrik> braunr: haven't checked, but I have a vague recollection that the + fundamentals are pretty much there + +[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`. +[[I|tschwinge]] remember some discussion about this, but have not yet worked on +locating it. [[Talk to me|tschwinge]] if you'd like to have a look at this. + + +# IRC, OFTC, #debian-hurd, 2012-06-19 + + <bdefreese> OK, how the heck do you get an undefined reference to mremap? + <youpi> simply because we don't have it + <pinotree> mremap exists only on linux + <bdefreese> It's in sys/mman.h + <pinotree> on linux? + <bdefreese> No, on GNU/Hurd + <bdefreese> /usr/include/i386-gnu/sys/mman.h + <youpi> that's just the common file with linux + <youpi> containing just the prototype + <youpi> that doesn't mean there's an implementation behind + <pinotree> youpi: hm no, linux has an own version + <youpi> uh + <bdefreese> Ah, aye, I didn't look at the implementation.. :( + <youpi> it's then odd that it was added to the generic sys/mman.h :) + <bdefreese> Just another stub? + <pinotree> ah, only few linux archs have own versions + <youpi> for the macro values I guess + <pinotree> http://paste.debian.net/175173/ on glibc/master + <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from? + <youpi> rgrep on a linux box ;) + <youpi> <bits/mman.h> + <youpi> but that's again linuxish + <bdefreese> Aye but with us having that in the header it is causing some + code to be run which utilizes mremap. If that wasn't defined we wouldn't + be calling it. + <youpi> ah + <youpi> we could try to remove it indeed + <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined + __GNU__? + <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn new file mode 100644 index 00000000..b12b7558 --- /dev/null +++ b/open_issues/glibc/octave.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 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, OFTC, #debian-hurd, 2012-04-23 + + <pinotree> diffing the octave i386 vs hurd-i386 build logs gives + interesting surprises + <youpi> checking whether this system has an arbitrary file name length + limit... no | checking whether this system has an arbitrary + file name length limit... yes + <youpi> ? + <pinotree> not only that + <youpi> checking whether getcwd handles long file names properly... yes + | checking whether getcwd handles long file names properly... no, but it + is partly worki+ + <youpi> ? + <pinotree> -checking whether fdopendir works... yes + <pinotree> +checking whether fdopendir works... no + <pinotree> (- is i386, + is hurd-i386) + <pinotree> -checking whether getlogin_r works with small buffers... yes + <pinotree> +checking whether getlogin_r works with small buffers... no + <pinotree> -checking for working mkstemp... yes + <pinotree> +checking for working mkstemp... no + <pinotree> +checking for working nanosleep... no (mishandles large + arguments) diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn new file mode 100644 index 00000000..4afd8a1a --- /dev/null +++ b/open_issues/glibc/t/tls-threadvar.mdwn @@ -0,0 +1,60 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +This basically means to get rid of `sysdeps/mach/hurd/bits/libc-tsd.h` (and +thus the `_HURD_THREADVAR_*`/`_hurd_threadvar_location` interface), and +directly use `__thread` instead. + +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]]. + +After this has been done, probably the whole `__libc_tsd_*` stuff can be +dropped altogether, and `__thread` directly be used in glibc. + + +# IRC, freenode, #hurd, 2012-08-07 + + <tschwinge> r5219: Update libpthread patch to replace threadvar with tls + for pthread_self + <tschwinge> r5224: revert r5219 too, it's not ready either + <youpi> as the changelog says, the __thread revertal is because it posed + problems + <youpi> and I just didn't have any time to check them while the freeze was + so close + <tschwinge> OK. What kind of problems? Should it be reverted upstream, + too? + <youpi> I don't remember exactly + <youpi> it should just be fixed + <youpi> we can revert it upstream, but it'd be good that we manage to + progress, at some point... + <tschwinge> Of course -- however as long as we don't know what kind of + problem, it is a bit difficult. ;-) + <youpi> since I didn't left a note, it was most probably a mere glibc run, + or boot with the patched libpthread + <youpi> *testsuite run + <tschwinge> OK. + <tschwinge> The libpthread testsuite doesn't show any issues with that + patch applied, though. But I didn'T test anything else. + <tschwinge> youpi: Also, you have probably seen my glibc __thread errno + email -- rmcgrath wanted to find some time this week to comment/help, and + I take it you don't have any immediate comments to that issue? + <youpi> I saw the mails, but didn't investigate at all diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn new file mode 100644 index 00000000..68db2cc1 --- /dev/null +++ b/open_issues/glibc/t/tls.mdwn @@ -0,0 +1,70 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +# To Do + + * Discuss d2431f633e6139a62e1575ec18830f7e81160cf0 with Samuel. + + * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed. + + +# Documentation + +[[!taglink open_issue_documentation]] + + * IRC, freenode, #hurd, 2011-11-26 + + <tschwinge> In glibc multiarch support (strcasecmp for i686 SSE3, etc.) + there is access to memory via gs: -- this will need to be changed for + us, right? + <youpi> depends on the access + <tschwinge> * `optimized strcasecmp and strncasecmp for x86-32` + (multiarch), + <tschwinge> 76e3966e9efc3808a9e7ad09121c5dfc1211c20b + + <tschwinge> 6abf346582ba678f4850a88b4a5950593841df1d + + <tschwinge> 5583a0862cf94f71cbcde91c4043a20af65facca. `gs` + access. + <youpi> + movl __libc_tsd_LOCALE@GOTNTPOFF(%ebx), %eax + <youpi> that's handled by the linker fine + <youpi> it's only the things held in the tcb_t structure which can pose + problem + <tschwinge> tcbhead_t? + <tschwinge> I'm looking at this. + <tschwinge> So, at gs:0, there is the TCB. + <tschwinge> And we have the same layout as NPTL/Linux, just that we + don't have as much data there as they have. + <tschwinge> We're missing multiple_threads, sysinfo, sttack_guard, + pointer_guard, gscope_flag, private_futex, __private_tm[5]. + <tschwinge> So, if one of these is referenced (be it my name or by + numeric offset), this is invalid for us. + <tschwinge> Anything else should work equivalently. + <youpi> yes + <youpi> usually the only numeric offset being used is 0 + <youpi> so it would simply not build + <tschwinge> And the other offsers are generated via tcb-offsets.sym. + <tschwinge> glibc's elf/stackguard-macros.h is wrong for us (but not + used anywhere apart from elf/tst-stackguard1.c, I think). + +After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's +`sysdeps/i386/stackguard-macros.h`; problem remains. + + <tschwinge> __thread __locale_t __libc_tsd_LOCALE = &_nl_global_locale; + -- this means that a __libc_tsd_LOCALE values will be in the TLS + segment, and this is what is being accessed from the assembler code + with %gs:__libc_tsd_LOCALE@NTPOFF, and the linker will resolve this. + <youpi> yes + <youpi> see in the nm output, the libc_tsd symbols + <youpi> these provide the offsets + <tschwinge> youpi: Thank you, I'm now understanding this part of TLS + much better. + <youpi> have you had a look at the tls.pdf from Uli ? + <youpi> all the gory details are there :) diff --git a/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn new file mode 100644 index 00000000..6d1b4bea --- /dev/null +++ b/open_issues/glibc___libc_alloca_cutoff_should_be_lowered.mdwn @@ -0,0 +1,19 @@ +[[!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="glibc: __libc_alloca_cutoff should be lowered"]] + +[[!tag open_issue_hurd open_issue_glibc]] + +Ognyan Kulev, *[LIBC] \_\_libc\_alloca\_cutoff should be lowered*, bug-hurd, +2003-06-12, <http://lists.gnu.org/archive/html/bug-hurd/2003-06/msg00050.html> + +Replace second link (mail.gnu.org) with +<http://lists.gnu.org/archive/html/bug-hurd/2002-09/msg00143.html>. diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn new file mode 100644 index 00000000..14329d0f --- /dev/null +++ b/open_issues/glibc_ioctls.mdwn @@ -0,0 +1,72 @@ +[[!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_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> d'oh, broken defines for ioctl()! + <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines + <pinotree> tschwinge: ↑ know anything about this? + <pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h + <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit + + <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header + <youpi> that's possible + <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq' + <youpi> ah, that's not a bug then + <youpi> see the ioctl section of the porting page of the wiki + <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq + <pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough + * pinotree looks + <youpi> it's not to be done so simply + <youpi> see the page :) + <youpi> I'm afraid _IOT_arpreq can't be properly defined + * pinotree is not finding it... + <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html + <youpi> that's it yes + <youpi> I mean, that's the kind of thing + <youpi> but not the wiki page, let me look + <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html + <pinotree> i also saw a glib patch adding few types like that (char, short, int) + <youpi> yes that's the same kind of thing + <pinotree> i see + <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such + <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16] + <pinotree> so basically it would support at most 3 elements in a passed struct? + <pinotree> s/elements/fields/ + <youpi> 3 kinds of fields + <youpi> as you provide a count + <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? + <pinotree> ie the order of the fields in the struct does not matter, it seems? + <youpi> the order of the fields does matter + <youpi> as this encodes how mig will read the struct to send them + <pinotree> uhm + <youpi> also, _IOTS(struct sockaddr) won't work + <pinotree> yeah i should define it too + <youpi> no, it even needs to be replaced by its content + <pinotree> ah + <pinotree> it is possible to compose the _IOTS()? + <pinotree> (to build structs with more than 3 kind of fields) + <youpi> no + <pinotree> d'oh + <youpi> that's a hard shortcoming of the whole ioctl encoding + * pinotree scratches his head + <youpi> there's no way but redefining ioctl(), really + <youpi> it was a funny trick to encode it this way, but unrealistic + <pinotree> i see, yes + <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig + <pinotree> indeed + <youpi> actually it's not mach's ioctl issue + <youpi> as mach doesn't know ioctl + <youpi> but the hurd ioctl interface + <pinotree> right + <youpi> which might end up in mach, other processes, other machines, etc. + * pinotree s/Mach/Hurd/ :) diff --git a/open_issues/glibc_libpthread_robust_mutexes.mdwn b/open_issues/glibc_libpthread_robust_mutexes.mdwn new file mode 100644 index 00000000..a92c984d --- /dev/null +++ b/open_issues/glibc_libpthread_robust_mutexes.mdwn @@ -0,0 +1,54 @@ +[[!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_glibc open_issue_libpthread]] + +libpthread: glibc 44e2ad5ab8c21dbfed3e384ba2ed31d7a8fc4744 +998e5fc14595229101561d76282036839e5b66ab -- The robust mutex functions are in +POSIX 2008. + +--- + +IRC, #hurd, unknown date. + + <youpi> neal: bad news: you remember the PTHREAD_RECURSIVE_MUTEX_INITIALIZER that points to a global __pthread_recursive_mutexattr? + <youpi> that doesn't work + <youpi> because some libraries like libstdc++ do not link against libpthread, while still using pthread_mutex_lock/unlock (counting on them being provided by either libc or libpthread-stubs) + <CIA-1> sthibaul-guest * r626 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): + <CIA-1> * debian/patches/libpthread_rwlock_initializer.patch: Disable patch for now: + <CIA-1> our initializer does not work when the application does not link against + <CIA-1> libpthread. + + <CIA-1> sthibaul-guest * r629 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): do not disable adding PTHREAD_RWLOCK_INITIALIZER, that's not the one that poses problems + <CIA-1> sthibaul-guest * r630 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_no_recursive_mutex_initializer.patch: New patch + <CIA-1> to drop undefined references to __pthread_recursive_mutexattr. + + <youpi> I'm thinking about how to fix the PTHREAD_RECURSIVE_MUTEX_INITIALIZER + <youpi> instead of a pointer to a static attribute variable, which posed problem + <youpi> could we perhaps consider that page 0 is never mapped + <youpi> and thus not only pointer 0 but also 1 2, etc. are invalid + <neal> I think that is a good solution + <youpi> and use them as special values + <neal> alternatively, we could assume that -PAGESIZE is never valid + <youpi> that makes us test it in all pthread_mutex_* functions, but it's not so bad + <neal> I'm not sure which is better + <youpi> why isn't it? + <neal> because the kernel is mapped there normally + <youpi> the kernel could be elsewhere + <neal> true + <youpi> in a 64bit adressing space for instance + <neal> I think your solution is a good one + <youpi> ok + + <CIA-1> sthibault * r633 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_recursive_mutex_initializer.patch: New patch + <CIA-1> to fix the recursive mutex initializers usage in libraries not linking + <CIA-1> against libpthread. diff --git a/open_issues/glibc_madvise_vs_static_linking.mdwn b/open_issues/glibc_madvise_vs_static_linking.mdwn new file mode 100644 index 00000000..ab633b0f --- /dev/null +++ b/open_issues/glibc_madvise_vs_static_linking.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]] + +[[!sourceware_PR 4822]]. + + $ echo 'int main() {}' | gcc -o /dev/null -static -x c - + /usr/lib/gcc/i486-gnu/4.4.5/../../../libcrt.a(malloc.o): In function `_int_free': + (.text+0xdc3): warning: warning: madvise is not implemented and will always fail + +This is correct, but it does confuse GNU Autoconf, for example, which then +thinks that static linking is not supported and sets a flag accordingly, which +luckly no / not many packages use. + +*This call does not influence the semantics of the application (except in the +case of MADV_DONTNEED), but may influence its performance. The kernel is free +to ignore the advice.* (`man madvise`), so we may simply want to turn it into a +no-op in glibc, avoiding the link-time warning. + +GCC c5db973fdab3db3e13db575e5650c0bcfd3630f4 (2011-10-17) makes use of this. +As we now export the symbol (and `MADV_DONTNEED`, too), GCC will no longer +`munmap` pages, but will keep them mapped for later re-use. This may increase +memory usage. + +2011-07: This is what Samuel has [done for Debian +glibc](http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/trunk/debian/patches/hurd-i386/local-madvise_warn.diff). + + +# IRC, freenode, #hurd, 2012-02-16 + + <tschwinge> youpi: With Roland's fix the situation will be that just using + gcc -static doesn't emit the stub warning, but still will do so in case + that the source code itself links in madvise. Is this acceptable for + you/Debian/...? + <youpi> packages with -Werror will still bug out + <youpi> not that I consider -Werror to be a good idea, though :) + <tschwinge> youpi: Indeed. Compiler warnings can be caused by all kinds of + things. -Werror is good for development, but not for releases. diff --git a/open_issues/glibc_ptrace.mdwn b/open_issues/glibc_ptrace.mdwn index b4c529d7..7ca07077 100644 --- a/open_issues/glibc_ptrace.mdwn +++ b/open_issues/glibc_ptrace.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2012 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 @@ -33,15 +33,11 @@ License|/fdl]]."]]"""]] and for us it is a `struct i386_thread_state` from `mach/i386/thread_status.h`; - * Linux probides some functionality that we don't provide, e.g., - `PTRACE_SINGLESTEP`. + * Linux provides some functionality that we don't provide: + `PTRACE_GETFPXREGS` , `PTRACE_SINGLESTEP`. * Some parts are wrongly implemented, e.g., `PTRACE_GETREGS` and `PTRACE_SETREGS` both do the same thing. - * `return` values are wrong, e.g., `return EOPNOTSUPP` should instead - set `errno = EOPNOTSUPP` and `return -1` in a few places (but not - with the three `PTRACE_PEEK*` requests. - Also consider the `sysdeps/generic/sys/ptrace.h` and `sysdeps/unix/sysv/linux/sys/ptrace.h` files. diff --git a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn new file mode 100644 index 00000000..47f104c6 --- /dev/null +++ b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn @@ -0,0 +1,28 @@ +[[!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_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> you can hardcode DTV_OFFSET as 4 for now + <youpi> it's the offset of the dtv field in the tcbhead_t structure from hurd/libpthread + <tschwinge> youpi: May very well be that I'm misunderstanding something, but wouldn't it rather be the offset of tcb in __pthread + the offset of dtv in tcbhead_t (which indeed is 4)? + <youpi> what you don't know is that DTV_OFFSET is not relative to __pthread, but to the tls segment + <tschwinge> Oh, aha. Thanks. + <youpi> and drepper abused the fact that in nptl __pthread appears at the start of the tls segment + +kFreeBSD, glibc: + + ++#if 0 + + DTV_OFFSET offsetof(struct pthread, header.dtv) + ++#else + ++DTV_OFFSET offsetof(struct _pthread_descr_struct, p_header.data.dtvp) + ++#endif diff --git a/open_issues/glusterfs.mdwn b/open_issues/glusterfs.mdwn new file mode 100644 index 00000000..68518938 --- /dev/null +++ b/open_issues/glusterfs.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]]."]]"""]] + +IRC, unknown channel, unknown date. + + <antrik> "GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It + <antrik> borrows a powerful concept called Translators from GNU Hurd kernel." + <antrik> seems to be more similar to libstore than actual translators, though diff --git a/open_issues/gnat.mdwn b/open_issues/gnat.mdwn new file mode 100644 index 00000000..2d17e275 --- /dev/null +++ b/open_issues/gnat.mdwn @@ -0,0 +1,102 @@ +[[!meta copyright="Copyright © 2011, 2012 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="Enable Ada programming (GCC: GNAT)"]] + +[[!tag open_issue_gcc]] + +Make the Ada programming language available on GNU/Hurd in its [[GCC]] GNAT +implementation, and enable Hurd-specific features. + +There is a [[!FF_project 259]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/gnat feeds=no]] + + +## Debian GCC + +There has a patch been added for GNU/kFreeBSD: +`bfe081336914729fc0180c07ab4afa41965100f2`, `git-svn-id: +svn://svn.debian.org/gcccvs/branches/sid@5638 +6ca36cf4-e1d1-0310-8c6f-e303bb2178ca' + + +## IRC, freenode, #hurd, 2012-07-17 + + <gnu_srs> I've found the remaining problem with gnat backtrace for Hurd! + Related to the stack frame. + <gnu_srs> This version does not work: one relying on static assumptions + about the frame layout + <gnu_srs> Causing segfaults. + <gnu_srs> Any interest to create a test case out of that piece of code, + taken from gcc/ada/tracebak.c? + <braunr> gnu_srs: sure + + +### IRC, freenode, #hurd, 2012-07-18 + + <braunr> "Digging further revealed that the GNU/Hurd stack frame does not + seem to + <braunr> be static enough to define USE_GENERIC_UNWINDER in + gcc/ada/tracebak.c. + <braunr> " + <braunr> what do you mean by a "stack frame does not seem to be static + enough" ? + <gnu_srs> I can qoute from the source file if you want. Otherwise look at + the code yourself: gcc/ada/tracebak,c + <gnu_srs> I mean that something is wrong with the stack frame for + Hurd. This is the code I wanted to use as a test case for the stack. + <gnu_srs> Remember? + <braunr> more or less + <braunr> ah, "static assumptions" + <braunr> all right, i don't think anything is "wrong" with stack frames + <braunr> but if you use a recent version of gcc, as indicated in the code, + -fomit-frame-pointer is enabled by default + <braunr> so your stack frame won't look like it used to be without the + option + <braunr> hence the need for USE_GCC_UNWINDER + <braunr> http://en.wikipedia.org/wiki/Call_stack explains this very well + <gnu_srs> However, kfreebsd does not seem to need USE_GCC_UNWINDER, how + come? + <braunr> i guess they don't omit the frame pointer + <braunr> your fix is good btw + <gnu_srs> thanks + + +### IRC, freenode, #hurd, 2012-07-19 + + <gnu_srs> tschwinge: The bug in #681998 should go upstream. Applied in + Debian already. Hopefully this is the last patch needed for the port of + GNAT to Hurd. + + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Ada. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/gnumach_console_timestamp.mdwn b/open_issues/gnumach_console_timestamp.mdwn new file mode 100644 index 00000000..52b574d5 --- /dev/null +++ b/open_issues/gnumach_console_timestamp.mdwn @@ -0,0 +1,29 @@ +[[!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]] + +There is a [[!FF_project 267]][[!tag bounty]] on this task. + +IRC, freenode, #hurd, 2011-02-17 + + <azeem> task 39011c10 deallocating an invalid port 349, most probably a + bug. + <azeem> kernel: Page fault (14), code=6 + <azeem> Stopped at 0x28b9c7: orb %bh,0(%ecx,%edi,2) + <azeem> db> + [...] + <antrik> tschwinge: I doubt the deallocating warning is related to the + later fault + <tschwinge> antrik: YOu may be right. + <tschwinge> Perhaps it'd be a good idea to add some sort of timestamp to + Mach messages. + <tschwinge> Like in Linux' dmesg. + <tschwinge> Or just RDTSC (internal processor counter). diff --git a/open_issues/gnumach_constants.mdwn b/open_issues/gnumach_constants.mdwn new file mode 100644 index 00000000..16c8cf41 --- /dev/null +++ b/open_issues/gnumach_constants.mdwn @@ -0,0 +1,32 @@ +[[!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]] + +At compile-time, GNU Mach is parameterized with several constants. These might +need some tuning. Debian has some patches. + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> youpi: in ipc/ipc_hash.c, there is code which computes the size of + the global (space, port)->entry hash table + <braunr> youpi: you may be interested in tuning this one too + <youpi> I know + <braunr> ok + <youpi> the current value is not so bad + <youpi> it's big enough for buildds to run fine + <braunr> 256 if i'm right + <braunr> well + <braunr> it won't fail + <youpi> we're limited by the 4000 object limitation anyway + <braunr> since it's a chained hash table + <braunr> but increasing it may help performances a bit + <braunr> and it certainly can't hurt much diff --git a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn new file mode 100644 index 00000000..2df74301 --- /dev/null +++ b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn @@ -0,0 +1,142 @@ +[[!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. + + <antrik> youpi: I have found an interesting Mach problem, but I'm a bit scared of debugging it... + <antrik> (it is related to VM stuff) + <antrik> I have a memory region that is mapped by the iopl device (it's an mmio region -- graphics memory to be precise) + <antrik> when gdb tries to read that region with vm_read() (for a "print" command), it triggers a general protection trap... + <youpi> antrik: does the general protection trap kill the whole kernel or just gdb? + <antrik> kernel + <antrik> kernel: General protection trap (13), code=0 + <antrik> pmap_copy_page(41000000,49f2000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(209c1c54,41000000,1000,1,20994908) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(209c1c54,41000000,1000,20994908,2099490c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(209ba6e4,2c000,1000,0,25394ec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(209ba6e4,2c000,1000,208d303c,25394f00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(2095cfe4,208d3010,0,1fff3e48,2095cfd4) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(2095cfd4,2095cfe4,28,127ca0,0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(1024440,3,28,30,2c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x102441c + <antrik> BTW, is it useful at all to write down the paramenters as well?... + <antrik> argments I mean + <youpi> in the trace you mean? + <antrik> yes + <youpi> apparently the problem here is that the call to vm_fault_page() didn't perform its task + <youpi> which address is faulty? + <antrik> not sure what you mean + <youpi> ah shit the gpf wouldn't tell you + <youpi> does examine 49f2000 work? + <youpi> oh, wait, 4100000, that can't work + <youpi> +0 + <youpi> which physical address is your mmio at? + <antrik> haven't tried it... but I can provoke the fault again if it helps :-) + <youpi> we have the 1GB limitation issue + <antrik> oh... lemme check + <youpi> no need to, I think the problem is that + <youpi> the iopl driver should check that it's not above phys_last_addr + <antrik> it's only vm_read() that fails, though... + <antrik> the actual program I debugged in gdb works perfectly fine + <youpi> yes, but that's because it's accessing the memory in a different way + <youpi> in the case of direct reads it just uses the page table + <youpi> in the case of vm_read() it uses kernel's projection + <youpi> but in that case it's not in the kernel projection + <antrik> phys = 1090519040 + <youpi> that's it, it's beyond 1GB + <youpi> there's not much to do except changing mach's adressing organization + <antrik> yeah, that's the 0x41000000 + <antrik> hm... I guess we could make the vm_read() bail out instead of crashing?... + <youpi> yes + <youpi> but there are a lot of places like this + <antrik> still, it's not exactly fun when trying to debug a program and the kernel crashes :-) + <youpi> right :) + <antrik> I could try to add the check... if you tell me where it belongs ;-) + <youpi> antrik: it's not just one place, that's the problem + <youpi> it's all the places that call pmap_zero_page, pmap_copy_page, copy_to_phys or copy_from_phys + <youpi> and since we do want to let the iopl device create such kind of page, in principle we have to cope with them all + <youpi> pmap_zero_page should be ok, though + <youpi> the rest isn't + <antrik> is that tricky, or just a matter of doing it in all places? + + <antrik> hm... now it crashed in "normal" usage as well... + <antrik> hm... a page fault trap for a change... + <antrik> hm... now gdb tried to vm_read() something that is mapped to physical address 0x0... + <antrik> so I guess I fucked something up in the mapping code + <antrik> is it expected that such a vm_read() causes a kernel page fault, though?... + <antrik> youpi: ^ + <youpi> nope + <youpi> in principle the check for validity of the page is done earlier + <youpi> physical address 0x0 makes sense, though + <antrik> OK, here is the trace: + <antrik> Kernel page fault (14), code=0 at address 0x0 + <antrik> pmap_copy_page(0,6e54000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(20a067b0,0,1000,1,0acacec) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(20a067b0,0,1000,20acacec,20acacf0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(20a0f1c4,120d000,1000,0,253cdec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(20a0f1c4,120d000,1000,20a5703c,253cdf00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(20a52c80,20a57010,253cdf40,20ae33cc,20a52c70) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(20a52c70,20a52c80,28,20873074,20873070) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(10247d0,3,28,30,2f) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x10247ac + <antrik> seems to be exactly the same, except for the different arguments... + <antrik> hm... interesting... it *does* write something to the framebuffer, before it crashes... + <antrik> (which unfortunately makes it a bit hard to read the panic message... ;-) ) + <LarstiQ> heh :) + <antrik> wait, it must write to something else than the frame buffer as well, or else the debugger should just paint over the crap... + <antrik> or perhaps it crashes so hard that the debugger doesn't even work? ;-) + <antrik> hm... I guess the first thing I should actually do is finding out what's up with e2fsck... this make testing crashes kinda annoying :-( + <antrik> oh, "interesting"... I ran it on one of my other hurd partitions, and it complained about an endless number of files... (perhaps all) + <antrik> however, the value for the normal files was different than for the passive translator nodes + <antrik> it doesn't happen only on crashes; it seems that all passive translators that are still in use at time of shutdown (or crash) have the offending bit set in the inode + <antrik> ouch... seems it doesn't write into the framebuffer after all, but rather scribbles all over the first 4 MiB of memory -- which includes also the VGA window, before it goes on killing the kernel... + <youpi> which iopl driver are you using ? + <antrik> ? + <youpi> the one from the debian patch? + <youpi> upstream, gnumach doesn't have an iopl device any more + <antrik> I guess so... standard Debian stuff here + <antrik> oh. how does X map the memory, then? + <youpi> X does yes + <antrik> ? + <youpi> X uses the iopl() device to access the video memory, yes + <youpi> I don't know if that was what you were asking for, but that's what I meant by my answer :) + <antrik> yeah, I know how it does *currently* do it -- I stole the code from there :-) + <antrik> my question is, how is X supposed to get at the framebuffer, when there is no iopl device anymore? + <youpi> ah, I hadn't noticed the "how" word + <youpi> in Debian there is + <LarstiQ> !debian → !x? + <youpi> the clean "access device memory" interface is yet to be done + <antrik> err... that sounds like Xorg philosophy + <youpi> what, to wait for a nice interface ? + <antrik> "let's kill the old stuff, fuck regressions... maybe someone will figure out how to do it with the new stuff at some point. if not, not our problem" + <youpi> that's also a GNU philosophy + <youpi> ah, that one + <antrik> anyone know how device_map() is supposed to behave? the documentation isn't really clear... + <antrik> my understanding was then when an offset is specified, then the resulting object will be relative to that object; i.e. the offset of a later vm_map() on this object is applied on top of the object's internal offset... + <antrik> but that doesn't seem to be how it works for the iopl device, if I read the xf86 code correctly... + <antrik> yeah, the offset parameter seems a nop when doing device_map() on the iopl device diff --git a/open_issues/gnumach_i686.mdwn b/open_issues/gnumach_i686.mdwn new file mode 100644 index 00000000..b34df73b --- /dev/null +++ b/open_issues/gnumach_i686.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-05 + + <braunr> we could use a gnumach-i686 too + <pinotree> how would you compile gnumach as i686 variant btw? add + -march=.. or something like that in CFLAGS? + <braunr> yes + <braunr> at least we'll get some cmovs :) + + +## IRC, freenode, #hurd, 2012-07-07 + + <braunr> it was rejected in the past because we didn't think it would bring + real performance benefit, but it actually may diff --git a/open_issues/gnumach_integer_overflow.mdwn b/open_issues/gnumach_integer_overflow.mdwn new file mode 100644 index 00000000..2166e591 --- /dev/null +++ b/open_issues/gnumach_integer_overflow.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-04 + + <braunr> yes, we have integer overflows on resident_page_count, but + luckily, the member is rarely used diff --git a/open_issues/gnumach_kernel_threads.mdwn b/open_issues/gnumach_kernel_threads.mdwn new file mode 100644 index 00000000..9591986b --- /dev/null +++ b/open_issues/gnumach_kernel_threads.mdwn @@ -0,0 +1,23 @@ +[[!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-07-13 + + <braunr> jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ? + <jkoenig> braunr, it's the closest we can do to its command line + <braunr> doesn't it deserve something special like kernel threads in linux + ? + <braunr> so that it's actually clear that it's a special task/process + <jkoenig> you mean something like [mach root=device:hd0s1] ? + <braunr> something like that yes + <braunr> also, it would be nice if gnumach threads could actually be seen, + i don't remember if the mach interface allows it though diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn new file mode 100644 index 00000000..e5e9d2c5 --- /dev/null +++ b/open_issues/gnumach_memory_management.mdwn @@ -0,0 +1,2184 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +There is a [[!FF_project 266]][[!tag bounty]] on this task. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-04-12 + + <antrik> braunr: do you think the allocator you wrote for x15 could be used + for gnumach? and would you be willing to mentor this? :-) + <braunr> antrik: to be willing to isn't my current problem + <braunr> antrik: and yes, I think my allocator can be used + <braunr> it's a slab allocator after all, it only requires reap() and + grow() + <braunr> or mmap()/munmap() whatever you want to call it + <braunr> a backend + <braunr> antrik: although i've been having other ideas recently + <braunr> that would have more impact on our usage patterns I think + <antrik> mcsim: have you investigated how the zone allocator works and how + it's hooked into the system yet? + <braunr> mcsim: now let me give you a link + <braunr> mcsim: + http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=330436e799f322949bfd9e2fedf0475660309946;hb=HEAD + <braunr> mcsim: this is an implementation of the slab allocator i've been + working on recently + <braunr> mcsim: i haven't made it public because i reworked the per + processor layer, and this part isn't complete yet + <braunr> mcsim: you could use it as a reference for your project + <mcsim> braunr: ok + <braunr> it used to be close to the 2001 vmem paper + <braunr> but after many tests, fragmentation and accounting issues have + been found + <braunr> so i rewrote it to be closer to the linux implementation (cache + filling/draining in bukl transfers) + <braunr> bulk* + <braunr> they actually use the word draining in linux too :) + <mcsim> antrik: not complete yet. + <antrik> braunr: oh, it's unfinished? that's unfortunate... + <braunr> antrik: only the per processor part + <braunr> antrik: so it doesn't matter much for gnumach + <braunr> and it's not difficult to set up + <antrik> mcsim: hm, OK... but do you think you will have a fairly good + understanding in the next couple of days?... + <antrik> I'm asking because I'd really like to see a proposal a bit more + specific than "I'll look into things..." + <antrik> i.e. you should have an idea which things you will actually have + to change to hook up a new allocator etc. + <antrik> braunr: OK. will the interface remain unchanged, so it could be + easily replaced with an improved implementation later? + <braunr> the zone allocator in gnumach is a badly written bare object + allocator actually, there aren't many things to understand about it + <braunr> antrik: yes + <antrik> great :-) + <braunr> and the per processor part should be very close to the phys + allocator sitting next to it + <braunr> (with the slight difference that, as per cpu caches have variable + sizes, they are allocated on the free path rather than on the allocation + path) + <braunr> this is a nice trick in the vmem paper i've kept in mind + <braunr> and the interface also allows to set a "source" for caches + <antrik> ah, good point... do you think we should replace the physmem + allocator too? and if so, do it in one step, or one piece at a time?... + <braunr> no + <braunr> too many drivers currently depend on the physical allocator and + the pmap module as they are + <braunr> remember linux 2.0 drivers need a direct virtual to physical + mapping + <braunr> (especially true for dma mappings) + <antrik> OK + <braunr> the nice thing about having a configurable memory source is that + <antrik> whot do you mean by "allocated on the free path"? + <braunr> even if most caches will use the standard vm_kmem module as their + backend + <braunr> there is one exception in the vm_map module, allowing us to get + rid of either a static limit, or specific allocation code + <braunr> antrik: well, when you allocate a page, the allocator will lookup + one in a per cpu cache + <braunr> if it's empty, it fills the cache + <braunr> (called pools in my implementations) + <braunr> it then retries + <braunr> the problem in the slab allocator is that per cpu caches have + variable sizes + <braunr> so per cpu pools are allocated from their own pools + <braunr> (remember the magazine_xx caches in the output i showed you, this + is the same thing) + <braunr> but if you allocate them at allocation time, you could end up in + an infinite loop + <braunr> so, in the slab allocator, when a per cpu cache is empty, you just + fall back to the slab layer + <braunr> on the free path, when a per cpu cache doesn't exist, you allocate + it from its own cache + <braunr> this way you can't have an infinite loop + <mcsim> antrik: I'll try, but I have exams now. + <mcsim> As I understand amount of elements which could be allocated we + determine by zone initialization. And at this time memory for zone is + reserved. I'm going to change this. And make something similar to kmalloc + and vmalloc (support for pages consecutive physically and virtually). And + pages in zones consecutive always physically. + <mcsim> Am I right? + <braunr> mcsim: don't try to do that + <mcsim> why? + <braunr> mcsim: we just need a slab allocator with an interface close to + the zone allocator + <antrik> mcsim: IIRC the size of the complete zalloc map is fixed; but not + the number of elements per zone + <braunr> we don't need two allocators like kmalloc and vmalloc + <braunr> actually we just need vmalloc + <braunr> IIRC the limits are only present because the original developers + wanted to track leaks + <braunr> they assumed zones would be large enough, which isn't true any + more today + <braunr> but i didn't see any true reservation + <braunr> antrik: i'm not sure i was clear enough about the "allocation of + cpu caches on the free path" + <braunr> antrik: for a better explanation, read the vmem paper ;) + <antrik> braunr: you mean there is no fundamental reason why the zone map + has a limited maximal size; and it was only put in to catch cases where + something eats up all memory with kernel object creation?... + <antrik> braunr: I think I got it now :-) + <braunr> antrik: i'm pretty certin of it yes + <antrik> I don't see though how it is related to what we were talking + about... + <braunr> 10:55 < braunr> and the per processor part should be very close to + the phys allocator sitting next to it + <braunr> the phys allocator doesn't have to use this trick + <braunr> because pages have a fixed size, so per cpu caches all have the + same size too + <braunr> and the number of "caches", that is, physical segments, is limited + and known at compile time + <braunr> so having them statically allocated is possible + <antrik> I see + <braunr> it would actually be very difficult to have a phys allocator + requiring dynamic allocation when the dynamic allocator isn't yet ready + <antrik> hehe :-) + <mcsim> total size of all zone allocations is limited to 12 MB. And is "was + only put in to catch cases where something eats up all memory with kernel + object creation?" + <braunr> mcsim: ah right, there could be a kernel submap backing all the + zones + <braunr> but this can be increased too + <braunr> submaps are kind of evil :/ + <antrik> mcsim: I think it's actually 32 MiB or something like that in the + Debian version... + <antrik> braunr: I'm not sure I ever fully understood what the zalloc map + is... I looked through the code once, and I think I got a rough + understading, but I was still pretty uncertain about some bits. and I + don't remember the details anyways :-) + <braunr> antrik: IIRC, it's a kernel submap + <braunr> it's named kmem_map in x15 + <antrik> don't know what a submap is + <braunr> submaps are vm_map objects + <braunr> in a top vm_map, there are vm_map_entries + <braunr> these entries usually point to vm_objects + <braunr> (for the page cache) + <braunr> but they can point to other maps too + <braunr> the goal is to reduce fragmentation by isolating allocations + <braunr> this also helps reducing contention + <braunr> for exemple, on BSD, there is a submap for mbufs, so that the + network code doesn't interfere too much with other kernel allocations + <braunr> antrik: they are similar to spans in vmem, but vmem has an elegant + importing mechanism which eliminates the static limit problem + <antrik> so memory is not directly allocated from the physical allocator, + but instead from another map which in turn contains physical memory, or + something like that?... + <braunr> no, this is entirely virtual + <braunr> submaps are almost exclusively used for the kernel_map + <antrik> you are using a lot of identifies here, but I don't remember (or + never knew) what most of them mean :-( + <braunr> sorry :) + <braunr> the kernel map is the vm_map used to represent the ~1 GiB of + virtual memory the kernel has (on i386) + <braunr> vm_map objects are simple virtual space maps + <braunr> they contain what you see in linux when doing /proc/self/maps + <braunr> cat /proc/self/maps + <braunr> (linux uses entirely different names but it's roughly the same + structure) + <braunr> each line is a vm_map_entry + <braunr> (well, there aren't submaps in linux though) + <braunr> the pmap tool on netbsd is able to show the kernel map with its + submaps, but i don't have any image around + <mcsim> braunr: is limit for zones is feature and shouldn't be changed? + <braunr> mcsim: i think we shouldn't have fixed limits for zones + <braunr> mcsim: this should be part of the debugging facilities in the slab + allocator + <braunr> is this fixed limit really a major problem ? + <braunr> i mean, don't focus on that too much, there are other issues + requiring more attention + <antrik> braunr: at 12 MiB, it used to be, causing a lot of zalloc + panics. after increasing, I don't think it's much of a problem anymore... + <antrik> but as memory sizes grow, it might become one again + <antrik> that's the problem with a fixed size... + <braunr> yes, that's the issue with submaps + <braunr> but gnumach is full of those, so let's fix them by order of + priority + <antrik> well, I'm still trying to digest what you wrote about submaps :-) + <braunr> i'm downloading netbsd, so you can have a good view of all this + <antrik> so, when the kernel allocates virtual address space regions + (mostly for itself), instead of grabbing chunks of the address space + directly, it takes parts out of a pre-reserved region? + <braunr> not exactly + <braunr> both statements are true + <mcsim> antrik: only virtual addresses are reserved + <braunr> it grabs chunks of the address space directly, but does so in a + reserved region of the address space + <braunr> a submap is like a normal map, it has a start address, a size, and + is empty, then it's populated with vm_map_entries + <braunr> so instead of allocating from 3-4 GiB, you allocate from, say, + 3.1-3.2 GiB + <antrik> yeah, that's more or less what I meant... + <mcsim> braunr: I see two problems: limited zones and absence of caching. + <mcsim> with caching absence of readahead paging will be not so significant + <braunr> please avoid readahead + <mcsim> ok + <braunr> and it's not about paging, it's about kernel memory, which is + wired + <braunr> (well most of it) + <braunr> what about limited zones ? + <braunr> the whole kernel space is limited, there has to be limits + <braunr> the problem is how to handle them + <antrik> braunr: almost all. I looked through all zones once, and IIRC I + found exactly one that actually allows paging... + <braunr> currently, when you reach the limit, you have an OOM error + <braunr> antrik: yes, there are + <braunr> i don't remember which implementation does that but, when + processes haven't been active for a minute or so, they are "swapedout" + <braunr> completely + <braunr> even the kernel stack + <braunr> and the page tables + <braunr> (most of the pmap structures are destroyed, some are retained) + <antrik> that might very well be true... at least inactive processes often + show up with 0 memory use in top on Hurd + <braunr> this is done by having a pageable kernel map, with wired entries + <braunr> when the swapper thread swaps tasks out, it unwires them + <braunr> but i think modern implementations don't do that any more + <antrik> well, I was talking about zalloc only :-) + <braunr> oh + <braunr> so the zalloc_map must be pageable + <braunr> or there are two submaps ? + <antrik> not sure whether "morden implementations" includes Linux ;-) + <braunr> no, i'm talking about the bsd family only + <antrik> but it's certainly true that on Linux even inactive processes + retain some memory + <braunr> linux doesn't make any difference between processor-bound and + I/O-bound processes + <antrik> braunr: I have no idea how it works. I just remember that when + creating zones, one of the optional flags decides whether the zone is + pagable. but as I said, IIRC there is exactly one that actually is... + <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max, + zone_map_size, FALSE); + <braunr> kmem_suballoc(parent, min, max, size, pageable) + <braunr> so the zone_map isn't + <antrik> IIRC my conclusion was that pagable zones do not count in the + fixed zone map limit... but I'm not sure anymore + <braunr> zinit() has a memtype parameter + <braunr> with ZONE_PAGEABLE as a possible flag + <braunr> this is wierd :) + <mcsim> There is no any zones which use ZONE_PAGEABLE flag + <antrik> mcsim: are you sure? I think I found one... + <braunr> if (zone->type & ZONE_PAGEABLE) { + <antrik> admittedly, it is several years ago that I looked into this, so my + memory is rather dim... + <braunr> if (kmem_alloc_pageable(zone_map, &addr, ... + <braunr> calling kmem_alloc_pageable() on an unpageable submap seems wrong + <mcsim> I've greped gnumach code and there is no any zinit procedure call + with ZONE_PAGEABLE flag + <braunr> good + <antrik> hm... perhaps it was in some code that has been removed + alltogether since ;-) + <antrik> actually I think it would be pretty neat to have pageable kernel + objects... but I guess it would require considerable effort to implement + this right + <braunr> mcsim: you also mentioned absence of caching + <braunr> mcsim: the zone allocator actually is a bare caching object + allocator + <braunr> antrik: no, it's easy + <braunr> antrik: i already had that in x15 0.1 + <braunr> antrik: the problem is being sure the objects you allocate from a + pageable backing store are never used when resolving a page fault + <braunr> that's all + <antrik> I wouldn't expect that to be easy... but surely you know better + :-) + <mcsim> braunr: indeed. I was wrong. + <antrik> braunr: what is a caching object allocator?... + <braunr> antrik: ok, it's not easy + <braunr> antrik: but once you have vm_objects implemented, having pageable + kernel object is just a matter of using the right options, really + <braunr> antrik: an allocator that caches its buffers + <braunr> some years ago, the term "object" would also apply to + preconstructed buffers + <antrik> I have no idea what you mean by "caches its buffers" here :-) + <braunr> well, a memory allocator which doesn't immediately free its + buffers caches them + <mcsim> braunr: but can it return objects to system? + <braunr> mcsim: which one ? + <antrik> yeah, obviously the *implementation* of pageable kernel objects is + not hard. the tricky part is deciding which objects can be pageable, and + which need to be wired... + <mcsim> Can zone allocator return cached objects to system as in slab? + <mcsim> I mean reap() + <braunr> well yes, it does so, and it does that too often + <braunr> the caching in the zone allocator is actually limited to the + pagesize + <braunr> once page is completely free, it is returned to the vm + <mcsim> this is bad caching + <braunr> yes + <mcsim> if object takes all page than there is now caching at all + <braunr> caching by side effect + <braunr> true + <braunr> but the linux slab allocator does the same thing :p + <braunr> hm + <braunr> no, the solaris slab allocator does so + <mcsim> linux's slab returns objects only when system ask + <antrik> without preconstructed objects, is there actually any point in + caching empty slabs?... + <mcsim> Once I've changed my allocator to slab and it cached more than 1GB + of my memory) + <braunr> ok wait, need to fix a few mistakes first + <mcsim> s/ask/asks + <braunr> the zone allocator (in gnumach) actually has a garbage collector + <antrik> braunr: well, the Solaris allocator follows the slab/magazine + paper, right? so there is caching at the magazine layer... in that case + caching empty slabs too would be rather redundant I'd say... + <braunr> which is called when running low on memory, similar to the slab + allocaotr + <braunr> antrik: yes + <antrik> (or rather the paper follows the Solaris allocator ;-) ) + <braunr> mcsim: the zone allocator reap() is zone_gc() + <antrik> braunr: hm, right, there is a "collectable" flag for zones... but + I never understood what it means + <antrik> braunr: BTW, I heard Linux has yet another allocator now called + "slob"... do you happen to know what that is? + <braunr> slob is a very simple allocator for embedded devices + <mcsim> AFAIR this is just heap allocator + <braunr> useful when you have a very low amount of memory + <braunr> like 1 MiB + <braunr> yes + <antrik> just googled it :-) + <braunr> zone and slab are very similar + <antrik> sounds like a simple heap allocator + <mcsim> there is another allocator that calls slub, and it better than slab + in many cases + <braunr> the main difference is the data structures used to store slabs + <braunr> mcsim: i disagree + <antrik> mcsim: ah, you already said that :-) + <braunr> mcsim: slub is better for systems with very large amounts of + memory and processors + <braunr> otherwise, slab is better + <braunr> in addition, there are accounting issues with slub + <braunr> because of cache merging + <mcsim> ok. This strange that slub is default allocator + <braunr> well both are very good + <braunr> iirc, linus stated that he really doesn't care as long as its + works fine + <braunr> he refused slqb because of that + <braunr> slub is nice because it requires less memory than slab, while + still being as fast for most cases + <braunr> it gets slower on the free path, when the cpu performing the free + is different from the one which allocated the object + <braunr> that's a reasonable cost + <mcsim> slub uses heap for large object. Are there any tests that compare + what is better for large objects? + <antrik> well, if slub requires less memory, why do you think slab is + better for smaller systems? :-) + <braunr> antrik: smaller is relative + <antrik> mcsim: for large objects slab allocation is rather pointless, as + you don't have multiple objects in a page anyways... + <braunr> antrik: when lameter wrote slub, it was intended for systems with + several hundreds processors + <antrik> BTW, was slqb really refused only because the other ones are "good + enough"?... + <braunr> yes + <antrik> wow, that's a strange argument... + <braunr> linus is already unhappy of having "so many" allocators + <antrik> well, if the new one is better, it could replace one of the others + :-) + <antrik> or is it useful only in certain cases? + <braunr> that's the problem + <braunr> nobody really knows + <antrik> hm, OK... I guess that should be tested *before* merging ;-) + <antrik> is anyone still working on it, or was it abandonned? + <antrik> mcsim: back to caching... + <antrik> what does caching in the kernel object allocator got to do with + readahead (i.e. clustered paging)?... + <mcsim> if we cached some physical pages we don't need to find new ones for + allocating new object. And that's why there will not be a page fault. + <mcsim> antrik: Regarding kam. Hasn't he finished his project? + <antrik> err... what? + <antrik> one of us must be seriously confused + <antrik> I totally fail to see what caching of physical pages (which isn't + even really a correct description of what slab does) has to do with page + faults + <antrik> right, KAM didn't finish his project + <mcsim> If we free the physical page and return it to system we need + another one for next allocation. But if we keep it, we don't need to find + new physical page. + <mcsim> And physical page is allocated only then when page fault + occurs. Probably, I'm wrong + <antrik> what does "return to system" mean? we are talking about the + kernel... + <antrik> zalloc/slab are about allocating kernel objects. this doesn't have + *anything* to do with paging of userspace processes + <antrik> only thing the have in common is that they need to get pages from + the physical page allocator. but that's yet another topic + <mcsim> Under "return to system" I mean ability to use this page for other + needs. + <braunr> mcsim: consider kernel memory to be wired + <braunr> here, return to system means releasing a page back to the vm + system + <braunr> the vm_kmem module then unmaps the physical page and free its + virtual address in the kernel map + <mcsim> ok + <braunr> antrik: the problem with new allocators like slqb is that it's + very difficult to really know if they're better, even with extensive + testing + <braunr> antrik: there are papers (like wilson95) about the difficulties in + making valuable results in this field + <braunr> see + http://www.sceen.net/~rbraun/dynamic_storage_allocation_a_survey_and_critical_review.pdf + <mcsim> how can be allocated physically continuous object now? + <braunr> mcsim: rephrase please + <mcsim> what is similar to kmalloc in Linux to gnumach? + <braunr> i know memory is reserved for dma in a direct virtual to physical + mapping + <braunr> so even if the allocation is done similarly to vmalloc() + <braunr> the selected region of virtual space maps physical memory, so + memory is physically contiguous too + <braunr> for other allocation types, a block large enough is allocated, so + it's contiguous too + <mcsim> I don't clearly understand. If we have fragmentation in physical + ram, so there aren't 2 free pages in a row, but there are able apart, we + can't to allocate these 2 pages along? + <braunr> no + <braunr> but every system has this problem + <mcsim> But since we have only 12 or 32 MB of memory the problem becomes + more significant + <braunr> you're confusing virtual and physical memory + <braunr> those 32 MiB are virtual + <braunr> the physical pages backing them don't have to be contiguous + <mcsim> Oh, indeed + <mcsim> So the only problem are limits? + <braunr> and performance + <braunr> and correctness + <braunr> i find the zone allocator badly written + <braunr> antrik: mcsim: here is the content of the kernel pmap on NetBSD + (which uses a virtual memory system close to the Mach VM) + <braunr> antrik: mcsim: http://www.sceen.net/~rbraun/pmap.out + +[[pmap.out]] + + <braunr> you can see the kmem_map (which is used for most general kernel + allocations) is 128 MiB large + <braunr> actually it's not the kernel pmap, it's the kernel_map + <antrik> braunr: why is it called pmap.out then? ;-) + <braunr> antrik: because the tool is named pmap + <braunr> for process map + <braunr> it also exists under Linux, although direct access to + /proc/xx/maps gives more info + <mcsim> braunr: I've said that this is kernel_map. Can I see kernel_map for + Linux? + <braunr> mcsim: I don't know how to do that + <mcsim> s/I've/You've + <braunr> but Linux doesn't have submaps, and uses a direct virtual to + physical mapping, so it's used differently + <antrik> how are things (such as zalloc zones) entered into kernel_map? + <braunr> in zone_init() you have + <braunr> zone_map = kmem_suballoc(kernel_map, &zone_min, &zone_max, + zone_map_size, FALSE); + <braunr> so here, kmem_map is named zone_map + <braunr> then, in zalloc() + <braunr> kmem_alloc_wired(zone_map, &addr, zone->alloc_size) + <antrik> so, kmem_alloc just deals out chunks of memory referenced directly + by the address, and without knowing anything about the use? + <braunr> kmem_alloc() gives virtual pages + <braunr> zalloc() carves them into buffers, as in the slab allocator + <braunr> the difference is essentially the lack of formal "slab" object + <braunr> which makes the zone code look like a mess + <antrik> so kmem_suballoc() essentially just takes a bunch of pages from + the main kernel_map, and uses these to back another map which then in + turn deals out pages just like the main kernel_map? + <braunr> no + <braunr> kmem_suballoc creates a vm_map_entry object, and sets its start + and end address + <braunr> and creates a vm_map object, which is then inserted in the new + entry + <braunr> maybe that's what you meant with "essentially just takes a bunch + of pages from the main kernel_map" + <braunr> but there really is no allocation at this point + <braunr> except the map entry and the new map objects + <antrik> well, I'm trying to understand how kmem_alloc() manages things. so + it has map_entry structures like the maps of userspace processes? do + these also reference actual memory objects? + <braunr> kmem_alloc just allocates virtual pages from a vm_map, and backs + those with physical pages (unless the user requested pageable memory) + <braunr> it's not "like the maps of userspace processes" + <braunr> these are actually the same structures + <braunr> a vm_map_entry can reference a memory object or a kernel submap + <braunr> in netbsd, it can also referernce nothing (for pure wired kernel + memory like the vm_page array) + <braunr> maybe it's the same in mach, i don't remember exactly + <braunr> antrik: this is actually very clear in vm/vm_kern.c + <braunr> kmem_alloc() creates a new kernel object for the allocation + <braunr> allocates a new entry (or uses a previous existing one if it can + be extended) through vm_map_find_entry() + <braunr> then calls kmem_alloc_pages() to back it with wired memory + <antrik> "creates a new kernel object" -- what kind of kernel object? + <braunr> kmem_alloc_wired() does roughly the same thing, except it doesn't + need a new kernel object because it knows the new area won't be pageable + <braunr> a simple vm_object + <braunr> used as a container for anonymous memory in case the pages are + swapped out + <antrik> vm_object is the same as memory object/pager? or yet something + different? + <braunr> antrik: almost + <braunr> antrik: a memory_object is the user view of a vm_object + <braunr> as in the kernel/user interfaces used by external pagers + <braunr> vm_object is a more internal name + <mcsim> Is fragmentation a big problem in slab allocator? + <mcsim> I've tested it on my computer in Linux and for some caches it + reached 30-40% + <antrik> well, fragmentation is a major problem for any allocator... + <antrik> the original slab allocator was design specifically with the goal + of reducing fragmentation + <antrik> the revised version with the addition of magazines takes a step + back on this though + <antrik> have you compared it to slub? would be pretty interesting... + <mcsim> I have an idea how can it be decreased, but it will hurt by + performance... + <mcsim> antrik: no I haven't, but there will be might the same, I think + <mcsim> if each cache will handle two types of object: with sizes that will + fit cache sizes (or I bit smaller) and with sizes which are much smaller + than maximal cache size. For first type of object will be used standard + slab allocator and for latter type will be used (within page) heap + allocator. + <mcsim> I think that than fragmentation will be decreased + <antrik> not at all. heap allocator has much worse fragmentation. that's + why slab allocator was invented + <antrik> the problem is that in a long-running program (such an the + kernel), objects tend to have vastly varying lifespans + <mcsim> but we use heap only for objects of specified sizes + <antrik> so often a few old objects will keep a whole page hostage + <mcsim> for example for 32 byte cache it could be 20-28 byte objects + <antrik> that's particularily visible in programs such as firefox, which + will grow the heap during use even though actual needs don't change + <antrik> the slab allocator groups objects in a fashion that makes it more + likely adjacent objects will be freed at similar times + <antrik> well, that's pretty oversimplyfied, but I hope you get the + idea... it's about locality + <mcsim> I agree, but I speak not about general heap allocation. We have + many heaps for objects with different sizes. + <mcsim> Could it be better? + <antrik> note that this has been a topic of considerable research. you + shouldn't seek to improve the actual algorithms -- you would have to read + up on the existing research at least before you can contribute anything + to the field :-) + <antrik> how would that be different from the slab allocator? + <mcsim> slab will allocate 32 byte for both 20 and 32 byte requests + <mcsim> And if there was request for 20 bytes we get 12 unused + <antrik> oh, you mean the implementation of the generic allocator on top of + slabs? well, that might not be optimal... but it's not an often used case + anyways. mostly the kernel uses constant-sized objects, which get their + own caches with custom tailored size + <antrik> I don't think the waste here matters at all + <mcsim> affirmative. So my idea is useless. + <antrik> does the statistic you refer to show the fragmentation in absolute + sizes too? + <mcsim> Can you explain what is absolute size? + <mcsim> I've counted what were requested (as parameter of kmalloc) and what + was really allocated (according to best fit cache size). + <antrik> how did you get that information? + <mcsim> I simply wrote a hook + <antrik> I mean total. i.e. how many KiB or MiB are wasted due to + fragmentation alltogether + <antrik> ah, interesting. how does it work? + <antrik> BTW, did you read the slab papers? + <mcsim> Do you mean articles from lwn.net? + <antrik> no + <antrik> I mean the papers from the Sun hackers who invented the slab + allocator(s) + <antrik> Bonwick mostly IIRC + <mcsim> Yes + <antrik> hm... then you really should know the rationale behind it... + <mcsim> There he says about 11% percent of memory waste + <antrik> you didn't answer my other questions BTW :-) + <mcsim> I've corrupted kernel tree with patch, and tomorrow I'm going to + read myself up for exam (I have it on Thursday). But than I'll send you a + module which I've used for testing. + <antrik> OK + <mcsim> I can send you module now, but it will not work without patch. + <mcsim> It would be better to rewrite it using debugfs, but when I was + writing this test I didn't know about trace_* macros + + +# IRC, freenode, #hurd, 2011-04-15 + + <mcsim> There is a hack in zone_gc when it allocates and frees two + vm_map_kentry_zone elements to make sure the gc will be able to allocate + two in vm_map_delete. Isn't it better to allocate memory for these + entries statically? + <youpi> mcsim: that's not the point of the hack + <youpi> mcsim: the point of the hack is to make sure vm_map_delete will be + able to allocate stuff + <youpi> allocating them statically will just work once + <youpi> it may happen several times that vm_map_delete needs to allocate it + while it's empty (and thus zget_space has to get called, leading to a + hang) + <youpi> funnily enough, the bug is also in macos X + <youpi> it's still in my TODO list to manage to find how to submit the + issue to them + <braunr> really ? + <braunr> eh + <braunr> is that because of map entry splitting ? + <youpi> it's git commit efc3d9c47cd744c316a8521c9a29fa274b507d26 + <youpi> braunr: iirc something like this, yes + <braunr> netbsd has this issue too + <youpi> possibly + <braunr> i think it's a fundamental problem with the design + <braunr> people think of munmap() as something similar to free() + <braunr> whereas it's really unmap + <braunr> with a BSD-like VM, unmap can easily end up splitting one entry in + two + <braunr> but your issue is more about harmful recursion right ? + <youpi> I don't remember actually + <youpi> it's quite some time ago :) + <braunr> ok + <braunr> i think that's why i have "sources" in my slab allocator, the + default source (vm_kern) and a custom one for kernel map entries + + +# IRC, freenode, #hurd, 2011-04-18 + + <mcsim> braunr: you've said that once page is completely free, it is + returned to the vm. + <mcsim> who else, besides zone_gc, can return free pages to the vm? + <braunr> mcsim: i also said i was wrong about that + <braunr> zone_gc is the only one + + +# IRC, freenode, #hurd, 2011-04-19 + + <braunr> antrik: mcsim: i added back a new per-cpu layer as planned + <braunr> + http://git.sceen.net/rbraun/libbraunr.git/?a=blob;f=mem.c;h=c629b2b9b149f118a30f0129bd8b7526b0302c22;hb=HEAD + <braunr> mcsim: btw, in mem_cache_reap(), you can clearly see there are two + loops, just as in zone_gc, to reduce contention and avoid deadlocks + <braunr> this is really common in memory allocators + + +# IRC, freenode, #hurd, 2011-04-23 + + <mcsim> I've looked through some allocators and all of them use different + per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but + still multiprocessing must be kept in mind. So, what do you think what + kind of cpu caches is better? As for me I like variant with only per-cpu + caches (like in slqb). + <antrik> mcsim: well, have you looked at the allocator braunr wrote + himself? :-) + <antrik> I'm not sure I suggested that explicitly to you; but probably it + makes most sense to use that in gnumach + + +# IRC, freenode, #hurd, 2011-04-24 + + <mcsim> antrik: Yes, I have. He uses both global and per cpu caches. But he + also suggested to look through slqb, where there are only per cpu + caches.\ + <braunr> i don't remember slqb in detail + <braunr> what do you mean by "only per-cpu caches" ? + <braunr> a whole slab sytem for each cpu ? + <mcsim> I mean that there are no global queues in caches, but there are + special queues for each cpu. + <mcsim> I've just started investigating slqb's code, but I've read an + article on lwn about it. And I've read that it is used for zen kernel. + <braunr> zen ? + <mcsim> Here is this article http://lwn.net/Articles/311502/ + <mcsim> Yes, this is linux kernel with some patches which haven't been + approved to torvald's tree + <mcsim> http://zen-kernel.org/ + <braunr> i see + <braunr> well it looks nice + <braunr> but as for slub, the problem i can see is cross-CPU freeing + <braunr> and I think nick piggins mentions it + <braunr> piggin* + <braunr> this means that sometimes, objects are "burst-free" from one cpu + cache to another + <braunr> which has the same bad effects as in most other allocators, mainly + fragmentation + <mcsim> There is a special list for freeing object allocated for another + CPU + <mcsim> And garbage collector frees such object on his own + <braunr> so what's your question ? + <mcsim> It is described in the end of article. + <mcsim> What cpu-cache policy do you think is better to implement? + <braunr> at this point, any + <braunr> and even if we had a kernel that perfectly supports + multiprocessor, I wouldn't care much now + <braunr> it's very hard to evaluate such allocators + <braunr> slqb looks nice, but if you have the same amount of fragmentation + per slab as other allocators do (which is likely), you have tat amount of + fragmentation multiplied by the number of processors + <braunr> whereas having shared queues limit the problem somehow + <braunr> having shared queues mean you have a bit more contention + <braunr> so, as is the case most of the time, it's a tradeoff + <braunr> by the way, does pigging say why he "doesn't like" slub ? :) + <braunr> piggin* + <mcsim> http://lwn.net/Articles/311093/ + <mcsim> here he describes what slqb is better. + <braunr> well it doesn't describe why slub is worse + <mcsim> but not very particularly + <braunr> except for order-0 allocations + <braunr> and that's a form of fragmentation like i mentioned above + <braunr> in mach those problems have very different impacts + <braunr> the backend memory isn't physical, it's the kernel virtual space + <braunr> so the kernel allocator can request chunks of higher than order-0 + pages + <braunr> physical pages are allocated one at a time, then mapped in the + kernel space + <mcsim> Doesn't order of page depend on buffer size? + <braunr> it does + <mcsim> And why does gnumach allocates higher than order-0 pages more? + <braunr> why more ? + <braunr> i didn't say more + <mcsim> And why in mach those problems have very different impact? + <braunr> ? + <braunr> i've just explained why :) + <braunr> 09:37 < braunr> physical pages are allocated one at a time, then + mapped in the kernel space + <braunr> "one at a time" means order-0 pages, even if you allocate higher + than order-0 chunks + <mcsim> And in Linux they allocated more than one at time because of + prefetching page reading? + <braunr> do you understand what virtual memory is ? + <braunr> linux allocators allocate "physical memory" + <braunr> mach kernel allocator allocates "virtual memory" + <braunr> so even if you allocate a big chunk of virtual memory, it's backed + by order-0 physical pages + <mcsim> yes, I understand this + <braunr> you don't seem to :/ + <braunr> the problem of higher than order-0 page allocations is + fragmentation + <braunr> do you see why ? + <mcsim> yes + <braunr> so + <braunr> fragmentation in the kernel space is less likely to create issues + than it does in physical memory + <braunr> keep in mind physical memory is almost always full because of the + page cache + <braunr> and constantly under some pressure + <braunr> whereas the kernel space is mostly empty + <braunr> so allocating higher then order-0 pages in linux is more dangerous + than it is in Mach or BSD + <mcsim> ok + <braunr> on the other hand, linux focuses pure performance, and not having + to map memory means less operations, less tlb misses, quicker allocations + <braunr> the Mach VM must map pages "one at a time", which can be expensive + <braunr> it should be adapted to handle multiple page sizes (e.g. 2 MiB) so + that many allocations can be made with few mappings + <braunr> but that's not easy + <braunr> as always: tradeoffs + <mcsim> There are other benefits of physical allocating. In big DMA + transfers can be needed few continuous physical pages. How does mach + handles such cases? + <braunr> gnumach does that awfully + <braunr> it just reserves the whole DMA-able memory and uses special + allocation functions on it, IIRC + <braunr> but kernels which have a MAch VM like memory sytem such as BSDs + have cleaner methods + <braunr> NetBSD provides a function to allocate contiguous physical memory + <braunr> with many constraints + <braunr> FreeBSD uses a binary buddy system like Linux + <braunr> the fact that the kernel allocator uses virtual memory doesn't + mean the kernel has no mean to allocate contiguous physical memory ... + + +# IRC, freenode, #hurd, 2011-05-02 + + <braunr> hm nice, my allocator uses less memory than glibc (squeeze + version) on both 32 and 64 bits systems + <braunr> the new per-cpu layer is proving effective + <neal> braunr: Are you reimplementation malloc? + <braunr> no + <braunr> it's still the slab allocator for mach, but tested in userspace + <braunr> so i wrote malloc wrappers + <neal> Oh. + <braunr> i try to heavily test most of my code in userspace now + <neal> it's easier :-) + <neal> I agree + <braunr> even the physical memory allocator has been implemented this way + <neal> is this your mach version? + <braunr> virtual memory allocation will follow + <neal> or are you working on gnu mach? + <braunr> for now it's my version + <braunr> but i intend to spend the summer working on ipc port names + management + +[[rework_gnumach_IPC_spaces]]. + + <braunr> and integrate the result in gnu mach + <neal> are you keeping the same user-space API? + <neal> Or are you experimenting with something new? + <antrik> braunr: to be fair, it's not terribly hard to use less memory than + glibc :-) + <braunr> yes + <braunr> antrik: well ptmalloc3 received some nice improvements + <braunr> neal: the goal is to rework some of the internals only + <braunr> neal: namely, i simply intend to replace the splay tree with a + radix tree + <antrik> braunr: the glibc allocator is emphasising performace, unlike some + other allocators that trade some performance for much better memory + utilisation... + <antrik> ptmalloc3? + <braunr> that's the allocator used in glibc + <braunr> http://www.malloc.de/en/ + <antrik> OK. haven't seen any recent numbers... the comparision I have in + mind is many years old... + <braunr> i also made some additions to my avl and red-black trees this week + end, which finally make them suitable for almost all generic uses + <braunr> the red-black tree could be used in e.g. gnu mach to augment the + linked list used in vm maps + <braunr> which is what's done in most modern systems + <braunr> it could also be used to drop the overloaded (and probably over + imbalanced) page cache hash table + + +# IRC, freenode, #hurd, 2011-05-03 + + <mcsim> antrik: How should I start porting? Have I just include rbraun's + allocator to gnumach and make it compile? + <antrik> mcsim: well, basically yes I guess... but you will have to look at + the code in question first before we know anything more specific :-) + <antrik> I guess braunr might know better how to start, but he doesn't + appear to be here :-( + <braunr> mcsim: you can't juste put my code into gnu mach and make it run, + it really requires a few careful changes + <braunr> mcsim: you will have to analyse how the current zone allocator + interacts with regard to locking + <braunr> if it is used in interrupt handlers + <braunr> what kind of locks it should use instead of the pthread stuff + available in userspace + <braunr> you will have to change the reclamiing policy, so that caches are + reaped on demand + <braunr> (this basically boils down to calling the new reclaiming function + instead of zone_gc()) + <braunr> you must be careful about types too + <braunr> there is work to be done ;) + <braunr> (not to mention the obvious about replacing all the calls to the + zone allocator, and testing/debugging afterwards) + + +# IRC, freenode, #hurd, 2011-07-14 + + <braunr> can you make your patch available ? + <mcsim> it is available in gnumach repository at savannah + <mcsim> tree mplaneta/libbraunr/master + <braunr> mcsim: i'll test your branch + <mcsim> ok. I'll give you a link in a minute + <braunr> hm why balloc ? + <mcsim> Braun's allocator + <braunr> err + <braunr> + http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD + <braunr> mcsim: this is the interface i had in mind for a kernel version :) + <braunr> very similar to the original slab allocator interface actually + <braunr> well, you've been working + <mcsim> But I have a problem with this patch. When I apply it to gnumach + code from debian repository. I have to make a change in file ramdisk.c + with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c + <mcsim> because in git repository there is no such file + <braunr> mcsim: how do you configure the kernel before building ? + <braunr> mcsim: you should keep in touch more often i think, so that you + get feedback from us and don't spend too much time "off course" + <mcsim> I didn't configure it. I just run dpkg-buildsource -b. + <braunr> oh you build the debian package + <braunr> well my version was by configure --enable-kdb --enable-rtl8139 + <braunr> and it seems stuck in an infinite loop during bootstrap + <mcsim> and printf doesn't work. The first function called by c_boot_entry + is printf(version). + <braunr> mcsim: also, you're invited to get the x15mach version of my + files, which are gplv2+ licensed + <braunr> be careful of my macros.h file, it can conflict with the + macros_help.h file from gnumach iirc + <mcsim> There were conflicts with MACRO_BEGIN and MACRO_END. But I solved + it + <braunr> ok + <braunr> it's tricky + <braunr> mcsim: try to find where the first use of the allocator is made + + +# IRC, freenode, #hurd, 2011-07-22 + + <mcsim> braunr, hello. Kernel with your allocator already compiles and + runs. There still some problems, but, certainly, I'm on the final stage + already. I hope I'll finish in a few days. + <tschwinge> mcsim: Oh, cool! Have you done some measurements already? + <mcsim> Not yet + <tschwinge> OK. + <tschwinge> But if it able to run a GNU/Hurd system, then that already is + something, a big milestone! + <braunr> nice + <braunr> although you'll probably need to tweak the garbage collecting + process + <mcsim> tschwinge: thanks + <mcsim> braunr: As back-end for allocating memory I use + kmem_alloc_wired. But in zalloc was an opportunity to use as back-end + kmem_alloc_pageable. Although there was no any zone that used + kmem_alloc_pageable. Do I need to implement this functionality? + <braunr> mcsim: do *not* use kmem_alloc_pageable() + <mcsim> braunr: Ok. This is even better) + <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel + vm object, which means all kernel memory is wired and unmanaged + <braunr> making it fast and safe + <braunr> pageable kernel memory was useful back when RAM was really scarce + <braunr> 20 years ago + <braunr> but it's a source of deadlock + <mcsim> Indeed. I'll won't use kmem_alloc_pageable. + + +# IRC, freenode, #hurd, 2011-08-09 + + < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in + one of your commits ? + < braunr> mcsim: don't use spin_lock_t as a member of another structure + < mcsim> braunr: I confused with types in *_verify functions, so they + didn't work. Than I fixed it in the commit you mentioned. + < braunr> in gnumach, most types are actually structure pointers + < braunr> use simple_lock_data_t + < braunr> mcsim: ok + < mcsim> > use simple_lock_data_t + < mcsim> braunr: ok + < braunr> mcsim: don't make too many changes to the code base, and if + you're unsure, don't hesitate to ask + < braunr> also, i really insist you rename the allocator, as done in x15 + for example + (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of + a name based on mine :/ + < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the + allocator. + < braunr> other than that, it's nice to see progress + < braunr> although again, it would be better with some reports along + < braunr> i won't be present at the meeting tomorrow unfortunately, but you + should use those to report the status of your work + < mcsim> braunr: You've said that I have to tweak gc process. Did you mean + to call mem_gc() when physical memory ends instead of calling it every x + seconds? Or something else? + < braunr> there are multiple topics, alhtough only one that really matters + < braunr> study how zone_gc was called + < braunr> reclaiming memory should happen when there is pressure on the VM + subsystem + < braunr> but it shouldn't happen too ofte, otherwise there is trashing + < braunr> and your caches become mostly useless + < braunr> the original slab allocator uses a 15-second period after a + reclaim during which reclaiming has no effect + < braunr> this allows having a somehow stable working set for this duration + < braunr> the linux slab allocator uses 5 seconds, but has a more + complicated reclaiming mechanism + < braunr> it releases memory gradually, and from reclaimable caches only + (dentry for example) + < braunr> for x15 i intend to implement the original 15 second interval and + then perform full reclaims + < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than + once a second. + < mcsim> In balloc I've changed interval to once in 15 seconds. + < braunr> don't use the code as it is + < braunr> the version you've based your work on was meant for userspace + < braunr> where there isn't memory pressure + < braunr> so a timer is used to trigger reclaims at regular intervals + < braunr> it's different in a kernel + < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a + second ? + < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks + if second is passed. + < braunr> where ? + < mcsim> Than zone_gc can be called. + < braunr> ah ok, it's in zaclloc.c then + < braunr> zalloc.c + < braunr> yes this function is fine + < mcsim> so old gc didn't consider vm pressure. Or I missed something. + < braunr> it did + < mcsim> how? + < braunr> well, it's called by the pageout daemon + < braunr> under memory pressure + < braunr> so it's fine + < mcsim> so if mem_gc is called by pageout daemon is it fine? + < braunr> it must be changed to do something similar to what + consider_zone_gc does + < mcsim> It does. mem_gc does the same work as consider_zone_gc and + zone_gc. + < braunr> good + < mcsim> so gc process is fine? + < braunr> should be + < braunr> i see mem.c only includes mem.h, which then includes other + headers + < braunr> don't do that + < braunr> always include all the headers you need where you need them + < braunr> if you need avltree.h in both mem.c and mem.h, include it in both + files + < braunr> and by the way, i recommend you use the red black tree instead of + the avl type + < braunr> (it's the same interface so it shouldn't take long) + < mcsim> As to report. If you won't be present at the meeting, I can tell + you what I have to do now. + < braunr> sure + < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for + the userspace version only + < braunr> GPLv2+ actually + < braunr> hm you don't need list.c + < braunr> it would only add dead code + < braunr> "Zone for dynamical allocator", don't mix terms + < braunr> this comment refers to a vm_map, so call it a map + < mcsim> 1. Change constructor for kentry_alloc_cache. + < mcsim> 2. Make measurements. + < mcsim> + + < mcsim> 3. Use simple_lock_data_t + < mcsim> 4. Replace license + < braunr> kentry_alloc_cache <= what is that ? + < braunr> cache for kernel map entries in vm_map ? + < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as + there is no kernel preemption + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL + times a second. + < braunr> " + < mcsim> sorry. I meant vm_map_kentry_cache + < braunr> hm nothing actually about this comment + < braunr> mcsim: ok + < braunr> yes kernel map entries need special handling + < braunr> i don't know how it's done in gnumach though + < braunr> static preallocation ? + < mcsim> yes + < braunr> that's ugly :p + < mcsim> but it uses dynamic allocation further even for vm_map kernel + entries + < braunr> although such bootstrapping issues are generally difficult to + solve elegantly + < braunr> ah + < mcsim> now I use only static allocation, but I'll add dynamic allocation + too + < braunr> when you have time, mind the coding style (convert everything to + gnumach style, which mostly implies using tabs instead of 4-spaces + indentation) + < braunr> when you'll work on dynamic allocation for the kernel map + entries, you may want to review how it's done in x15 + < braunr> the mem_source type was originally intended for that purpose, but + has slightly changed once the allocator was adapted to work in my kernel + < mcsim> ok + < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED + < braunr> and it is zcram()'ed immediately after + < braunr> so you can consider it a statically allocated zone + < braunr> in x15 i use another strategy: there is a special kernel submap + named kentry_map which contains only one map entry (statically allocated) + < braunr> this map is the backend (mem_source) for the kentry_cache + < braunr> the kentry_cache is created with a special flag that tells it + memory can't be reclaimed + < braunr> when the cache needs to grow, the single map entry is extended to + cover the allocated memory + < braunr> it's similar to the way pmap_growkernel() works for kernel page + table pages + < braunr> (and is actually based on that idea) + < braunr> it's a compromise between full static and dynamic allocation + types + < braunr> the advantage is that the allocator code can be used (so there is + no need for a special allocator like in netbsd) + < braunr> the drawback is that some resources can never be returned to + their source (and under peaks, the amount of unfreeable resources could + become large, but this is unexpected) + < braunr> mcsim: for now you shouldn't waste your time with this + < braunr> i see the number of kernel map entries is fixed at 256 + < braunr> and i've never seen the kernel use more than around 30 entries + < mcsim> Do you think that I have to left this problem to the end? + < braunr> yes + + +# IRC, freenode, #hurd, 2011-08-11 + + < mcsim> braunr: Hello. Can you give me an advice how can I make + measurements better? + < braunr> mcsim: what kind of measurements + < mcsim> braunr: How much is your allocator better than zalloc. + < braunr> slightly :p + < braunr> that's why i never took the time to put it in gnumach + < mcsim> braunr: Just I thought that there are some rules or + recommendations of such measurements. Or I can do them any way I want? + < braunr> mcsim: i don't know + < braunr> mcsim: benchmarking is an art of its own, and i don't even know + how to use the bits of profiling code available in gnumach (if it still + works) + < antrik> mcsim: hm... are you saying you already have a running system + with slab allocator?... :-) + < braunr> mcsim: the main advantage i can see is the removal of many + arbitrary hard limits + < mcsim> antrik: yes + < antrik> \o/ + < antrik> nice work! + < braunr> :) + < braunr> the cpu layer should also help a bit, but it's hard to measure + < braunr> i guess it could be seen on the ipc path for very small buffers + < mcsim> antrik: Thanks. But I still have to 1. Change constructor for + kentry_alloc_cache. and 2. Make measurements. + < braunr> and polish the whole thing :p + < antrik> mcsim: I'm not sure this can be measured... the performance + differente in any real live usage is probably just a few percent at most + -- it's hard to construct a benchmark giving enough precision so it's not + drowned in noise... + < antrik> perhaps it conserves some memory -- but that too would be hard to + measure I fear + < braunr> yes + < braunr> there *should* be better allocation times, less fragmentation, + better accounting ... :) + < braunr> and no arbitrary limits ! + < antrik> :-) + < braunr> oh, and the self debugging features can be nice too + < mcsim> But I need to prove that my work wasn't useless + < braunr> well it wasn't, but that's hard to measure + < braunr> it's easy to prove though, since there are additional features + that weren't present in the zone allocator + < mcsim> Ok. If there are some profiling features in gnumach can you give + me a link with their description? + < braunr> mcsim: sorry, no + < braunr> mcsim: you could still write the basic loop test, which counts + the number of allocations performed in a fixed time interval + < braunr> but as it doesn't match many real life patterns, it won't be very + useful + < braunr> and i'm afraid that if you consider real life patterns, you'll + see how negligeable the improvement can be compared to other operations + such as memory copies or I/O (ouch) + < mcsim> Do network drivers use this allocator? + < mcsim> ok. I'll scrape up some test and than I'll report results. + + +# IRC, freenode, #hurd, 2011-08-26 + + < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in + linux for gnumach? + < mcsim> Or how can I determine memory map if I know address? I need this + for vm_map_copyin + < guillem> mcsim: vm_map_lookup_entry? + < mcsim> guillem: but I need to transmit map to this function and it will + return an entry which contains specified address. + < mcsim> And I don't know what map have I transmit. + < mcsim> I need to transfer static array from kernel to user. What map + contains static data? + < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large + chunks of data are transferred as out-of-line data in IPC messages + (i.e. using VM magic) + < mcsim> antrik: can you give me an example? I just found using + vm_map_copyin in host_zone_info. + < antrik> no idea what vm_map_copyin is to be honest... + + +# IRC, freenode, #hurd, 2011-08-27 + + < braunr> mcsim: the primitives are named copyin/copyout, and they are used + for messages with inline data + < braunr> or copyinmsg/copyoutmsg + < braunr> vm_map_copyin/out should be used for chunks larger than a page + (or roughly a page) + < braunr> also, when writing to a task space, see which is better suited: + vm_map_copyout or vm_map_copy_overwrite + < mcsim> braunr: and what will be src_map for vm_map_copyin/out? + < braunr> the caller map + < braunr> which you can get with current_map() iirc + < mcsim> braunr: thank you + < braunr> be careful not to leak anything in the transferred buffers + < braunr> memset() to 0 if in doubt + < mcsim> braunr:ok + < braunr> antrik: vm_map_copyin() is roughly vm_read() + < antrik> braunr: what is it used for? + < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have + copy_{from,to}_user -- instead, large chunks of data are transferred as + out-of-line data in IPC messages (i.e. using VM magic) + < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy* + functions + < antrik> braunr: oh, you mean it doesn't actually copy data, but only page + table entries? if so, that's *not* really comparable to + copy_{from,to}_user()... + + +# IRC, freenode, #hurd, 2011-08-28 + + < braunr> antrik: the equivalent of copy_{from,to}_user are + copy{in,out}{,msg} + < braunr> antrik: but when the data size is about a page or more, it's + better not to copy, of course + < antrik> braunr: it's actually not clear at all that it's really better to + do VM magic than to copy... + + +# IRC, freenode, #hurd, 2011-08-29 + + < braunr> antrik: at least, that used to be the general idea, and with a + simpler VM i suspect it's still true + < braunr> mcsim: did you progress on your host_zone_info replacement ? + < braunr> mcsim: i think you should stick to what the original + implementation did + < braunr> which is making an inline copy if caller provided enough space, + using kmem_alloc_pageable otherwise + < braunr> specify ipc_kernel_map if using kmem_alloc_pageable + < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is + it worse? + < mcsim> braunr: host_zone_info replacement is pushed to savannah + repository. + < braunr> mcsim: i'll have a look + < mcsim> braunr: I've pushed one more commit just now, which has attitude + to host_zone_info. + < braunr> mem_alloc_early_init should be renamed mem_bootstrap + < mcsim> ok + < braunr> mcsim: i don't understand your call to kmem_free + < mcsim> braunr: It shouldn't be there? + < braunr> why should it be there ? + < braunr> you're freeing what the copy object references + < braunr> it's strange that it even works + < braunr> also, you shouldn't pass infop directly as the copy object + < braunr> i guess you get a warning for that + < braunr> do what the original code does: use an intermediate copy object + and a cast + < mcsim> ok + < braunr> another error (without consequence but still, you should mind it) + < braunr> simple_lock(&mem_cache_list_lock); + < braunr> [...] + < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size); + < braunr> you can't hold simple locks while allocating memory + < braunr> read how the original implementation works around this + < mcsim> ok + < braunr> i guess host_zone_info assumes the zone list doesn't change much + while unlocked + < braunr> or that's it's rather unimportant since it's for debugging + < braunr> a strict snapshot isn't required + < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++; + < braunr> you should really use two separate lines for readability + < braunr> also, instead of counting each time, you could just maintain a + global counter + < braunr> mcsim: use strncpy instead of strcpy for the cache names + < braunr> not to avoid overflow but rather to clear the unused bytes at the + end of the buffer + < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor + issue + < braunr> you're handing off debugging data to a userspace application + < braunr> a rather dull reporting tool in most cases, which doesn't require + wired down memory + < braunr> so in order to better use available memory, pageable memory + should be used + < braunr> in the future i guess it could become a not-so-minor issue though + < mcsim> ok. I'll fix it + < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on + ? + < braunr> MEM_CF_VERIFY actually + < mcsim1> yes. + < braunr> oh + < braunr> nothing wrong + < braunr> ? + < mcsim1> it is always set + < braunr> ok + < braunr> ah, you set it in macros.h .. + < braunr> don't + < braunr> put it in mem.c if you want, or better, make it a compile-time + option + < braunr> macros.h is a tiny macro library, it shouldn't define such + unrelated options + < mcsim1> ok. + < braunr> mcsim1: did you try fault injection to make sure the checking + code actually works and how it behaves when an error occurs ? + < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h + with mem.c + < braunr> yes that would simplify things + < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and + panic occurred. + < braunr> very good + < braunr> have you progressed concerning the measurements you wanted to do + ? + < mcsim1> not much. + < braunr> ok + < mcsim1> I think they will be ready in a few days. + < antrik> what measurements are these? + < mcsim1> braunr: What maximal size for static data and stack in kernel? + < braunr> what do you mean ? + < braunr> kernel stacks are one page if i'm right + < braunr> static data (rodata+data+bss) are limited by grub bugs only :) + < mcsim1> braunr: probably they are present, because when I created too big + array I couldn't boot kernel + < braunr> local variable or static ? + < mcsim1> static + < braunr> how large ? + < mcsim1> 4Mb + < braunr> hm + < braunr> it's not a grub bug then + < braunr> i was able to embed as much as 32 MiB in x15 while doing this + kind of tests + < braunr> I guess it's the gnu mach boot code which only preallocates one + page for the initial kernel mapping + < braunr> one PTP (page table page) maps 4 MiB + < braunr> (x15 does this completely dynamically, unlike mach or even + current BSDs) + < mcsim1> antrik: First I want to measure time of each cache + creation/allocation/deallocation and then compile kernel. + < braunr> cache creation is irrelevant + < braunr> because of the cpu pools in the new allocator, you should test at + least two different allocation patterns + < braunr> one with quick allocs/frees + < braunr> the other with large numbers of allocs then their matching frees + < braunr> (larger being at least 100) + < braunr> i'd say the cpu pool layer is the real advantage over the + previous zone allocator + < braunr> (from a performance perspective) + < mcsim1> But there is only one cpu + < braunr> it doesn't matter + < braunr> it's stil a very effective cache + < braunr> in addition to reducing contention + < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab() + < braunr> mcsim1: work is needed to polish the whole thing, but getting it + actually working is a nice achievement for someone new on the project + < braunr> i hope it helped you learn about memory allocation, virtual + memory, gnu mach and the hurd in general :) + < antrik> indeed :-) + + +# IRC, freenode, #hurd, 2011-09-06 + + [some performance testing] + <braunr> i'm not sure such long tests are relevant but let's assume balloc + is slower + <braunr> some tuning is needed here + <braunr> first, we can see that slab allocation occurs more often in balloc + than page allocation does in zalloc + <braunr> so yes, as slab allocation is slower (have you measured which part + actually is slow ? i guess it's the kmem_alloc call) + <braunr> the whole process gets a bit slower too + <mcsim> I used alloc_size = 4096 for zalloc + <braunr> i don't know what that is exactly + <braunr> but you can't hold 500 16 bytes buffers in a page so zalloc must + have had free pages around for that + <mcsim> I use kmem_alloc_wired + <braunr> if you have time, measure it, so that we know how much it accounts + for + <braunr> where are the results for dealloc ? + <mcsim> I can't give you result right now because internet works very + bad. But for first DEALLOC result are the same, exept some cases when it + takes balloc for more than 1000 ticks + <braunr> must be the transfer from the cpu layer to the slab layer + <mcsim> as to kmem_alloc_wired. I think zalloc uses this function too for + allocating objects in zone I test. + <braunr> mcsim: yes, but less frequently, which is why it's faster + <braunr> mcsim: another very important aspect that should be measured is + memory consumption, have you looked into that ? + <mcsim> I think that I made too little iterations in test SMALL + <mcsim> If I increase constant SMALL_TESTS will it be good enough? + <braunr> mcsim: i don't know, try both :) + <braunr> if you increase the number of iterations, balloc average time will + be lower than zalloc, but this doesn't remove the first long + initialization step on the allocated slab + <mcsim> SMALL_TESTS to 500, I mean + <braunr> i wonder if maintaining the slabs sorted through insertion sort is + what makes it slow + <mcsim> braunr: where do you sort slabs? I don't see this. + <braunr> mcsim: mem_cache_alloc_from_slab and its free counterpart + <braunr> mcsim: the mem_source stuff is useless in gnumach, you can remove + it and directly call the kmem_alloc/free functions + <mcsim> But I have to make special allocator for kernel map entries. + <braunr> ah right + <mcsim> btw. It turned out that 256 entries are not enough. + <braunr> that's weird + <braunr> i'll make a patch so that the mem_source code looks more like what + i have in x15 then + <braunr> about the results, i don't think the slab layer is that slow + <braunr> it's the cpu_pool_fill/drain functions that take time + <braunr> they preallocate many objects (64 for your objects size if i'm + right) at once + <braunr> mcsim: look at the first result page: some times, a number around + 8000 is printed + <braunr> the common time (ticks, whatever) for a single object is 120 + <braunr> 8132/120 is 67, close enough to the 64 value + <mcsim> I forgot about SMALL tests here are they: + http://paste.debian.net/128533/ (balloc) http://paste.debian.net/128534/ + (zalloc) + <mcsim> braunr: why do you divide 8132 by 120? + <braunr> mcsim: to see if it matches my assumption that the ~8000 number + matches the cpu_pool_fill call + <mcsim> braunr: I've got it + <braunr> mcsim: i'd be much interested in the dealloc results if you can + paste them too + <mcsim> dealloc: http://paste.debian.net/128589/ + http://paste.debian.net/128590/ + <braunr> mcsim: thanks + <mcsim> second dealloc: http://paste.debian.net/128591/ + http://paste.debian.net/128592/ + <braunr> mcsim: so the main conclusion i retain from your tests is that the + transfers from the cpu and the slab layers are what makes the new + allocator a bit slower + <mcsim> OPERATION_SMALL dealloc: http://paste.debian.net/128593/ + http://paste.debian.net/128594/ + <braunr> mcsim: what needs to be measured now is global memory usage + <mcsim> braunr: data from /proc/vmstat after kernel compilation will be + enough? + <braunr> mcsim: let me check + <braunr> mcsim: no it won't do, you need to measure kernel memory usage + <braunr> the best moment to measure it is right after zone_gc is called + <mcsim> Are there any facilities in gnumach for memory measurement? + <braunr> it's specific to the allocators + <braunr> just count the number of used pages + <braunr> after garbage collection, there should be no free page, so this + should be rather simple + <mcsim> ok + <mcsim> braunr: When I measure memory usage in balloc, what formula is + better cache->nr_slabs * cache->bufs_per_slab * cache->buf_size or + cache->nr_slabs * cache->slab_size? + <braunr> the latter + + +# IRC, freenode, #hurd, 2011-09-07 + + <mcsim> braunr: I've disabled calling of mem_cpu_pool_fill and allocator + became faster + <braunr> mcsim: sounds nice + <braunr> mcsim: i suspect the free path might not be as fast though + <mcsim> results for first calling: http://paste.debian.net/128639/ second: + http://paste.debian.net/128640/ and with many alloc/free: + http://paste.debian.net/128641/ + <braunr> mcsim: thanks + <mcsim> best result are for second call: average time decreased from 159.56 + to 118.756 + <mcsim> First call slightly worse, but this is because I've added some + profiling code + <braunr> i still see some ~8k lines in 128639 + <braunr> even some around ~12k + <mcsim> I think this is because of mem_cache_grow I'm investigating it now + <braunr> i guess so too + <mcsim> I've measured time for first call in cache and from about 22000 + mem_cache_grow takes 20000 + <braunr> how did you change the code so that it doesn't call + mem_cpu_pool_fill ? + <braunr> is the cpu layer still used ? + <mcsim> http://paste.debian.net/128644/ + <braunr> don't forget the free path + <braunr> mcsim: anyway, even with the previous slightly slower behaviour we + could observe, the performance hit is negligible + <mcsim> Is free path a compilation? (I'm sorry for my english) + <braunr> mcsim: mem_cache_free + <braunr> mcsim: the last two measurements i'd advise are with big (>4k) + object sizes and, really, kernel allocator consumption + <mcsim> http://paste.debian.net/128648/ http://paste.debian.net/128646/ + http://paste.debian.net/128649/ (first, second, small) + <braunr> mcsim: these numbers are closer to the zalloc ones, aren't they ? + <mcsim> deallocating slighty faster too + <braunr> it may not be the case with larger objects, because of the use of + a tree + <mcsim> yes, they are closer + <braunr> but then, i expect some space gains + <braunr> the whole thing is about compromise + <mcsim> ok. I'll try to measure them today. Anyway I'll post result and you + could read them in the morning + <braunr> at least, it shows that the zone allocator was actually quite good + <braunr> i don't like how the code looks, there are various hacks here and + there, it lacks self inspection features, but it's quite good + <braunr> and there was little room for true improvement in this area, like + i told you :) + <braunr> (my allocator, like the current x15 dev branch, focuses on mp + machines) + <braunr> mcsim: thanks again for these numbers + <braunr> i wouldn't have had the courage to make the tests myself before + some time eh + <mcsim> braunr: hello. Look at the small_4096 results + http://paste.debian.net/128692/ (balloc) http://paste.debian.net/128693/ + (zalloc) + <braunr> mcsim: wow, what's that ? :) + <braunr> mcsim: you should really really include your test parameters in + the report + <braunr> like object size, purpose, and other similar details + <mcsim> for balloc I specified only object_size = 4096 + <mcsim> for zalloc object_size = 4096, alloc_size = 4096, memtype = 0; + <braunr> the results are weird + <braunr> apart from the very strange numbers (e.g. 0 or 4429543648), none + is around 3k, which is the value matching a kmem_alloc call + <braunr> happy to see balloc behaves quite good for this size too + <braunr> s/good/well/ + <mcsim> Oh + <mcsim> here is significant only first 101 lines + <mcsim> I'm sorry + <braunr> ok + <braunr> what does the test do again ? 10 loops of 10 allocs/frees ? + <mcsim> yes + <braunr> ok, so the only slowdown is at the beginning, when the slabs are + created + <braunr> the two big numbers (31844 and 19548) are strange + <mcsim> on the other hand time of compilation is + <mcsim> balloc zalloc + <mcsim> 38m28.290s 38m58.400s + <mcsim> 38m38.240s 38m42.140s + <mcsim> 38m30.410s 38m52.920s + <braunr> what are you compiling ? + <mcsim> gnumach kernel + <braunr> in 40 mins ? + <mcsim> yes + <braunr> you lack hvm i guess + <mcsim> is it long? + <mcsim> I use real PC + <braunr> very + <braunr> ok + <braunr> so it's normal + <mcsim> in vm it was about 2 hours) + <braunr> the difference really is negligible + <braunr> ok i can explain the big numbers + <braunr> the slab size depends on the object size, and for 4k, it is 32k + <braunr> you can store 8 4k buffers in a slab (lines 2 to 9) + <mcsim> so we need use kmem_alloc_* 8 times? + <braunr> on line 10, the ninth object is allocated, which adds another slab + to the cache, hence the big number + <braunr> no, once for a size of 32k + <braunr> and then the free list is initialized, which means accessing those + pages, which means tlb misses + <braunr> i guess the zone allocator already has free pages available + <mcsim> I see + <braunr> i think you can stop performance measurements, they show the + allocator is slightly slower, but so slightly we don't care about that + <braunr> we need numbers on memory usage now (at the page level) + <braunr> and this isn't easy + <mcsim> For balloc I can get numbers if I summarize nr_slabs*slab_size for + each cache, isn't it? + <braunr> yes + <braunr> you can have a look at the original implementation, function + mem_info + <mcsim> And for zalloc I have to summarize of cur_size and then add + zalloc_wasted_space? + <braunr> i don't know :/ + <braunr> i think the best moment to obtain accurate values is after zone_gc + removes the collected pages + <braunr> for both allocators, you could fill a stats structure at that + moment, and have an rpc copy that structure when a client tool requests + it + <braunr> concerning your tests, there is another point to have in mind + <braunr> the very first loop in your code shows a result of 31844 + <braunr> although you disabled the call to cpu_pool_fill + <braunr> but the reason why it's so long is that the cpu layer still exists + <braunr> and if you look carefully, the cpu pools are created as needed on + the free path + <mcsim> I removed cpu_pool_drain + <braunr> but not cpu_pool_push/pop i guess + <mcsim> http://paste.debian.net/128698/ + <braunr> see, you still allocate the cpu pool array on the free path + <mcsim> but I don't fill it + <braunr> that's not the point + <braunr> it uses mem_cache_alloc + <braunr> so in a call to free, you can also have an allocation, that can + potentially create a new slab + <mcsim> I see, so I have to create cpu_pool at the initialization stage? + <braunr> no, you can't + <braunr> there is a reason why they're allocated on the free path + <braunr> but since you don't have the fill/drain functions, i wonder if you + should just comment out the whole cpu layer code + <braunr> but hmm + <braunr> no really, it's not worth the effort + <braunr> even with drains/fills, the results are really good enough + <braunr> it makes the allocator smp ready + <braunr> we should just keep it that way + <braunr> mcsim: fyi, the reason why cpu pool arrays are allocated on the + free path is to avoid recursion + <braunr> because cpu pool arrays are allocated from caches just as almost + everything else + <mcsim> ok + <mcsim> summ of cur_size and then adding zalloc_wasted_space gives 0x4e1954 + <mcsim> but this value isn't even page aligned + <mcsim> For balloc I've got 0x4c6000 0x4aa000 0x48d000 + <braunr> hm can you report them in decimal, >> 10 so that values are in KiB + ? + <mcsim> 4888 4776 4660 for balloc + <mcsim> 4998 for zalloc + <braunr> when ? + <braunr> after boot ? + <mcsim> boot, compile, zone_gc + <mcsim> and then measure + <braunr> ? + <mcsim> I call garbage collector before measuring + <mcsim> and I measure after kernel compilation + <braunr> i thought it took you 40 minutes + <mcsim> for balloc I got results at night + <braunr> oh so you already got them + <braunr> i can't beleive the kernel only consumes 5 MiB + <mcsim> before gc it takes about 9052 Kib + <braunr> can i see the measurement code ? + <braunr> oh, and how much ram does your machine have ? + <mcsim> 758 mb + <mcsim> 768 + <braunr> that's really weird + <braunr> i'd expect the kernel to consume much more space + <mcsim> http://paste.debian.net/128703/ + <mcsim> it's only dynamically allocated data + <braunr> yes + <braunr> ipc ports, rights, vm map entries, vm objects, and lots of other + hanging buffers + <braunr> about how much is zalloc_wasted_space ? + <braunr> if it's small or constant, i guess you could ignore it + <mcsim> about 492 + <mcsim> KiB + <braunr> well it's another good point, mach internal structures don't imply + much overhead + <braunr> or, the zone allocator is underused + + <tschwinge> mcsim, braunr: The memory allocator project is coming along + good, as I get from your IRC messages? + <braunr> tschwinge: yes, but as expected, improvements are minor + <tschwinge> But at the very least it's now well-known, maintainable code. + <braunr> yes, it's readable, easier to understand, provides self inspection + and is smp ready + <braunr> there also are less hacks, but a few less features (there are no + way to avoid sleeping so it's unusable - and unused - in interrupt + handlers) + <braunr> is* no way + <braunr> tschwinge: mcsim did a good job porting and measuring it + + +# IRC, freenode, #hurd, 2011-09-08 + + <antrik> braunr: note that the zalloc map used to be limited to 8 MiB or + something like that a couple of years ago... so it doesn't seems + surprising that the kernel uses "only" 5 MiB :-) + <antrik> (yes, we had a *lot* of zalloc panics back then...) + + +# IRC, freenode, #hurd, 2011-09-14 + + <mcsim> braunr: hello. I've written a constructor for kernel map entries + and it can return resources to their source. Can you have a look at it? + http://paste.debian.net/130037/ If all be OK I'll push it tomorrow. + <braunr> mcsim: send the patch through mail please, i'll apply it on my + copy + <braunr> are you sure the cache is reapable ? + <mcsim> All slabs, except first I allocate with kmem_alloc_wired. + <braunr> how can you be sure ? + <mcsim> First slab I allocate during bootstrap and use pmap_steal_memory + and further I use only kmem_alloc_wired + <braunr> no, you use kmem_free + <braunr> in kentry_dealloc_cache() + <braunr> which probably creates a recursion + <braunr> using the constructor this way isn't a good idea + <braunr> constructors are good for preconstructed state (set counters to 0, + init lists and locks, that kind of things, not allocating memory) + <braunr> i don't think you should try to make this special cache reapable + <braunr> mcsim: keep in mind constructors are applied on buffers at *slab* + creation, not at object allocation + <braunr> so if you allocate a single slab with, say, 50 or 100 objects per + slab, kmem_alloc_wired would be called that number of times + <mcsim> why kentry_dealloc_cache can create recursion? kentry_dealloc_cache + is called only by mem_cache_reap. + <braunr> right + <braunr> but are you totally sure mem_cache_reap() can't be called by + kmem_free() ? + <braunr> i think you're right, it probably can't + + +# IRC, freenode, #hurd, 2011-09-25 + + <mcsim> braunr: hello. I rewrote constructor for kernel entries and seems + that it works fine. I think that this was last milestone. Only moving of + memory allocator sources to more appropriate place and merge with main + branch left. + <braunr> mcsim: it needs renaming and reindenting too + <mcsim> for reindenting C-x h Tab in emacs will be enough? + <braunr> mcsim: make sure which style must be used first + <mcsim> and what should I rename and where better to place allocator? For + example, there is no lib directory, like in x15. Should I create it and + move list.* and rbtree.* to lib/ or move these files to util/ or + something else? + <braunr> mcsim: i told you balloc isn't a good name before, use something + more meaningful (kmem is already used in gnumach unfortunately if i'm + right) + <braunr> you can put the support files in kern/ + <mcsim> what about vm_alloc? + <braunr> you should prefix it with vm_ + <braunr> shouldn't + <braunr> it's a top level allocator + <braunr> on top of the vm system + <braunr> maybe mcache + <braunr> hm no + <braunr> maybe just km_ + <mcsim> kern/km_alloc.*? + <braunr> no + <braunr> just km + <mcsim> ok. + + +# IRC, freenode, #hurd, 2011-09-27 + + <mcsim> braunr: hello. When I've tried to speed of new allocator and bad + I've removed function mem_cpu_pool_fill. But you've said to undo this. I + don't understand why this function is necessary. Can you explain it, + please? + <mcsim> When I've tried to compare speed of new allocator and old* + <braunr> i'm not sure i said that + <braunr> i said the performance overhead is negligible + <braunr> so it's better to leave the cpu pool layer in place, as it almost + doesn't hurt + <braunr> you can implement the KMEM_CF_NO_CPU_POOL I added in the x15 mach + version + <braunr> so that cpu pools aren't used by default, but the code is present + in case smp is implemented + <mcsim> I didn't remove cpu pool layer. I've just removed filling of cpu + pool during creation of slab. + <braunr> how do you fill the cpu pools then ? + <mcsim> If object is freed than it is added to cpu poll + <braunr> so you don't fill/drain the pools ? + <braunr> you try to get/put an object and if it fails you directly fall + back to the slab layer ? + <mcsim> I drain them during garbage collection + <braunr> oh + <mcsim> yes + <braunr> you shouldn't touch the cpu layer during gc + <braunr> the number of objects should be small enough so that we don't care + much + <mcsim> ok. I can drain cpu pool at any other time if it is prohibited to + in mem_gc. + <mcsim> But why do we need to fill cpu poll during slab creation? + <mcsim> In this case allocation consist of: get object from slab -> put it + to cpu pool -> get it from cpu pool + <mcsim> I've just remove last to stages + <braunr> hm cpu pools aren't filled at slab creation + <braunr> they're filled when they're empty, and drained when they're full + <braunr> so that the number of objects they contain is increased/reduced to + a value suitable for the next allocations/frees + <braunr> the idea is to fall back as little as possible to the slab layer + because it requires the acquisition of the cache lock + <mcsim> oh. You're right. I'm really sorry. The point is that if cpu pool + is empty we don't need to fill it first + <braunr> uh, yes we do :) + <mcsim> Why cache locking is so undesirable? If we have free objects in + slabs locking will not take a lot if time. + <braunr> mcsim: it's undesirable on a smp system + <mcsim> ok. + <braunr> mcsim: and spin locks are normally noops on a up system + <braunr> which is the case in gnumach, hence the slightly better + performances without the cpu layer + <braunr> but i designed this allocator for x15, which only supports mp + systems :) + <braunr> mcsim: sorry i couldn't look at your code, sick first, busy with + server migration now (new server almost ready for xen hurds :)) + <mcsim> ok. + <mcsim> I ended with allocator if didn't miss anything important:) + <braunr> i'll have a look soon i hope :) + + +# IRC, freenode, #hurd, 2011-09-27 + + <antrik> braunr: would it be realistic/useful to check during GC whether + all "used" objects are actually in a CPU pool, and if so, destroy them so + the slab can be freed?... + <antrik> mcsim: BTW, did you ever do any measurements of memory + use/fragmentation? + <mcsim> antrik: I couldn't do this for zalloc + <antrik> oh... why not? + <antrik> (BTW, I would be interested in a comparision between using the CPU + layer, and bare slab allocation without CPU layer) + <mcsim> Result I've got were strange. It wasn't even aligned to page size. + <mcsim> Probably is it better to look into /proc/vmstat? + <mcsim> Because I put hooks in the code and probably I missed something + <antrik> mcsim: I doubt vmstat would give enough information to make any + useful comparision... + <braunr> antrik: isn't this draining cpu pools at gc time ? + <braunr> antrik: the cpu layer was found to add a slight overhead compared + to always falling back to the slab layer + <antrik> braunr: my idea is only to drop entries from the CPU cache if they + actually prevent slabs from being freed... if other objects in the slab + are really in use, there is no point in flushing them from the CPU cache + <antrik> braunr: I meant comparing the fragmentation with/without CPU + layer. the difference in CPU usage is probably negligable anyways... + <antrik> you might remember that I was (and still am) sceptical about CPU + layer, as I suspect it worsens the good fragmentation properties of the + pure slab allocator -- but it would be nice to actually check this :-) + <braunr> antrik: right + <braunr> antrik: the more i think about it, the more i consider slqb to be + a better solution ...... :> + <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 + + +# IRC, freenode, #hurd, 2011-11-14 + + <braunr> i've just realized that replacing the zone allocator removes most + (if not all) static limit on allocated objects + <braunr> as we have nothing similar to rlimits, this means kernel resources + are actually exhaustible + <braunr> and i'm not sure every allocation is cleanly handled in case of + memory shortage + <braunr> youpi: antrik: tschwinge: is this acceptable anyway ? + <braunr> (although IMO, it's also a good thing to get rid of those limits + that made the kernel panic for no valid reason) + <youpi> there are actually not many static limits on allocated objects + <youpi> only a few have one + <braunr> those defined in kern/mach_param.h + <youpi> most of them are not actually enforced + <braunr> ah ? + <braunr> they are used at zinit() time + <braunr> i thought they were + <youpi> yes, but most zones are actually fine with overcoming the max + <braunr> ok + <youpi> see zone->max_size += (zone->max_size >> 1); + <youpi> you need both !EXHAUSTIBLE and FIXED + <braunr> ok + <pinotree> making having rlimits enforced would be nice... + <pinotree> s/making// + <braunr> pinotree: the kernel wouldn't handle many standard rlimits anyway + + <braunr> i've just committed my final patch on mcsim's branch, which will + serve as the starting point for integration + <braunr> which means code in this branch won't change (or only last minute + changes) + <braunr> you're invited to test it + <braunr> there shouldn't be any noticeable difference with the master + branch + <braunr> a bit less fragmentation + <braunr> more memory can be reclaimed by the VM system + <braunr> there are debugging features + <braunr> it's SMP ready + <braunr> and overall cleaner than the zone allocator + <braunr> although a bit slower on the free path (because of what's + performed to reduce fragmentation) + <braunr> but even "slower" here is completely negligible + + +# IRC, freenode, #hurd, 2011-11-15 + + <mcsim> I enabled cpu_pool layer and kentry cache exhausted at "apt-get + source gnumach && (cd gnumach-* && dpkg-buildpackage)" + <mcsim> I mean kernel with your last commit + <mcsim> braunr: I'll make patch how I've done it in a few minutes, ok? It + will be more specific. + <braunr> mcsim: did you just remove the #if NCPUS > 1 directives ? + <mcsim> no. I replaced macro NCPUS > 1 with SLAB_LAYER, which equals NCPUS + > 1, than I redefined macro SLAB_LAYER + <braunr> ah, you want to make the layer optional, even on UP machines + <braunr> mcsim: can you give me the commands you used to trigger the + problem ? + <mcsim> apt-get source gnumach && (cd gnumach-* && dpkg-buildpackage) + <braunr> mcsim: how much ram & swap ? + <braunr> let's see if it can handle a quite large aptitude upgrade + <mcsim> how can I check swap size? + <braunr> free + <braunr> cat /proc/meminfo + <braunr> top + <braunr> whatever + <mcsim> total used free shared buffers + cached + <mcsim> Mem: 786368 332296 454072 0 0 + 0 + <mcsim> -/+ buffers/cache: 332296 454072 + <mcsim> Swap: 1533948 0 1533948 + <braunr> ok, i got the problem too + <mcsim> braunr: do you run hurd in qemu? + <braunr> yes + <braunr> i guess the cpu layer increases fragmentation a bit + <braunr> which means more map entries are needed + <braunr> hm, something's not right + <braunr> there are only 26 kernel map entries when i get the panic + <braunr> i wonder why the cache gets that stressed + <braunr> hm, reproducing the kentry exhaustion problem takes quite some + time + <mcsim> braunr: what do you mean? + <braunr> sometimes, dpkg-buildpackage finishes without triggering the + problem + <mcsim> the problem is in apt-get source gnumach + <braunr> i guess the problem happens because of drains/fills, which + allocate/free much more object than actually preallocated at boot time + <braunr> ah ? + <braunr> ok + <braunr> i've never had it at that point, only later + <braunr> i'm unable to trigger it currently, eh + <mcsim> do you use *-dbg kernel? + <braunr> yes + <braunr> well, i use the compiled kernel, with the slab allocator, built + with the in kernel debugger + <mcsim> when you run apt-get source gnumach, you run it in clean directory? + Or there are already present downloaded archives? + <braunr> completely empty + <braunr> ah just got it + <braunr> ok the limit is reached, as expected + <braunr> i'll just bump it + <braunr> the cpu layer drains/fills allocate several objects at once (64 if + the size is small enough) + <braunr> the limit of 256 (actually 252 since the slab descriptor is + embedded in its slab) is then easily reached + <antrik> mcsim: most direct way to check swap usage is vmstat + <braunr> damn, i can't live without slabtop and the amount of + active/inactive cache memory any more + <braunr> hm, weird, we have active/inactive memory in procfs, but not + buffers/cached memory + <braunr> we could set buffers to 0 and everything as cached memory, since + we're currently unable to communicate the purpose of cached memory + (whether it's used by disk servers or file system servers) + <braunr> mcsim: looks like there are about 240 kernel map entries (i forgot + about the ones used in kernel submaps) + <braunr> so yes, addin the cpu layer is what makes the kernel reach the + limit more easily + <mcsim> braunr: so just increasing limit will solve the problem? + <braunr> mcsim: yes + <braunr> slab reclaiming looks very stable + <braunr> and unfrequent + <braunr> (which is surprising) + <pinotree> braunr: "unfrequent"? + <braunr> pinotree: there isn't much memory pressure + <braunr> slab_collect() gets called once a minute on my hurd + <braunr> or is it infrequent ? + <braunr> :) + <pinotree> i have no idea :) + <braunr> infrequent, yes + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> for those who want to play with the slab branch of gnumach, the + slabinfo tool is available at http://git.sceen.net/rbraun/slabinfo.git/ + <braunr> for those merely interested in numbers, here is the output of + slabinfo, for a hurd running in kvm with 512 MiB of RAM, an unused swap, + and a short usage history (gnumach debian packages built, aptitude + upgrade for a dozen of packages, a few git commands) + <braunr> http://www.sceen.net/~rbraun/slabinfo.out + <antrik> braunr: numbers for a long usage history would be much more + interesting :-) + + +## IRC, freenode, #hurd, 2011-11-17 + + <braunr> antrik: they'll come :) + <etenil> is something going on on darnassus? it's mighty slow + <braunr> yes + <braunr> i've rebooted it to run a modified kernel (with the slab + allocator) and i'm building stuff on it to stress it + <braunr> (i don't have any other available machine with that amount of + available physical memory) + <etenil> ok + <antrik> braunr: probably would be actually more interesting to test under + memory pressure... + <antrik> guess that doesn't make much of a difference for the kernel object + allocator though + <braunr> antrik: if ram is larger, there can be more objects stored in + kernel space, then, by building something large such as eglibc, memory + pressure is created, causing caches to be reaped + <braunr> our page cache is useless because of vm_object_cached_max + <braunr> it's a stupid arbitrary limit masking the inability of the vm to + handle pressure correctly + <braunr> if removing it, the kernel freezes soon after ram is filled + <braunr> antrik: it may help trigger the "double swap" issue you mentioned + <antrik> what may help trigger it? + <braunr> not checking this limit + <antrik> hm... indeed I wonder whether the freezes I see might have the + same cause + + +## IRC, freenode, #hurd, 2011-11-19 + + <braunr> http://www.sceen.net/~rbraun/slabinfo.out <= state of the slab + allocator after building the debian libc packages and removing all files + once done + <braunr> it's mostly the same as on any other machine, because of the + various arbitrary limits in mach (most importantly, the max number of + objects in the page cache) + <braunr> fragmentation is still quite low + <antrik> braunr: actually fragmentation seems to be lower than on the other + run... + <braunr> antrik: what makes you think that ? + <antrik> the numbers of currently unused objects seem to be in a similar + range IIRC, but more of them are reclaimable I think + <antrik> maybe I'm misremembering the other numbers + <braunr> there had been more reclaims on the other run + + +# IRC, freenode, #hurd, 2011-11-25 + + <braunr> mcsim: i've just updated the slab branch, please review my last + commit when you have time + <mcsim> braunr: Do you mean compilation/tests? + <braunr> no, just a quick glance at the code, see if it matches what you + intended with your original patch + <mcsim> braunr: everything is ok + <braunr> good + <braunr> i think the branch is ready for integration + + +# IRC, freenode, #hurd, 2011-12-17 + + <braunr> in the slab branch, there now is no use for the defines in + kern/mach_param.h + <braunr> should the file be removed or left empty as a placeholder for + future arbitrary limits ? + <braunr> (i'd tend ro remove it as a way of indicating we don't want + arbitrary limits but there may be a good reason to keep it around .. :)) + <youpi> I'd just drop it + <braunr> ok + <braunr> hmm maybe we do want to keep that one : + <braunr> #define IMAR_MAX (1 << 10) /* Max number of + msg-accepted reqs */ + <antrik> whatever that is... + <braunr> it gets returned in ipc_marequest_info + <braunr> but the mach_debug interface has never been used on the hurd + <braunr> there now is a master-slab branch in the gnumach repo, feel free + to test it + + +# IRC, freenode, #hurd, 2011-12-22 + + <youpi> braunr: does the new gnumach allocator has profiling features? + <youpi> e.g. to easily know where memory leaks reside + <braunr> youpi: you mean tracking call traces to allocated blocks ? + <youpi> not necessarily traces + <youpi> but at least means to know what kind of objects is filling memory + <braunr> it's very close to the zone allocator + <braunr> but instead of zones, there are caches + <braunr> each named after the type they store + <braunr> see http://www.sceen.net/~rbraun/slabinfo.out + <youpi> ok, so we can know, per-type, how much memory is used + <braunr> yes + <youpi> good + <braunr> if backtraces can easily be forged, it wouldn't be hard to add + that feature too + <youpi> does it dump such info when memory goes short? + <braunr> no but it can + <braunr> i've done this during tests + <youpi> it'd be good + <youpi> because I don't know in advance when a buildd will crash due to + that :) + <braunr> each time slab_collect() is called for example + <youpi> I mean not on collect, but when it's too late + <youpi> and thus always enabled + <braunr> ok + <youpi> (because there's nothing better to do than at least give infos) + <braunr> you just have to define "when it's too late", and i can add that + <youpi> when there is no memory left + <braunr> you mean when the number of free pages strictly reaches 0 ? + <youpi> yes + <braunr> ok + <youpi> i.e. just before crashing the kernel + <braunr> i see + + +# IRC, freenode, #hurdfr, 2012-01-02 + + <youpi> braunr: le code du slab allocator, il est écrit from scratch ? + <youpi> il y a encore du copyright carnegie mellon + <youpi> (dans slab_info.h du moins) + <youpi> ipc_hash_global_size = 256; + <youpi> il faudrait mettre 256 comme constante dans un header + <youpi> sinon c'est encore une valeur arbitraire cachée dans du code + <youpi> de même pour ipc_marequest_size etc. + <braunr> youpi: oui, from scratch + <braunr> slab_info.h est à l'origine zone_info.h + <braunr> pour les valeurs fixes, elles étaient déjà présentes de cette + façon, j'ai pensé qu'il valait mieux laisser comme ça pour faciliter la + lecture des diffs + <braunr> je ferai des macros à la place + <braunr> du coup il faudra peut-être remettre mach_param.h + <braunr> ou alors dans les .h ipc + + +# IRC, freenode, #hurd, 2012-01-18 + + <braunr> does the slab branch need other reviews/reports before being + integrated ? + + +# IRC, freenode, #hurd, 2012-01-30 + + <braunr> youpi: do you have some idea about when you want to get the slab + branch in master ? + <youpi> I was considering as soon as mcsim gets his paper + <braunr> right + + +# IRC, freenode, #hurd, 2012-02-22 + + <mcsim> Do I understand correct, that real memory page should be + necessarily in one of following lists: vm_page_queue_active, + vm_page_queue_inactive, vm_page_queue_free? + <braunr> cached pages are + <braunr> some special pages used only by the kernel aren't + <braunr> pages can be both wired and cached (i.e. managed by the page + cache), so that they can be passed to external applications and then + unwired (as is the case with your host_slab_info() function if you + remember) + <braunr> use "physical" instead of "real memory" + <mcsim> braunr: thank you. + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> youpi: tschwinge: when the slab code was added, a few new files + made into gnumach that come from my git repo and are used in other + projects as well + <braunr> they're licensed under BSD upstream and GPL in gnumach, and though + it initially didn't disturb me, now it does + <braunr> i think i should fix this by leaving the original copyright and + adding the GPL on top + <youpi> sure, submit a patch + <braunr> hm i have direct commit acces if im right + <youpi> then fix it :) + <braunr> do you want to review ? + <youpi> I don't think there is any need to + <braunr> ok + + +# IRC, freenode, #hurd, 2012-12-08 + + <mcsim> braunr: hi. Do I understand correct that merely the same technique + is used in linux to determine the slab where, the object to be freed, + resides? + <braunr> yes but it's faster on linux since it uses a direct mapping of + physical memory + <braunr> it just has to shift the virtual address to obtain the physical + one, whereas x15 has to walk the pages tables + <braunr> of course it only works for kmalloc, vmalloc is entirely different + <mcsim> btw, is there sense to use some kind of B-tree instead of AVL to + decrease number of cache misses? AFAIK, in modern processors size of L1 + cache line is at least 64 bytes, so in one node we can put at least 4 + leafs (key + pointer to data) making search faster. + <braunr> that would be a b-tree + <braunr> and yes, red-black trees were actually developed based on + properties observed on b-trees + <braunr> but increasing the size of the nodes also increases memory + overhead + <braunr> and code complexity + <braunr> that's why i have a radix trees for cases where there are a large + number of entries with keys close to each other :) + <braunr> a radix-tree is basically a b-tree using the bits of the key as + indexes in the various arrays it walks instead of comparing keys to each + other + <braunr> the original avl tree used in my slab allocator was intended to + reduce the average height of the tree (avl is better for that) + <braunr> avl trees are more suited for cases where there are more lookups + than inserts/deletions + <braunr> they make the tree "flatter" but the maximum complexity of + operations that change the tree is 2log2(n), since rebalancing the tree + can make the algorithm reach back to the tree root + <braunr> red-black trees have slightly bigger heights but insertions are + limited to 2 rotations and deletions to 3 + <mcsim> there should be not much lookups in slab allocators + <braunr> which explains why they're more generally found in generic + containers + <mcsim> or do I misunderstand something? + <braunr> well, there is a lookup for each free() + <braunr> whereas there are insertions/deletions when a slab becomes + non-empty/empty + <mcsim> I see + <braunr> so it was very efficient for caches of small objects, where slabs + have many of them + <braunr> also, i wrote the implementation in userspace, without + functionality pmap provides (although i could have emulated it + afterwards) diff --git a/open_issues/gnumach_memory_management/pmap.out b/open_issues/gnumach_memory_management/pmap.out new file mode 100644 index 00000000..b1af1e66 --- /dev/null +++ b/open_issues/gnumach_memory_management/pmap.out @@ -0,0 +1,85 @@ +Start End Size Offset rwxpc RWX I/W/A Dev Inode - File +c0000000-c16c1fff 23304k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16c2000-c16c2fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16c3000-c16e2fff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c16e3000-c999cfff 133864k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ kmem_map ] + c16e3000-c16e3fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c16e4000-c1736fff 332k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1737000-c1737fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1738000-c1766fff 188k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1767000-c1767fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1768000-c182dfff 792k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c182e000-c182efff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c182f000-c187bfff 308k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c187c000-c187cfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c187d000-c187dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + c1880000-c189ffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +c999d000-ca99cfff 16384k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ pager_map ] +ca99d000-ca9b7fff 108k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9b8000-ca9b9fff 8k 0a9b8000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +ca9ba000-ca9bbfff 8k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9bc000-ca9bffff 16k 0a9bc000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +ca9c0000-ca9dffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +ca9e0000-cab0bfff 1200k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ phys_map ] +cab0c000-cad16fff 2092k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ mb_map ] + cab0c000-cab0cfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + cab0d000-cab3afff 184k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad17000-cad26fff 64k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad27000-cad2cfff 24k 0ad27000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cad2d000-cad2dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cad2e000-cad2ffff 8k 0ad2e000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cad30000-cae0ffff 896k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cae10000-cae11fff 8k 0ae10000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cae12000-cae81fff 448k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cae82000-cae83fff 8k 0ae82000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cae84000-caecbfff 288k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caecc000-caecdfff 8k 0aecc000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caece000-caecefff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caecf000-caecffff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caed0000-caed1fff 8k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caed2000-caed3fff 8k 0aed2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caed4000-caee5fff 72k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caee6000-caee9fff 16k 0aee6000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caeea000-caeeefff 20k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +caeef000-caef4fff 24k 0aeef000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +caef5000-cb00cfff 1120k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb00d000-cb01cfff 64k 0b00d000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb01d000-cb02afff 56k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb02b000-cb82afff 8192k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ ubc_pager ] +cb82b000-cb838fff 56k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb839000-cb839fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb83a000-cb83bfff 8k 0b83a000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb83c000-cb855fff 104k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb856000-cb857fff 8k 0b856000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb858000-cb858fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb859000-cb85cfff 16k 0b859000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb85d000-cb85dfff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb85e000-cb85ffff 8k 0b85e000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb860000-cb88ffff 192k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb890000-cb8cffff 256k 0b890000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb8d0000-cb8f0fff 132k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cb8f1000-cb8f4fff 16k 0b8f1000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cb8f5000-cba03fff 1084k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cba04000-cba04fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cba05000-cbaf1fff 948k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbaf2000-cbaf3fff 8k 0baf2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbaf4000-cbaf7fff 16k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbaf8000-cbafffff 32k 0baf8000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb00000-cbb70fff 452k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbb71000-cbb76fff 24k 0bb71000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb77000-cbb7bfff 20k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbb7c000-cbb7ffff 16k 0bb7c000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbb80000-cbbc1fff 264k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc2000-cbbc2fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc3000-cbbc3fff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc4000-cbbc5fff 8k 0bbc4000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbc6000-cbbc8fff 12k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbc9000-cbbcafff 8k 0bbc9000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbcb000-cbbcdfff 12k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbbce000-cbbcffff 8k 0bbce000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbbd0000-cbca1fff 840k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbca2000-cbcadfff 48k 0bca2000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbcae000-cbcaefff 4k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] +cbcaf000-cbcb2fff 16k 0bcaf000 rwxs- (rwx) 2/0/1 00:00 0 - [ uvm_aobj ] +cbcc0000-cbcdffff 128k 00000000 rwxs- (rwx) 2/0/1 00:00 0 - [ anon ] + total 193356k 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/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn new file mode 100644 index 00000000..d128c668 --- /dev/null +++ b/open_issues/gnumach_page_cache_policy.mdwn @@ -0,0 +1,785 @@ +[[!meta copyright="Copyright © 2012 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]] + +[[!toc]] + + +# [[page_cache]] + + +# IRC, freenode, #hurd, 2012-04-26 + + <braunr> another not-too-long improvement would be changing the page cache + policy + <youpi> to drop the 4000 objects limit, you mean ? + <braunr> yes + <youpi> do you still have my patch attempt ? + <braunr> no + <youpi> let me grab that + <braunr> oh i won't start it right away you know + <braunr> i'll ask for it when i do + <youpi> k + <braunr> (otherwise i fell i'll just loose it again eh) + <youpi> :) + <braunr> but i imagine it's not too hard to achieve + <youpi> yes + <braunr> i also imagine to set a large threshold of free pages to avoid + deadlocks + <braunr> which will still be better than the current situation where we + have either lots of free pages because tha max limit is reached, or lots + of pressure and system freezes :/ + <youpi> yes + + +## IRC, freenode, #hurd, 2012-06-17 + + <braunr> youpi: i don't understand your patch :/ + <youpi> arf + <youpi> which part don't you understand? + <braunr> the global idea :/ + <youpi> first, drop the limit on number of objects + <braunr> you added a new collect call at pageout time + <youpi> (i.e. here, hack overflow into 0) + <braunr> yes + <braunr> obviously + <youpi> but then the cache keeps filling up with objects + <youpi> which sooner or later become empty + <youpi> thus the collect, which is supposed to look for empty objects, and + just drop them + <braunr> but not at the right time + <braunr> objects should be collected as soon as their ref count drops to 0 + <braunr> err + <youpi> now, the code of the collect is just a crude attempt without + knowing much about the vm + <braunr> when their resident page count drops to 0 + <youpi> so don't necessarily read it :) + <braunr> ok + <braunr> i've begin playing with the vm recently + <braunr> the limits (arbitrary, and very old obviously) seem far too low + for current resources + <braunr> (e.g. the threshold on free pages is 50 iirc ...) + <youpi> yes + <braunr> i'll probably use a different approach + <braunr> the one i mentioned (collecting one object at a time - or pushing + them on a list for bursts - when they become empty) + <braunr> this should relax the kernel allocator more + <braunr> (since there will be less empty vm_objects remaining until the + next global collecttion) + + +## IRC, freenode, #hurd, 2012-06-30 + + <braunr> the threshold values of the page cache seem quite enough actually + <youpi> braunr: ah + <braunr> youpi: yes, it seems the problems are in ext2, not in the VM + <youpi> k + <youpi> the page cache limitation still doesn't help :) + <braunr> the problem in the VM is the recycling of vm_objects, which aren't + freed once empty + <braunr> but it only wastes some of the slab memory, it doesn't prevent + correct processing + <youpi> braunr: thus the limitation, right? + <braunr> no + <braunr> well + <braunr> that's the policy they chose at the time + <braunr> for what reason .. i can't tell + <youpi> ok, but I mean + <youpi> we can't remove the policy because of the non-free of empty objects + <braunr> we must remove vm_objects at some point + <braunr> but even without it, it makes no sense to disable the limit while + ext2 is still unstable + <braunr> also, i noticed that the page count in vm_objects never actually + drop to 0 ... + <youpi> you mean the limit permits to avoid going into the buggy scenarii + too often? + <braunr> yes + <youpi> k + <braunr> at least, that's my impression + <braunr> my test case is tar xf files.tar.gz, which contains 50000 files of + 12k random data + <braunr> i'll try with other values + <braunr> i get crashes, deadlocks, livelocks, and it's not pretty :) + +[[libpager_deadlock]]. + + <braunr> and always in ext2, mach doesn't seem affected by the issue, other + than the obvious + <braunr> (well i get the usual "deallocating an invalid port", but as + mentioned, it's "most probably a bug", which is the case here :) + <youpi> braunr: looks coherent with the hangs I get on the buildds + <braunr> youpi: so that's the nasty bug i have to track now + <youpi> though I'm also still getting some out of memory from gnumach + sometimes + <braunr> the good thing is i can reproduce it very quickly + <youpi> a dump from the allocator to know which zone took all the room + might help + <braunr> youpi: yes i promised that too + <youpi> although that's probably related with ext2 issues :) + <braunr> youpi: can you send me the panic message so i can point the code + which must output the allocator state please ? + <youpi> next time I get it, sure :) + <pinotree> braunr: you could implement a /proc/slabinfo :) + <braunr> pinotree: yes but when a panic happens, it's too late + <braunr> http://git.sceen.net/rbraun/slabinfo.git/ btw + <braunr> although it's not part of procfs + <braunr> and the mach_debug interface isn't provided :( + + +## IRC, freenode, #hurd, 2012-07-03 + + <braunr> it looks like pagers create a thread per memory object ... + <antrik> braunr: oh. so if I open a lot of files, ext2fs will *inevitably* + have lots of threads?... + <braunr> antrik: i'm not sure + <braunr> it may only be required to flush them + <braunr> but when there are lots of them, the threads could run slowly, + giving the impression there is one per object + <braunr> in sync mode i don't see many threads + <braunr> and i don't get the bug either for now + <braunr> while i can see physical memory actually being used + <braunr> (and the bug happens before there is any memory pressure in the + kernel) + <braunr> so it definitely looks like a corruption in ext2fs + <braunr> and i have an idea .... :> + <braunr> hm no, i thought an alloca with a big size parameter could erase + memory outside the stack, but it's something else + <braunr> (although alloca should really be avoided) + <braunr> arg, the problem seems to be in diskfs_sync_everything -> + ports_bucket_iterate (pager_bucket, sync_one); :/ + <braunr> :( + <braunr> looks like the ext2 problem is triggered by calling pager_sync + from diskfs_sync_everything + <braunr> and is possibly related to + http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00127.html + <braunr> (and for reference, the rest of the discussion + http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00012.html) + <braunr> multithreading in libpager is scary :/ + <antrik> braunr: s/in libpager/ ;-) + <braunr> antrik: right + <braunr> omg the ugliness :/ + <braunr> ok i found a bug + <braunr> a real one :) + <braunr> (but not sure it's the only one since i tried that before) + <braunr> 01:38 < braunr> hm no, i thought an alloca with a big size + parameter could erase memory outside the stack, but it's something else + <braunr> turns out alloca is sometimes used for 64k+ allocations + <braunr> which explains the stack corruptions + <pinotree> ouch + <braunr> as it's used to duplicate the node table before traversing it, it + also explains why the cache limit affects the frequency of the bug + <braunr> now the fun part, write the patch following GNU protocol .. :) + +[[!message-id "1341350006-2499-1-git-send-email-rbraun@sceen.net"]] + + <braunr> if someone feels like it, there are a bunch of alloca calls in the + hurd (like around 30 if i'm right) + <braunr> most of them look safe, but some could trigger that same problem + in other servers + <braunr> ok so far, no problem with the upstream ext2fs code :) + <braunr> 20 loops of tar xf / rm -rf consuming all free memory as cache :) + <braunr> the hurd uses far too much cpu time for no valid reason in many + places :/ + * braunr happy + <braunr> my hurd is completely using its ram :) + <gnu_srs> Meaning, the bug is solved? Congrats if so :) + <braunr> well, ext2fs looks way more stable now + <braunr> i haven't had a single issue since the change, so i guess i messed + something with my previous test + <braunr> and the Mach VM cache implementation looks good enough + <braunr> now the only thing left is to detect unused objects and release + them + <braunr> which is actually the core of my work :) + <braunr> but i'm glad i could polish ext2fs + <braunr> with luck, this is the issue that was striking during "thread + storms" in the past + * pinotree hugs braunr + <braunr> i'm also very happy to see the slab allocator reacting well upon + memory pressure :> + <mcsim> braunr: Why alloca corrupted memory diskfs_node_iterate? Was + temporary node to big to keep it in stack? + <braunr> mcsim: yes + <braunr> 17:54 < braunr> turns out alloca is sometimes used for 64k+ + allocations + <braunr> and i wouldn't be surprised if our thread stacks are + simplecontiguous 64k mappings of zero-filled memory + <braunr> (as Mach only provides bottom-up allocation) + <braunr> our thread implementation should leave unmapped areas between + thread stacks, to easily catch such overflows + <pinotree> braunr: wouldn't also fatfs/inode.c and tmpfs/node.c need the + same fix? + <braunr> pinotree: possibly + <braunr> i haven't looked + <braunr> more than 300 loops of tar xf / rm -rf on an archive of 20000 + files of 12 KiB each, without any issue, still going on :) + <youpi> braunr: yay + + +## [[!message-id "20120703121820.GA30902@mail.sceen.net"]], 2012-07-03 + + +## IRC, freenode, #hurd, 2012-07-04 + + <braunr> mach is so good it caches objects which *no* page in physical + memory + <braunr> hm i think i have a working and not too dirty vm cache :> + <kilobug> braunr: congrats :) + <braunr> kilobug: hey :) + <braunr> the dangerous side effect is the increased swappiness + <braunr> we'll have to monitor that on the buildds + <braunr> otherwise the cache is effectively used, and the slab allocator + reports reasonable amounts of objects, not increasing once the ram is + full + <braunr> let's see what happens with 1.8 GiB of RAM now + <braunr> damn glibc is really long to build :) + <braunr> and i fear my vm cache patch makes non scalable algorithms negate + some of its benefits :/ + <braunr> 72 tasks, 2090 threads + <braunr> we need the ability to monitor threads somewhere + + +## IRC, freenode, #hurd, 2012-07-05 + + <braunr> hm i get kernel panics when not using the host cache :/ + <braunr> no virtual memory for stack allocations + <braunr> that's scary + <antrik> ? + <braunr> i guess the lack of host cache makes I/O slow enough to create a + big thread storm + <braunr> that completely exhausts the kernel space + <braunr> my patch challenges scalability :) + <antrik> and not having a zalloc zone anymore, instead of getting a nice + panic when trying to allocate yet another thread, you get an address + space exhaustion on an unrelated event instead. I see ;-) + <braunr> thread stacks are not allocated from a zone/cache + <braunr> also, the panic concerned aligned memory, but i don't think that + matters + <braunr> the kernel panic clearly mentions it's about thread stack + allocation + <antrik> oh, by "stack allocations" you actually mean allocating a stack + for a new thread... + <braunr> yes + <antrik> that's not what I normally understand when reading "stack + allocations" :-) + <braunr> user stacks are simple zero filled memory objects + <braunr> so we usually get a deadlock on them :> + <braunr> i wonder if making ports_manage_port_operations_multithread limit + the number of threads would be a good thing to do + <antrik> braunr: last time slpz did that, it turned out that it causes + deadlocks in at least one (very specific) situation + <braunr> ok + <antrik> I think you were actually active at the time slpz proposed the + patch (and it was added to Debian) -- though probably not at the time + where youpi tracked it down as the cause of certain lockups, so it was + dropped again... + <braunr> what seems very weird though is that we're normally using + continuations + <antrik> braunr: you mean in the kernel? how is that relevant to the topic + at hand?... + <braunr> antrik: continuations have been designed to reduce the number of + stacks to one per cpu :/ + <braunr> but they're not used everywhere + <antrik> they are not used *anywhere* in the Hurd... + <braunr> antrik: continuations are supposed to be used by kernel code + <antrik> braunr: not sure what you are getting at. of course we should use + some kind of continuations in the Hurd instead of having an active thread + for every single request in flight -- but that's not something that could + be done easily... + <braunr> antrik: oh no, i don't want to use continuations at all + <braunr> i just want to use less threads :) + <braunr> my panic definitely looks like a thread storm + <braunr> i guess increasing the kmem_map will help for the time bein + <braunr> g + <braunr> (it's not the whole kernel space that gets filled up actually) + <braunr> also, stacks are kept on a local cache until there is memory + pressure oO + <braunr> their slab cache can fill the backing map before there is any + pressure + <braunr> and it makes a two level cache, i'll have to remove that + <antrik> well, how do you reduce the number of threads? apart from + optimising scheduling (so requests are more likely to be completed before + new ones are handled), the only way to reduce the number of threads is to + avoid having a thread per request + <braunr> exactly + <antrik> so instead the state of each request being handled has to be + explicitly stored... + <antrik> i.e. continuations + <braunr> hm actually, no + <braunr> you use thread migration :) + <braunr> i don't want to artificially use the number of kernel threads + <braunr> the hurd should be revamped not to use that many threads + <braunr> but it looks like a hard task + <antrik> well, thread migration would reduce the global number of threads + in the system... it wouldn't prevent a server from having thousands of + threads + <braunr> threads would allready be allocated before getting in the server + <antrik> again, the only way not to use a thread for each outstanding + request is having some explicit request state management, + i.e. continuations + <braunr> hm right + <braunr> but we can nonetheless reduce the number of threads + <braunr> i wonder if the sync threads are created on behalf of the pagers + or the kernel + <braunr> one good thing is that i can already feel better performance + without using the host cache until the panic happens + <antrik> the tricky bit about that is that I/O can basically happen at any + point during handling a request, by hitting a page fault. so we need to + be able to continue with some other request at any point... + <braunr> yes + <antrik> actually, readahead should help a lot in reducing the number of + request and thus threads... still will be quite a lot though + <braunr> we should have a bunch of pageout threads handling requests + asynchronously + <braunr> it depends on the implementation + <braunr> consider readahead detects that, in the next 10 pages, 3 are not + resident, then 1 is, then 3 aren't, then 1 is again, and the last two + aren't + <braunr> how is this solved ? :) + <braunr> about the stack allocation issue, i actually think it's very + simple to solv + <braunr> the code is a remnant of the old BSD days, when processes were + heavily swapped + <braunr> so when a thread is created, its stack isn't allocated + <braunr> the allocation happens when the thread is dispatched, and the + scheduler finds it's swapped (which is the initial state) + <braunr> the stack is allocated, and the operation is assumed to succeed, + which is why failure produces a panic + <antrik> well, actually, not just readahead... clustered paging in + general. the thread storms happen mostly on write not read AIUI + <braunr> changing that to allocate at thread creation time will allow a + cleaner error handling + <braunr> antrik: yes, at writeback + <braunr> antrik: so i guess even when some physical pages are already + present, we should aim at larger sizes for fewer I/O requests + <antrik> not sure that would be worthwhile... probably doesn't happen all + that often. and if some of the pages are dirty, we would have to make + sure that they are ignored although they were part of the request... + <braunr> yes + <braunr> so one request per missing area ? + <antrik> the opposite might be a good idea though -- if every other page is + dirty, it *might* indeed be preferable to do a single request rewriting + even the clean ones in between... + <braunr> yes + <braunr> i personally think one request, then replace only what was + missing, is simpler and preferable + <antrik> OTOH, rewriting clean pages might considerably increase write time + (and wear) on SSDs + <braunr> why ? + <antrik> I doubt the controller is smart enough to recognies if a page + doesn't really need rewriting + <antrik> so it will actually allocate and write a new cluster + <braunr> no but it won't spread writes on different internal sectors, will + it ? + <braunr> sectors are usually really big + <antrik> "sectors" is not a term used in SSDs :-) + <braunr> they'll be erased completely whatever the amount of data at some + point if i'm right + <braunr> ah + <braunr> need to learn more about that + <braunr> i thought their internal hardware was much like nand flash + <antrik> admittedly I don't remember the correct terminology either... + <antrik> they *are* NAND flash + <antrik> writing is actually not the problem -- it can happen in small + chunks. the problem is erasing, which is only possible in large blocks + <braunr> yes + <braunr> so having larger requests doesn't seem like a problem to me + <braunr> because of that + <antrik> thus smart controllers (which pretty much all SSD nowadays have, + and apparently even SD cards) do not actually overwrite. instead, writes + always happen to clean portions, and erasing only happens when a block is + mostly clean + <antrik> (after relocating the remaining used parts to other clean areas) + <antrik> braunr: the problem is not having larger requests. the problem is + rewriting clusters that don't really need rewriting. it means the dist + performs unnecessary writing actions. + <antrik> it doesn't hurt for magnetic disks, as the head has to pass over + the unchanged sectors anyways; and rewriting the unnecessarily doesn't + increase wear + <antrik> but it's different for SSDs + <antrik> each write has a penalty there + <braunr> i thought only erases were the real penalty + <antrik> well, erase happens in the background with modern controllers; so + it has no direct penalty. the write has a direct performance penalty when + saturating the bandwith, and always has a direct wear penalty + <braunr> can't controllers handle 32k requests ? like everything does ? :/ + <antrik> sure they can. but that's beside the point... + <braunr> if they do, they won't mind the clean data inside such large + blocks + <antrik> apparently we are talking past each other + <braunr> i must be missing something important about SSD + <antrik> braunr: the point is, the controller doesn't *know* it's clean + data; so it will actually write it just like the really unclean data + <braunr> yes + <braunr> and it will choose an already clean sector for that (previously + erased), so writing larger blocks shouldn't hurt + <braunr> there will be a slight increase in bandwidth usage, but that's + pretty much all of it + <braunr> isn't it ? + <antrik> well, writing always happens to clean blocks. but writing more + blocks obviously needs more time, and causes more wear... + <braunr> aiui, blocks are always far larger than the amount of pages we + want to writeback in one request + <braunr> the only way to use more than one is crossing a boundary + <antrik> no. again, the blocks that can be *written* are actually quite + small. IIRC most SSDs use 4k nowadays + <braunr> ok + <antrik> only erasing operates on much larger blocks + <braunr> so writing is a problem too + <braunr> i didn't think it would cause wear leveling to happen + <antrik> well, I'm not sure whether the wear actually happens on write or + on erase... but that doesn't matter, as the number of blocks that need to + be erased is equivalent to the number of blocks written... + <braunr> sorry, i'm really not sure + <braunr> if you erase one sector, then write the first and third block, + it's clearly not equivalent + <braunr> i mean + <braunr> let's consider two kinds of pageout requests + <braunr> 1/ a big one including clean pages + <braunr> 2/ several ones for dirty pages only + <braunr> let's assume they both need an erase when they happen + <braunr> what's the actual difference between them ? + <braunr> wear will increase only if the controller handle it on writes, if + i'm right + <braunr> but other than that, it's just bandwidth + <antrik> strictly speaking erase is only *necessary* when there are no + clean blocks anymore. but modern controllers will try to perform erase of + unused blocks in the background, so it doesn't delay actual writes + <braunr> i agree on that + <antrik> but the point is that for each 16 pages (or so) written, we need + to erase one block so we get 16 clean pages to write... + <braunr> yes + <braunr> which is about the size of a request for the sequential policy + <braunr> so it fits + <antrik> just to be clear: it doesn't matter at all how the pages + "fit". the controller will reallocate them anyways + <antrik> what matters is how many pages you write + <braunr> ah + <braunr> i thought it would just put the whole request in a single sector + (or two) + <antrik> I'm not sure what you mean by "sector". as I said, it's not a term + used in SSD technology + <braunr> so do you imply that writes can actually get spread over different + sectors ? + <braunr> the sector is the unit at the nand flash level, its size is the + erase size + <antrik> actually, I used the right terminology... the erase unit is the + block; the write unit is the page + <braunr> sector is a synonym of block + <antrik> never seen it. and it's very confusing, as it isn't in any way + similar to sectors in magnetic disks... + <braunr> http://en.wikipedia.org/wiki/Flash_memory#NAND_flash + <braunr> it's actually in the NOR part right before, paragraph "Erasing" + <braunr> "Modern NOR flash memory chips are divided into erase segments + (often called blocks or sectors)." + <antrik> ah. I skipped the NOR part :-) + <braunr> i've only heard sector where i worked, but i don't consider french + computer engineers to be authorities on the matter :) + <antrik> hehe + <braunr> let's call them block + <braunr> so, thread stacks are allocated out of the kernel map + <braunr> this is already a bad thing (which is probably why there is a + local cache btw) + <antrik> anyways, yes. modern controllers might split a contiguous write + request onto several blocks, as well as put writes to completely + different logical pages into one block. the association between addresses + and actual blocks is completely free + <braunr> now i wonder why the kernel map is so slow, as the panic happens + at about 3k threads, so about 11M of thread stacks + <braunr> antrik: ok + <braunr> antrik: well then it makes sense to send only dirty pages + <braunr> s/slow/low/ + <antrik> it's different for raw flash (using MTD subsystem in Linux) -- but + I don't think this is something we should consider any time soon :-) + <antrik> (also, raw flash is only really usable with specialised + filesystems anyways) + <braunr> yes + <antrik> are the thread stacks really only 4k? I would expect them to be + larger in many cases... + <braunr> youpi reduced them some time ago, yes + <braunr> they're 4k on xen + <braunr> uh, 16k + <braunr> damn, i'm wondering why i created separate submaps for the slab + allocator :/ + <braunr> probably because that's how it was done by the zone allocator + before + <braunr> but that's stupid :/ + <braunr> hm the stack issue is actually more complicated than i thought + because of interrupt priority levels + <braunr> i increased the kernel map size to avoid the panic instead + <braunr> now libc0.3 seems to build fine + <braunr> and there seems to be a clear decrease of I/O :) + + +### IRC, freenode, #hurd, 2012-07-06 + + <antrik> braunr: there is a submap for the slab allocator? that's strange + indeed. I know we talked about this; and I am pretty sure we agreed + removing the submap would actually be among the major benefits of a new + allocator... + <braunr> antrik: a submap is a good idea anyway + <braunr> antrik: it avoids fragmenting the kernel space too much + <braunr> it also breaks down locking + <braunr> but we could consider it + <braunr> as a first step, i'll merge the kmem and kalloc submaps (the ones + used for the slab caches and the malloc-like allocations respectively) + <braunr> then i'll change the allocation of thread stacks to use a slab + cache + <braunr> and i'll also remove the thread swapping stuff + <braunr> it will take some time, but by the end we should be able to + allocate tens of thousands of threads, and suffer no panic when the limit + is reached + <antrik> braunr: I'm not sure "no panic" is really a worthwhile goal in + such a situation... + <braunr> antrik: uh ?N + <braunr> antrik: it only means the system won't allow the creation of + threads until there is memory available + <braunr> from my pov, the microkernel should never fail up to a point it + can't continue its job + <antrik> braunr: the system won't be able to recover from such a situation + anyways. without actual resource management/priorisation, not having a + panic is not really helpful. it only makes it harder to guess what + happened I fear... + <braunr> i don't see why it couldn't recover :/ + + +## IRC, freenode, #hurd, 2012-07-07 + + <braunr> grmbl, there are a lot of issues with making the page cache larger + :( + <braunr> it actually makes the system slower in half of my tests + <braunr> we have to test that on real hardware + <braunr> unfortunately my current results seem to indicate there is no + clear benefit from my patch + <braunr> the current limit of 4000 objects creates a good balance between + I/O and cpu time + <braunr> with the previous limit of 200, I/O is often extreme + <braunr> with my patch, either the working set is less than 4k objects, so + nothing is gained, or the lack of scalability of various parts of the + system add overhead that affect processing speed + <braunr> also, our file systems are cached, but our block layer isn't + <braunr> which means even when accessing data from the cache, accesses + still cause some I/O for metadata + + +## IRC, freenode, #hurd, 2012-07-08 + + <braunr> youpi: basically, it works fine, but exposes scalability issues, + and increases swapiness + <youpi> so it doens't help with stability? + <braunr> hum, that was never the goal :) + <braunr> the goal was to reduce I/O, and increase performance + <youpi> sure + <youpi> but does it at least not lower stability too much? + <braunr> not too much, no + <youpi> k + <braunr> most of the issues i found could be reproduced without the patch + <youpi> ah + <youpi> then fine :) + <braunr> random deadlocks on heavy loads + <braunr> youpi: but i'm not sure it helps with performance + <braunr> youpi: at least not when emulated, and the host cache is used + <youpi> that's not very surprising + <braunr> it does help a lot when there is no host cache and the working set + is greater (or far less) than 4k objects + <youpi> ok + <braunr> the amount of vm_object and ipc_port is gracefully adjusted + <youpi> that'd help us with not having to tell people to use the complex + -drive option :) + +([[hurd/running/qemu/writeback_caching]].) + + <braunr> so you can easily run a hurd with 128 MiB with decent performance + and no leak in ext2fs + <braunr> yes + <braunr> for example + <youpi> braunr: I'd say we should just try it on buildds + <braunr> (it's not finished yet, i'd like to work more on reducing + swapping) + <youpi> (though they're really not busy atm, so the stability change can't + really be measured) + <braunr> when building the hurd, which takes about 10 minutes in my kvm + instances, there is only a 30 seconds difference between using the host + cache and not using it + <braunr> this is already the case with the current kernel, since the + working set is less than 4k objects + <braunr> while with the previous limit of 200 objects, it took 50 minutes + without host cache, and 15 with it + <braunr> so it's a clear benefit for most uses, except my virtual machines + :) + <youpi> heh + <braunr> because there, the amount of ram means a lot of objects can be + cached, and i can measure an increase in cpu usage + <braunr> slight, but present + <braunr> youpi: isn't it a good thing that buildds are resting a bit ? :) + <youpi> on one hand, yes + <youpi> but on the other hand, that doesn't permit to continue + stress-testing the Hurd :) + <braunr> we're not in a hurry for this patch + <braunr> because using it really means you're tickling the pageout daemon a + lot :) + + +## [[metadata_caching]] + + +## IRC, freenode, #hurd, 2012-07-12 + + <braunr> i'm only adding a cached pages count you know :) + <braunr> (well actually, this is now a vm_stats call that can replace + vm_statistics, and uses flavors similar to task_info) + <braunr> my goal being to see that yellow bar in htop + <braunr> ... :) + <pinotree> yellow? + <braunr> yes, yellow + <braunr> as in http://www.sceen.net/~rbraun/htop.png + <pinotree> ah + + +## IRC, freenode, #hurd, 2012-07-13 + + <braunr> i always get a "no more room for vm_map_enter" error when building + glibc :/ + <braunr> but the build continues, probably a failed test + <braunr> ah yes, i can see the yellow bar :> + <antrik> braunr: congrats :-) + <braunr> antrik: thanks + <braunr> but i think my patch can't make it into the git repo until the + swap deadlock is solved (or at least very infrequent ..) + +[[libpager_deadlock]]. + + <braunr> well, the page cache accounting tells me something is wrong there + too lol + <braunr> during a build 112M of data was created, of which only 28M made it + into the cache + <braunr> which may imply something is still holding references on the + others objects (shadow objects hold references to their underlying + object, which could explain this) + <braunr> ok i'm stupid, i just forgot to subtract the cached pages from the + used pages .. :> + <braunr> (hm, actually i'm tired, i don't think this should be done) + <braunr> ahh yes much better + <braunr> i simply forgot to convert pages in kilobytes .... :> + <braunr> with the fix, the accounting of cached files is perfect :) + + +## IRC, freenode, #hurd, 2012-07-14 + + <youpi> braunr: btw, if you want to stress big builds, you might want to + try webkit, ppl, rquantlib, rheolef, yade + <youpi> they don't pass on bach (1.3GiB), but do on ironforge (1.8GiB) + <braunr> youpi: i don't need to, i already know my patch triggers swap + deadlocks more often, which was expected + <youpi> k + <braunr> there are 3 tasks concerning my work : 1/ page cache accounting + (i'm sending the patch right now) 2/ removing the fixed limit and 3/ + hunting the swap deadlock and fixing as much as possible + <braunr> 2/ can't get in the repository without 3/ imo + <youpi> btw, the increase of PAGE_FREE_* in your 2/ could go already, + couldn't it? + <braunr> yes + <braunr> but we should test with higher thresholds + <braunr> well + <braunr> it really depends on the usage pattern :/ + + +## [[ext2fs_libports_reference_counting_assertion]] + + +## IRC, freenode, #hurd, 2012-07-15 + + <braunr> concerning the page cache patch, i've been using for quite some + time now, did lots of builds with it, and i actually wonder if it hurts + stability as much as i think + <braunr> considering i didn't stress the system as much before + <braunr> and it really improves performance + + <braunr> cached memobjs: 138606 + <braunr> cache: 1138M + <braunr> i bet ext2fs can have a hard time scanning 138k entries in a + linked list, using callback functions on each of them :x + + + +## IRC, freenode, #hurd, 2012-07-16 + + <tschwinge> braunr: Sorry that I didn't have better results to present. + :-/ + <braunr> eh, that was expected :) + <braunr> my biggest problem is the hurd itself :/ + <braunr> for my patch to be useful (and the rest of the intended work), the + hurd needs some serious fixing + <braunr> not syncing from the pagers + <braunr> and scalable algorithms everywhere of course + + +## IRC, freenode, #hurd, 2012-07-23 + + <braunr> youpi: FYI, the branches rbraun/page_cache in the gnupach and hurd + repos are ready to be merged after review + <braunr> gnumach* + <youpi> so you fixed the hangs & such? + <braunr> they only the cache stats, not the "improved" cache + <braunr> no + <braunr> it requires much more work for that :) + <youpi> braunr: my concern is that the tests on buildds show stability + regression + <braunr> youpi: tschwinge also reported performance degradation + <braunr> and not the minor kind + <youpi> uh + <tschwinge> :-/ + <braunr> far less pageins, but twice as many pageouts, and probably high + cpu overhead + <braunr> building (which is what buildds do) means lots of small files + <braunr> so lots of objects + <braunr> huge lists, long scans, etc.. + <braunr> so it definitely requires more work + <braunr> the stability issue comes first in mind, and i don't see a way to + obtain a usable trace + <braunr> do you ? + <youpi> nope + <braunr> (except making it loop forever instead of calling assert() and + attach gdb to a qemu instance) + <braunr> youpi: if you think the infinite loop trick is ok, we could + proceed with that + <youpi> which assert? + <braunr> the port refs one + <youpi> which one? + <braunr> whicih prevented you from using the page cache patch on buildds + <youpi> ah, the libports one + <youpi> for that one, I'd tend to take the time to perhaps use coccicheck + actually + +[[code_analysis]]. + + <braunr> oh + <youpi> it's one of those which is supposed to be statically ananyzable + <youpi> s/n/l + <braunr> that would be great + <tschwinge> :-) + <tschwinge> And set precedence. + + +## IRC, freenode, #hurd, 2012-07-26 + + <braunr> hm i killed darnassus, probably the page cache patch again + + +## IRC, freenode, #hurd, 2012-09-19 + + <youpi> I was wondering about the page cache information structure + <youpi> I guess the idea is that if we need to add a field, we'll just + define another RPC? + <youpi> braunr: ↑ + <braunr> i've done that already, yes + <braunr> youpi: have a look at the rbraun/page_cache gnumach branch + <youpi> that's what I was referring to + <braunr> ok diff --git a/open_issues/gnumach_rpc_timeouts.mdwn b/open_issues/gnumach_rpc_timeouts.mdwn new file mode 100644 index 00000000..68cfcb5a --- /dev/null +++ b/open_issues/gnumach_rpc_timeouts.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 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, 2012-04-28 + + <pinotree> uhm, apparently mach cannot handle timeouts for rpc's of more + than (2^(sizeof(mach_msg_timeout_t) * 8) - 1) / HZ + <pinotree> it seems that how ticks are calculated in mach, it becomes 0 + <pinotree> +because of diff --git a/open_issues/gnumach_tick.mdwn b/open_issues/gnumach_tick.mdwn new file mode 100644 index 00000000..eed447f6 --- /dev/null +++ b/open_issues/gnumach_tick.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-05 + + <pinotree> braunr: wrt to mach: it seems to me it ticks every 10ms or so, + it is true? + <braunr> yes + <braunr> and it's not preemptible + <pinotree> braunr: that means a gnumach kernel currently has a maximum + uptime of almost 500 days + <braunr> pinotree: what do you mean ? + <pinotree> there's an int (or uint, i don't remember) variable that keeps + the tick count + <braunr> yes the tick variable should probably be a 64-bits type + <braunr> or a struct + <braunr> but the tick count should only be used for computation on "short" + delays + <braunr> and it should be safe to use it even when it overflows + <braunr> it's not the wall clock + <pinotree> i found that when investigating why the maximum timeout for a + mach_msg is like INT_MAX >> 2 (or 4) or something like that, also due to + the tick count + <braunr> iirc, in linux, they mostly use the lower 32-bits on 32-bits + architecture, updating the 32 upper only when necessary diff --git a/open_issues/gnumach_tlb_flushing.mdwn b/open_issues/gnumach_tlb_flushing.mdwn new file mode 100644 index 00000000..45d0730d --- /dev/null +++ b/open_issues/gnumach_tlb_flushing.mdwn @@ -0,0 +1,21 @@ +[[!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. + + <tschwinge> gianluca, youpi: Why the value 32 for the TLB flushing decision, by the way? + <youpi> completely arbitrary + <tschwinge> I thought whether that might perhaps be worth a macro definition with a comment? + <verte> what's the typical TLB size these days? + <youpi> tschwinge: right + <youpi> note that the 32 value would be probably different between native and xen + <gianluca> tschwinge: just arbitrary diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn new file mode 100644 index 00000000..7739f4d1 --- /dev/null +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -0,0 +1,202 @@ +[[!meta copyright="Copyright © 2011, 2012 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-07-20 + + <braunr> could we add gnumach forward map entry merging as an open issue ? + <braunr> probably hurting anything using bash extensively, like build most + build systems + <braunr> mcsim: this map entry merging problem might interest you + <braunr> tschwinge: see vm/vm_map.c, line ~905 + <braunr> "See whether we can avoid creating a new entry (and object) by + extending one of our neighbors. [So far, we only attempt to extend from + below.]" + <braunr> and also vm_object_coalesce + <braunr> "NOTE: Only works at the moment if the second object is NULL - + if it's not, which object do we lock first?" + <braunr> although map entry merging should be enough + <braunr> this seems to be the cause for bash having between 400 and 1000+ + map entries + <braunr> thi makes allocations and faults slow, and forks even more + <braunr> but again, this should be checked before attempting anything + <braunr> (for example, this comment still exists in freebsd, although they + solved the problem, so who knows) + <antrik> braunr: what exactly would you want to check? + <antrik> braunr: this rather sounds like something you would just have to + try... + <braunr> antrik: that map merging is actually incomplete + <braunr> and that entries can actually be merged + <antrik> hm, I see... + <braunr> (i.e. they are adjacent and have compatible properties + <braunr> ) + <braunr> antrik: i just want to avoid the "hey, splay trees mak fork slow, + let's work on it for a month to see it wasn't the problem" + <antrik> so basically you need a dump of a task's map to check whether + there are indeed entries that could/should be merged? + <antrik> hehe :-) + <braunr> well, vminfo should give that easily, i just didn't take the time + to check it + <jkoenig> braunr, as you pointed out, "vminfo $$" seems to indicate that + merging _is_ incomplete. + <braunr> this could actually have a noticeable impact on package builds + <braunr> hm + <braunr> the number of entries for instances of bash running scripts don't + exceed 50-55 :/ + <braunr> the issue seems to affect only certain instances (login shells, + and su -) + <braunr> jkoenig: i guess dash is just much lighter than bash in many ways + :) + <jkoenig> braunr, the number seems to increase with usage (100 here for a + newly started interactive shell, vs. 150 in an old one) + <braunr> yes, merging is far from complete in the vm_map code + <braunr> it only handles null objects (private zeroed memory), and only + tries to extend a previous entry (this isn't even a true merge) + <braunr> this works well for the kernel however, which is why there are so + few as 25 entries + <braunr> but any request, be it e.g. mmap(), or mprotect(), can easily + split entries + <braunr> making their number larger + <jkoenig> my ext2fs has ~6500 entries, but I guess this is related to + mapping blocks from the filesystem, right? + <braunr> i think so + <braunr> hm not sure actually + <braunr> i'd say it's fragmentation due to copy on writes when client have + mapped memory from it + <braunr> there aren't that many file mappings though :( + <braunr> jkoenig: this might just be the same problem as in bash + <braunr> 0x1308000[0x3000] (prot=RW, max_prot=RWX, mem_obj=584) + <braunr> 0x130b000[0x6000] (prot=RW, max_prot=RWX, mem_obj=585) + <braunr> 0x1311000[0x3000] (prot=RX, max_prot=RWX, mem_obj=586) + <braunr> 0x1314000[0x1000] (prot=RW, max_prot=RWX, mem_obj=586) + <braunr> 0x1315000[0x2000] (prot=RX, max_prot=RWX, mem_obj=587) + <braunr> the first two could be merged but not the others + <jkoenig> theoritically, those may correspond to memory objects backed by + different portions of the disk, right? + <braunr> jkoenig: this looks very much like the same issue (many private + mappings not merged) + <braunr> jkoenig: i'm not sure + <braunr> jkoenig: normally there is an offset when the object is valid + <braunr> but vminfo may simply not display it if 0 + * jkoenig goes read about memory object + <braunr> ok, vminfo can't actually tell if the object is anonymous or + file-backed memory + <jkoenig> (I'm perplexed about how the kernel can merge two memory objects + if disctinct port names exist in the tasks' name space -- that's what + mem_obj is, right?) + <braunr> i don't see why + <braunr> jkoenig: can you be more specific ? + <jkoenig> braunr, if, say, 584 and 585 above are port names which the task + expects to be able to access and do stuff with, what will happen to them + when the memory objects are merged? + <braunr> good question + <braunr> but hm + <braunr> no it's not really a problem + <braunr> memory objects aren't directly handled by the vm system + <braunr> vm_object and memory_object are different things + <braunr> vm_objects can be split and merged + <braunr> and shadow objects form chains ending on a final vm_object + <braunr> which references a memory object + <braunr> hm + <braunr> jkoenig: ok no solution, they can't be merged :) + <jkoenig> braunr, I'm confused :-) + <braunr> jkoenig: but at least, if two vm_objects are created but reference + the same externel memory object, the vm should be able to merge them back + <braunr> external* + <braunr> are created as a result of a split + <braunr> say, you map a memory object, mprotect part of it (=split), then + mprotect the reste of it (=merge), it should work + <braunr> jkoenig: does that clarify things a bit ? + <jkoenig> ok so if I get it right, the entries shown by vmstat are the + vm_object, and the mem_obj listed is a send right to the memory object + they're referencing ? + <braunr> yes + <braunr> i'm not sure about the type of the integer showed (port name or + simply an index) + <braunr> jkoenig: another possibility explaining the high number of entries + is how anonymous memory is implemented + <braunr> if every vm_allocate request implies the creation of a memory + object from the default pager + <braunr> the vm has no way to merge them + <jkoenig> and a vm_object is not a capability, but just an internal kernel + structure used to record the composition of the address space + <braunr> jkoenig: not exactly the address space, but close enough + <braunr> jkoenig: it's a container used to know what's in physical memory + and what isn't + <jkoenig> braunr, ok I think I'm starting to get it, thanks. + <braunr> glad i could help + <braunr> i wonder when vm_map_enter() gets null objects though :/ + <braunr> "If this port is MEMORY_OBJECT_NULL, then zero-filled memory is + allocated instead" + <braunr> which means vm_allocate() + <jkoenig> braunr, when the task uses vm_allocate(), or maybe vm_map_enter() + with MEMORY_OBJECT_NULL, there's an opportunity to extend an existing + object though, is that what you referred to earlier ? + <braunr> jkoenig: yes, and that's what is done + <jkoenig> but how does that play out with the default pager? (I'm thinking + aloud, as always feel free to ignore ;-) + <braunr> the default pager backs vm_objects providing zero filled memory + <braunr> hm, guess it wasn't your question + <braunr> well, swap isn't like a file, pages can be placed dynamically, + which is why the offset is always 0 for this type of memory + <jkoenig> hmm I see, apparently a memory object does not have a size + <braunr> are you sure ? + <jkoenig> from what I can gather from + http://www.gnu.org/software/hurd/gnumach-doc/External-Memory-Management.html, + but I looked very quickly + <braunr> vm_objects have a size + <braunr> and each map entry recors the offset within the object where the + mapping begins + <braunr> offset and sizes are used by the kernel when querying the memory + object pager + <braunr> see memory_object_data_request for example + <jkoenig> right. + <braunr> but the default pager has another interface + <braunr> jkoenig: after some simple tests, i haven't seen a simple case + where forward merging could be applied :( + <braunr> which means it's a lot harder than it first looked + <braunr> hm + <braunr> actually, there seems to be cases where this can be done + <braunr> all of them occurring after a first merge was done + <braunr> (which means a mapping request perfectly fits between two map + entries) + + +# IRC, freenode, #hurd, 2011-07-21 + + <braunr> tschwinge: you may remove the forward map entry merging issue :/ + <pinotree> what did you discover? + <braunr> 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 + <braunr> from what i could see, part of the problem still exists in freebsd + <braunr> for the same reasons (shadow objects being one of them) + +[[mach_shadow_objects]]. + + +# GCC build time using bash vs. dash + +<http://gcc.gnu.org/ml/gcc/2011-07/msg00444.html> + + +# Procedure + + * Analyze. + + * Measure. + + * Fix. + + * Measure again. + + * Have Samuel measure on the buildd. diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn new file mode 100644 index 00000000..53ff66c5 --- /dev/null +++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn @@ -0,0 +1,346 @@ +[[!meta copyright="Copyright © 2012 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, 2012-04-23 + + <braunr> btw, i'm running a gnumach version using red-black trees for vm + map entries + <antrik> braunr: sounds fashionable ;-) + <youpi> braunr: with some perf improvement? + <braunr> looks promising for our ext2fs instances showing several thousands + of map entries + <braunr> youpi: i'm not using it for lookups yet + <braunr> but the tree is there, maintained, used for both regular and copy + maps, and it doesn't crash + <youpi> good :) + <braunr> antrik: isn't it ? :) + <braunr> youpi: and the diff stat is like 50/15 + <antrik> braunr: what's the goal of using the fashionable trees? + <braunr> antrik: speeding up lookups in address spaces + <antrik> braunr: so the idea is that if we have a heavily fragmented + address space, the performance penalty is smaller? + <braunr> yes + <antrik> OK + <antrik> I take it you gave up on attempts to actually decrease + fragmentation?... + <braunr> it's not as good as reducing fragmentation, which requires + implementing a powerful merge, but it's still better + <braunr> yes + <braunr> it's too messy for my brain :/ + <antrik> I see + <antrik> oh + <braunr> it will add some overhead though + <youpi> I guess log(n) ? + <braunr> but if there is a significant performance gain, it'll be worth it + <braunr> yes + <braunr> i was more thinking about the memory overhead + <antrik> right now it's a linear list? + <youpi> I don't think we care nowadays :) + <braunr> antrik: yes + <antrik> ouch + <braunr> antrik: yes ... :> + <braunr> the original authors expected vm maps to have like 30 entries + <braunr> so they used a list for the maps, and a hash table for the + object/offset to physical page lookups + <braunr> there is a small lookup cache though, which is a nice optimization + <braunr> my code now uses it first, and falls back to the RB tree if the + hint didn't help + <antrik> braunr: well, don't forget to check whether it actually *is* still + an optimisation, when using fashionable trees ;-) + <braunr> antrik: i checked that already :) + <braunr> i did the same in x15 + <antrik> I see + <braunr> both bsd and linux uses a similar technique + <braunr> use* + <braunr> (well, bsd actually use what is done in mach :) + <antrik> (or perhaps the other way around... ;-) ) + <braunr> i don't think so, as the bsd vm is really the mach vm + <braunr> but we don't care much + <antrik> oh, right... that part actually went full circle + <braunr> youpi: i have a patch ready for test on machines with significant + amounts of map entries (e.g. the buildds ..) + <braunr> youpi: i won't have time for tests tonight, are you interested ? + <braunr> (i've been running it for 15 minutes without any issue for now) + <youpi> I'd say post to the list + <braunr> ok + <youpi> braunr: your patch uses the rb tree for lookups, right? + <youpi> braunr: the buildd using rbtree seems swift + <youpi> but maybe it's just a psychologic effect :) + <youpi> the chroot ext2fs already has 1392 lines in vminfo + <youpi> an rbtree can't hurt there :) + <youpi> braunr: it really seems faster + <youpi> the reboot might have helped too + <youpi> benchmarks shall say + <youpi> for now, I'll just let ironforge use it + <antrik> youpi: it's always fast after a reboot ;-) + <youpi> sure + <youpi> but still + <youpi> I mean + <youpi> *obviously* the reboot has helped + <youpi> but it might not be all + <youpi> at least it feels so + <youpi> and obviously only benchmarks can say + <antrik> the major benefit AIUI is rather that the slowdown happening over + time will be less noticable + +[[performance/degradation]]. + + <youpi> "over time" is actually quite fast + <youpi> ext2 fills up very quickly when you build a package + <youpi> it went up to 1700 lines very quickly + <youpi> and stabilized around there + <antrik> yeah, it can be very fast under heavy load + <youpi> that's why I say reboot seems not all + <youpi> it's already not so fresh + <youpi> with 1700 lines in vminfo + <antrik> well, I don't know how much of the slowdown I'm experiencing + (after doing stuff under memory pressure) is actually related to VM map + fragmentation... + <antrik> might be all, might be none, might be something in between + <youpi> then try his patch + <antrik> guess I should play a bit with vminfo... + <antrik> well, currently I actually experience pretty little slowdown, as + for certain reasons (only indirectly related to the Hurd) I'm not running + mutt on this machine, so I don't really have memory pressure... + + +## IRC, freenode, #hurd, 2012-04-24 + + <braunr> youpi: yes, it uses bst lookups + <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+ + map entries, and another around 7.5k + <braunr> (on ironforge) + + +## IRC, freenode, #hurd, 2012-04-24 + + <youpi> braunr: $ sudo vminfo 624 | wc -l + <youpi> 22957 + <youpi> there's no way it can not help :) + <braunr> youpi: 23k, that's really huge + + +## IRC, freenode, #hurd, 2012-04-26 + + <braunr> youpi: any new numbers wrt the rbtree patch ? + <youpi> well, buildd times are not really accurate :) + <youpi> but what I can tell is that it managed to build qtwebkit fine + <braunr> ok + <youpi> so the patch is probably safe :) + <braunr> i'll commit it soon then + <youpi> I'd say feel free to, yes + <braunr> thanks + + +## IRC, freenode, #hurd, 2012-04-27 + + <braunr> elmig: don't expect anything grand though, this patch is mostly + useful when address spaces get really fragmented, which mainly happens on + buildds + <braunr> (and it only speeds lookups, which isn't as good as reducing + fragmentation; things like fork still have to copy thousands of map + entries) + +[[glibc/fork]]. + + +## IRC, freenode, #hurdfr, 2012-06-02 + + <youpi> braunr: oh, un bug de rbtree + <youpi> Assertion `diff != 0' failed in file "vm/vm_map.c", line 1002 + <youpi> c'est dans rbtree_insert() + <youpi> vm_map_enter (vm/vm_map.c:1002). + <youpi> vm_map (vm/vm_user.c:373). + <youpi> syscall_vm_map (kern/ipc_mig.c:657). + <youpi> erf j'ai tué mon débuggueur, je ne peux pas inspecter plus + <youpi> le peu qui me reste c'est qu'apparemment target_map == 1, size == + 0, mask == 0 + <youpi> anywhere = 1 + <braunr> youpi: ça signifie sûrement que des adresses overlappent + <braunr> je rejetterai un coup d'oeil sur le code demain + <braunr> (si ça se trouve c'est un bug rare de la vm, le genre qui fait + crasher le noyau) + <braunr> (enfin jveux dire, qui faisait crasher le noyau de façon très + obscure avant le patch rbtree) + + +### IRC, freenode, #hurd, 2012-07-15 + + <bddebian> I get errors in vm_map.c whenever I try to "mount" a CD + <bddebian> Hmm, this time it rebooted the machine + <bddebian> braunr: The translator set this time and the machine reboots + before I can get the full message about vm_map, but here is some of the + crap I get: http://paste.debian.net/179191/ + <braunr> oh + <braunr> nice + <braunr> that may be the bug youpi saw with my redblack tree patch + <braunr> bddebian: assert(diff != 0); ? + <bddebian> Aye + <braunr> good + <braunr> it means we're trying to insert a vm_map_entry at a region in a + map which is already occupied + <bddebian> Oh + <braunr> and unlike the previous code, the tree actually checks that + <braunr> it has to + <braunr> so you just simply use the iso9660fs translator and it crashes ? + <bddebian> Well it used to on just trying to set the translator. This time + I was able to set the translator but as soon as I cd to the mount point I + get all that crap + <braunr> that's very good + <braunr> more test cases to fix the vm + + +### IRC, freenode, #hurd, 2012-11-01 + + <youpi> braunr: Assertion `diff != 0' failed in file "vm/vm_map.c", line + 1002 + <youpi> that's in rbtree_insert + <braunr> youpi: the problem isn't the tree, it's the map entries + <braunr> some must overlap + <braunr> if you can inspect that, it would be helpful + <youpi> I have a kdb there + <youpi> it's within a port_name_to_task system call + <braunr> this assertion basically means there already is an item in the + tree where the new item is supposed to be inserted + <youpi> this port_name_to_task presence in the stack is odd + <braunr> it's in vm_map_enter + <youpi> there's a vm_map just after that (and the assembly trap code + before) + <youpi> I know + <youpi> I'm wondering about the caller + <braunr> do you have a way to inspect the inserted map entry ? + <youpi> I'm actually wondering whether I have the right kernel in gdb + <braunr> oh + <youpi> better + <youpi> with the right kernel :) + <youpi> 0x80039acf (syscall_vm_map) + (target_map=d48b6640,address=d3b63f90,size=0,mask=0,anywhere=1) + <youpi> size == 0 seems odd to me + <youpi> (same parameters for vm_map) + <braunr> right + <braunr> my code does assume an entry has a non null size + <braunr> (in the entry comparison function) + <braunr> EINVAL (since Linux 2.6.12) length was 0. + <braunr> that's a quick glance at mmap(2) + <braunr> might help track bugs from userspace (e.g. in exec .. :)) + <braunr> posix says the saem + <braunr> same* + <braunr> the gnumach manual isn't that precise + <youpi> I don't seem to manage to read the entry + <youpi> but I guess size==0 is the problem anyway + <mcsim> youpi, braunr: Is there another kernel fault? Was that in my + kernel? + <braunr> no that's another problem + <braunr> which became apparent following the addition of red black trees in + the vm_map code + <braunr> (but which was probably present long before) + <mcsim> braunr: BTW, do you know if there where some specific circumstances + that led to memory exhaustion in my code? Or it just aggregated over + time? + <braunr> mcsim: i don't know + <mcsim> s/where/were + <mcsim> braunr: ok + + +### IRC, freenode, #hurd, 2012-11-05 + + <tschwinge> braunr: I have now also hit the diff != 0 assertion error; + sitting in KDB, waiting for your commands. + <braunr> tschwinge: can you check the backtrace, have a look at the system + call and its parameters like youpi did ? + <tschwinge> If I manage to figure out how to do that... :-) + * tschwinge goes read scrollback. + <braunr> "trace" i suppose + <braunr> if running inside qemu, you can use the integrated gdb server + <tschwinge> braunr: No, hardware. And work intervened. And mobile phone + <-> laptop via bluetooth didn't work. But now: + <tschwinge> Pretty similar to Samuel's: + <tschwinge> Assert([...]) + <tschwinge> vm_map_enter(0xc11de6c8, 0xc1785f94, 0, 0, 1) + <tschwinge> vm_map(0xc11de6c8, 0xc1785f94, 0, 0, 1) + <tschwinge> syscall_vm_map(1, 0x1024a88, 0, 0, 1) + <tschwinge> mach_call_call(1, 0x1024a88, 0, 0, 1) + <braunr> thanks + <braunr> same as youpi observed, the requested size for the mapping is 0 + <braunr> tschwinge: thanks + <tschwinge> braunr: Anything else you'd like to see before I reboot? + <braunr> tschwinge: no, that's enough for now, and the other kind of info + i'd like are much more difficult to obtain + <braunr> if we still have the problem once a small patch to prevent null + size is applied, then it'll be worth looking more into it + <pinotree> isn't it possible to find out who called with that size? + <braunr> not easy, no + <braunr> it's also likely that the call that fails isn't the first one + <pinotree> ah sure + <pinotree> braunr: making mmap reject 0 size length could help? posix says + such size should be rejected straight away + <braunr> 17:09 < braunr> if we still have the problem once a small patch to + prevent null size is applied, then it'll be worth looking more into it + <braunr> that's the idea + <braunr> making faulty processes choke on it should work fine :) + <pinotree> «If len is zero, mmap() shall fail and no mapping shall be + established.» + <pinotree> braunr: should i cook up such patch for mmap? + <braunr> no, the change must be applied in gnumach + <pinotree> sure, but that could simply such condition in mmap (ie avoiding + to call io_map on a file) + <braunr> such calls are erroneous and rare, i don't see the need + <pinotree> ok + <braunr> i bet it comes from the exec server anyway :p + <tschwinge> braunr: Is the mmap with size 0 already a reproducible testcase + you can use for the diff != 0 assertion? + <tschwinge> Otherwise I'd have a reproducer now. + <braunr> tschwinge: i'm not sure but probably yes + <tschwinge> braunr: Otherwise, take GDB sources, then: gcc -fsplit-stack + gdb/testsuite/gdb.base/morestack.c && ./a.out + <tschwinge> I have not looked what exactly this does; I think -fsplit-stack + is not really implemented for us (needs something in libgcc we might not + have), is on my GCC TODO list already. + <braunr> tschwinge: interesting too :) + + +### IRC, freenode, #hurd, 2012-11-19 + + <tschwinge> braunr: Hmm, I have now hit the diff != 0 GNU Mach assertion + failure during some GCC invocation (GCC testsuite) that does not relate + to -fsplit-stack (as the others before always have). + <tschwinge> Reproduced: + /media/erich/home/thomas/tmp/gcc/hurd/master.build/gcc/xgcc + -B/media/erich/home/thomas/tmp/gcc/hurd/master.build/gcc/ + /home/thomas/tmp/gcc/hurd/master/gcc/testsuite/gcc.dg/torture/pr42878-1.c + -fno-diagnostics-show-caret -O2 -flto -fuse-linker-plugin + -fno-fat-lto-objects -fcompare-debug -S -o pr42878-1.s + <tschwinge> Will check whether it's the same backtrace in GNU Mach. + <tschwinge> Yes, same. + <braunr> tschwinge: as youpi seems quite busy these days, i'll cook a patch + and commit it directly + <tschwinge> braunr: Thanks! I have, by the way, confirmed that the + following is enough to trigger the issue: vm_map(mach_task_self(), 0, 0, + 0, 1, 0, 0, 0, 0, 0, 0); + <tschwinge> ... and before the allocator patch, GNU Mach did accept that + and return 0 -- though I did not check what effect it actually has. (And + I don't think it has any useful one.) I'm also reading that as of lately + (Linux 2.6.12), mmap (length = 0) is to return EINVAL, which I think is + the foremost user of vm_map. + <pinotree> tschwinge: posix too says to return EINVAL for length = 0 + <braunr> yes, we checked that earlier with youpi + +[[!message-id "87sj8522zx.fsf@kepler.schwinge.homeip.net"]]. + + <braunr> tschwinge: well, actually your patch is what i had in mind + (although i'd like one in vm_map_enter to catch wrong kernel requests + too) + <braunr> tschwinge: i'll work on it tonight, and do some testing to make + sure we don't regress critical stuff (exec is another major direct user + of vm_map iirc) + <tschwinge> braunr: Oh, OK. :-) diff --git a/open_issues/gnumach_vm_object_resident_page_count.mdwn b/open_issues/gnumach_vm_object_resident_page_count.mdwn new file mode 100644 index 00000000..cc1b8897 --- /dev/null +++ b/open_issues/gnumach_vm_object_resident_page_count.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-03 + + <braunr> omg the ugliness + <braunr> the number of pages in physical memory for on object is a short + ... which limits the amount to .. 128 MiB + * braunr cries + <braunr> luckily, this should be easy to solve + +`vm/vm_object.h:vm_object:resident_page_count`. diff --git a/open_issues/grub_legacy.mdwn b/open_issues/grub_legacy.mdwn deleted file mode 100644 index cb69d10b..00000000 --- a/open_issues/grub_legacy.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -[[!meta copyright="Copyright © 2005, 2009 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="GRUB (legacy)"]] - -[[!tag open_issue_porting]] - -Even though it is customarily used *for* booting GNU/Hurd systems, [[GRUB]], -specifically GRUB legacy (which is still in wide-spread use, despite that -rather depricative nickname), has never been ported to be installable when -attempted to be installed *from* GNU/Hurd systems: - - # grub-install \(hd0\) - df: Warning: cannot read table of mounted filesystems - df: Warning: cannot read table of mounted filesystems - Could not find device for /boot: Not found or not a block device. - -There is a patch, [[grub-install.patch]], to fix that. - - -`grub-install`, however, still fails while invoking `grub`: - - # grub-install \(hd0\) - The file /boot/grub/stage1 not read correctly. - - # grub - [...] - grub> dump (hd0,0)/boot/grub/stage1 /tmp/grub_stage1 - - Error 18: Selected cylinder exceeds maximum supported by BIOS - - -The successor, [[GRUB2]], also needs to be ported. diff --git a/open_issues/grub_legacy/grub-install.patch b/open_issues/grub_legacy/grub-install.patch deleted file mode 100644 index 3f6341b4..00000000 --- a/open_issues/grub_legacy/grub-install.patch +++ /dev/null @@ -1,23 +0,0 @@ -2005-08-23 Thomas Schwinge <tschwinge@gnu.org> - - * grub-install (find_device): Rough port for GNU/Hurd. - - ---- grub-install.orig 2005-08-23 16:56:02.000000000 +0200 -+++ grub-install 2005-08-23 17:01:55.000000000 +0200 -@@ -263,7 +263,14 @@ - find_device () { - # For now, this uses the program `df' to get the device name, but is - # this really portable? -- tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'` -+ # No. (Not even on GNU/Linux.) - Thomas Schwinge -+ -+ case $host_os in -+ gnu*) # TODO: What about using multiple devices? -+ tmp_fname=`fsysopts $1/ | sed -n 's%.*device:\([^ ]*\).*%/dev/\1%p'`;; -+ *) -+ tmp_fname=`df $1/ | sed -n 's%.*\(/dev/[^ ]*\).*%\1%p'`;; -+ esac - - if test -z "$tmp_fname"; then - echo "Could not find device for $1" 2>&1 diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn new file mode 100644 index 00000000..6146885d --- /dev/null +++ b/open_issues/hurd_101.mdwn @@ -0,0 +1,41 @@ +[[!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]]."]]"""]] + +(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) + +Not the first time that something like this is proposed... + +IRC, freenode, #hurd, 2011-07-25 + + [failed GNU/Hurd project] + < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many + many people who insist on picking a hard task; realizing that indeed it's + hard; and going into hiding + < antrik> we see that happen every couple of months + < cluck> maybe we need a "hurd 101" + < cluck> getting a teacher and setting up a regularly held "class" for hurd + noobs + < Tekk_> cluck: what would that include? + < cluck> explaining core concepts, giving out "homework" (small tasks), etc + +[[Anatomy_of_a_Hurd_system]]. + + < cluck> that way "the big guys" could focus on the hard stuff and have an + army of code monkeys at their disposal to write speced stuff + < cluck> (then again this idea would heavily depend on available "teachers" + and "students", which, going by gsoc numbers, may not be all that + helpful) + < Tekk_> cluck: gsoc isn't an accurate indicator + < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P + < antrik> cluck: we don't need code monkeys... we need hackers + < Tekk_`> antrik: code monkeys involve into hackers + < Tekk_`> under the right conditions + < cluck> antrik: jokes aside some sort of triage system/training ground for + newcomers could be helpful diff --git a/open_issues/hurd_build_without_parted.mdwn b/open_issues/hurd_build_without_parted.mdwn new file mode 100644 index 00000000..06ecf56d --- /dev/null +++ b/open_issues/hurd_build_without_parted.mdwn @@ -0,0 +1,16 @@ +[[!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]] + +Seen with `cross-gnu`. + +If the *parted* libraries aren't available, we explicitly have to set +`--without-parted` or the build will fail. diff --git a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn new file mode 100644 index 00000000..b1eaf9a5 --- /dev/null +++ b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009, 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, #hurd, 2009-08-25 + + <cfhammar> also I fixed (what I think is) a bug in hurd_file_name_lookup_retry when opening FDs with FS_RETRY_MAGIC + <cfhammar> it didn't actually reopen the FD, rather it just (effectively) duped it + <scolobb> cfhammar: That's great! I think I had some problems because of not being able to truly reopen a port to a file. + <antrik> cfhammar: what is the difference, and why do you consider it a bug?... + <cfhammar> antrik: for one thing you can't change open modes, and it doesn't reset the file cursor + <cfhammar> (which I actually needed, though I could have done it manually) + <cfhammar> antrik: and also it isn't consistant with linux + <cfhammar> you can trigger the bug from the shell: cat /dev/fd/3 3>> /tmp/foo + <antrik> cfhammar: I can't say that I understand the test case... but I can at least confirm that it behaves differently on Hurd and on Linux :-) diff --git a/open_issues/hurdextras.mdwn b/open_issues/hurdextras.mdwn new file mode 100644 index 00000000..d4f9d1bc --- /dev/null +++ b/open_issues/hurdextras.mdwn @@ -0,0 +1,95 @@ +[[!meta copyright="Copyright © 2010, 2012 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]]."]]"""]] + +This is about merging some hurdextras stuff into Hurd proper repostitories. + +[[!toc levels=2]] + + +# OK + +## mboxfs + +Tarball-import, plus trivial changes. + + * Ludovic Courtes -- OK + * mmenal -- OK + +## notice + +Tarball-import. + + * Wolfgang Jährling <wolfgang@pro-linux.de> -- OK + +## run + +Tarball-import. + + * Marcus Brinkmann <marcus@gnu.org> -- OK + * Manuel Menal <mmenal@hurdfr.org> -- OK + + +# Not Interesting + +## procfs + +Not interesting anymore, but perhaps import for posterity? Likewise for Neal's +tarball(s). + + +# Not OK + +Sent email to all *NOK*s on 2012-07-14, asking for assignment. + + +## httpfs + + * Arun V. <arunsark@yahoo.com> -- NOK + * Gopika U. K. <gopika78@yahoo.com> -- NOK + * mrphython / James A. Morrison <ja2morri@uwaterloo.ca> -- OK + +## ipc_guide + + * Manuel Pavón Valderrama <mpavon@ugr.es> -- NOK + * <cp46tan@hotpop.com> -- NOK + +## jfs + + * Sajith T S <sajith@symonds.net> -- NOK + * mmenal / Manuel Menal <mmenal@hurdfr.org> -- OK + +## memfs + + * Farid Hajji <farid.hajji@ob.kamp.net> -- NOK + * Ludovic Courtes <ludo@chbouib.org> -- OK + * mmenal -- OK + +## pith + +[[tschwinge]] has some tarballs, too. + + * John Tobey <jtobey@john-edwin-tobey.org> -- NOK + * Manuel Menal <mmenal@hurdfr.org> -- OK + +## pptop + + * Miles Bader -- OK + * Paul Emsley <paule@chem.gla.ac.uk> -- NOK + * James Morrison -- OK + * Neal Walfield -- OK + * Jon Arney <jarney1@cox.net> -- OK + * Alfredo Beaumont Sainz <alfredo.beaumont@gmail.com> -- NOK (but trivial) -- OK + +## xmlfs + +Tarball-import. + + * Marc de Saint Sauveur <marc@hurdfr.org> -- NOK + * mmenal -- OK diff --git a/open_issues/ifunc.mdwn b/open_issues/ifunc.mdwn new file mode 100644 index 00000000..c357c99c --- /dev/null +++ b/open_issues/ifunc.mdwn @@ -0,0 +1,49 @@ +[[!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 +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_binutils open_issue_gcc open_issue_glibc]] + +Needs porting / support in [[/binutils]] and [[/glibc]], and then some target +configure magic for [[/GCC]]. + +<http://nickclifton.livejournal.com/6612.html> has a short summary about how to +use it from GCC. + + * binutils + + Already passes the ifunc testsuite bits for GAS, but notably for LD + (`ld/testsuite/ld-ifunc/ifunc.exp`), too, but that one contains a bunch of + stuff explicitly tailored towards Linux. For example, we get *OS/ABI: UNIX + - Linux*. (This should be fixed through using [[toolchain/ELFOSABI_GNU]].) + + Most of the executables that the testsuite generates don't actually + execute. (Though, this is partly due to the [[static + issue|binutils#static]].) + + $ tmpdir/local_prog + ifunc working correctly + $ tmpdir/static_prog + Killed + $ tmpdir/dynamic_prog + tmpdir/dynamic_prog: error while loading shared libraries: ./tmpdir/libshared_ifunc.so: ELF file OS ABI invalid + $ tmpdir/static_nonifunc_prog + Killed + $ tmpdir/test-1 + tmpdir/test-1: error while loading shared libraries: tmpdir/libshared_ifunc.so: ELF file OS ABI invalid + + * [[glibc]] + + * [[libc_variant_selection]] + + * [[GCC]] + + In `gcc/config.gcc`, set `default_gnu_indirect_function=yes` for us, like + done for GNU/Linux. See thread starting at [[!message-id + "CAFULd4YZsAQ6ckFjXtU5-yyv=3tYQwTJOPhU9zmJxFOrnotj8g@mail.gmail.com"]]. diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn new file mode 100644 index 00000000..220c69cc --- /dev/null +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -0,0 +1,419 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]] + +It is possible to run Hurd stuff on top of another system instead of on Mach. +One obvious variant is [[emulation]] (using [[hurd/running/QEMU]], for +example), but +doing that does not really integratable the Hurd guest into the host system. +There is also a more direct way, more powerful, but it also has certain +requirements to do it effectively. + +See also [[Mach_on_top_of_POSIX]]. + + +# IRC, freenode, #hurd, August / September 2010 + + <marcusb> silver_hook: the Hurd can also refer to the interfaces of the + filesystems etc, and a lot of that is really just server/client APIs that + could be implemented on any system that has transferable rights to + message capabilities. + <marcusb> silver_hook: it's surprising how few systems *have* transferable + rights, though! + <marcusb> silver_hook: usually it is added as an afterthought + <marcusb> and comes with restriction + <youpi> marcusb: there's SCM_RIGHTS to transfer fds, which is quite often + available + <marcusb> youpi: yes, I know this as "fdpassing" + <marcusb> youpi: it's described in the Stevens series even + [...] + <marcusb> ArneBab: well, let me put it this way. the Linux kernel has no + interface to manipulate another tasks's virtual address space, ie you + can't map/unmap stuff in another process + <marcusb> ArneBab: you would have to use ptrace and load some stub code in + that process to make that happen. + <marcusb> ArneBab: so for complete transparent manipulation, you need a + kernel module + <marcusb> that is what the User Mode Linux kernel module does + <marcusb> ArneBab: so say you use the User Mode Linux kernel module for + that one feature. Then you can do everything that User Mode Linux can + do, which, I assure you, includes running subhurds :) + <marcusb> it can be a bit tricky to implement those features, but it is not + harder than writing a kernel in the first place + <ArneBab> So, if I got an admin to install User Mode Linux and Mach + emulation, I’d get the flexibility (and independence from admin + decisions) I have in the Hurd? + <marcusb> ArneBab: one problem is that you still use Linux. For those who + want to get rid of Linux for political reasons, that would mean complete + failure + <marcusb> ArneBab: if you have UML kernel module, you can implement Mach in + user space + <marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or + started it + +[[Mach_on_top_of_POSIX]]. + + <marcusb> ArneBab: or you can just implement parts of it and relay to Linux + for the rest + <marcusb> the point is, that if you don't care for kernel improvements, and + are sufficiently happy with the translator stuff, it's not hard to bring + the Hurd to Linux or BSD + +Continue reading about the [[benefits_of_a_native_Hurd_implementation]]. + + +# IRC, freenode, #hurd, 2010-12-28 + + <antrik> kilobug: there is no real requirement for the Hurd to run on a + microkernel... as long as the important mechanisms are provided (most + notably external pagers and Mach IPC), the Hurd could run an top of + pretty much any kernel... + <antrik> whether it makes sense is another question of course :-) + <antrik> though I must say that I'm more and more convinced running the + Hurd on top of a monolithic kernel would actually be a useful approach + for the time being... + + +# IRC, freenode, #hurd, 2011-02-11 + + <neal> marcus and I were discussing how to add Mach to Linux + <neal> one could write a module to implement Mach IPC + <neal> and another to implement Mach VM + <neal> the big thing missing with Mach VM is the ability for a tracing + process to easily map or unmap an inferior process's memory + <antrik> neal: why would a tracing process need to map the inferior's + memory? + <neal> the simple answer is that is how it is done on Mach + <antrik> neal: is it? not sure we are talking about the same thing + here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK + <neal> on linux? + <neal> I think it use /proc/pid/mem + <antrik> on Hurd + <neal> I'm talking about adding Mach to Linux + <neal> by adding some functionality to Linux + <neal> and then implementing a bunch in user space + <antrik> yeah, but I don't understand the point about mapping inferior's + memory :-( + <antrik> what would be in user space? + <neal> there are a number of different cut points + <neal> one could imagine just using Linux's device drivers, CPU scheduler, + memory management, etc. + <neal> another possibility would be something higher where Hurd processes + just use some Hurdish servers + <antrik> neal: yeah, these are all options I have been considering... too + bad I wasn't able to come to FOSDEM -- I'd love to have participated in + this discussion :-( + <antrik> neal: BTW, were you just discussing this as a hypothetical idea, + or something you are seriously considering? + <neal> I'm unlikely to work on it, sorry + <antrik> didn't really expect that :-) + <antrik> would be nice though if you could write up your conclusions... + + +# IRC, freenode, #hurd, 2012-10-12 + + <peo-xaci> do hurd system libraries make raw system calls ever + (i.e. inlined syscall() / raw assembly)? + <braunr> sure + <peo-xaci> hmm, so a hurd emulation layer would need to use ptrace if it + should be fool proof? :/ + <braunr> there is no real need for raw assembly, and the very syscalls are + all available through macros + <braunr> hum what are you trying to say ? + <peo-xaci> well, if they are done through syscall, as a function, not a + macro, then they can be intercepted with LD_PRELOAD + <peo-xaci> so applications that do Hurd (Mach?) syscalls could work on + f.e. Linux, if a special libc is injected into the program with + LD_PRELOAD + <peo-xaci> same thing with making standard Linux-applications go through + the Hurd emulation layer + <peo-xaci> without recompilation + <mel-_> peo-xaci: the second direction is implemented in glibc. + <mel-_> for the other direction, I personally see little use for it + <braunr> peo-xaci: ok i misunderstood + <braunr> peo-xaci: i don't think there is any truely direct syscall usage + in the hurd + <peo-xaci> hmm, I'm not sure I understand what directions you are referring + to mel-_ + <braunr> peo-xaci: what are you trying to achieve ? + <peo-xaci> I want to make the Hurd design more accessible by letting Hurd + application run on the Linux kernel, preferably without + recompilation. This would be done with a daemon that implements Mach and + which all syscalls would go to. + <peo-xaci> then, I also want so that standard Linux applications can go + through that Mach daemon as well, if a special libc is preloaded + <braunr> you might want to discuss this with antrik + <peo-xaci> what I'm trying to figure out specifically is if there is some + library/interface that glue Hurd with Mach and would be better suited to + emulate than Mach? Mach seems to be more of an implementation detail to + the hurd and not something an application would directly use. + <braunr> yes, the various hurd libraries (libports and libpager mostly) + <peo-xaci> From [http://www.gnu.org/software/hurd/hurd/libports.html]: + "libports is not (at least, not for now) a generalization / abstraction + of Mach ports to the functionality the Hurd needs, that is, it is not + meant to provide an interface independently of the underlying + microkernel." + <peo-xaci> Is this still true? + <peo-xaci> Does libpager abstract the rest? + <peo-xaci> (and the other hurd libraries) + <braunr> there is nothing that really abstracts the hurd from mach + <braunr> for example, reference counting often happens here and there + <braunr> and core libraries like glibc and libpthread heavily rely on it + (through sysdeps specific code though) + <braunr> libports and libpager are meant to simplify object manipulation + for the former, and pager operations for the latter + <peo-xaci> and applications, such as translators, often use Mach interfaces + directly? + <peo-xaci> correct? + <braunr> depends on what often means + <braunr> let's say they do + <peo-xaci> :/ then it probably is better to emulate Mach after all + <braunr> there was a mach on posix port a long time ago + <peo-xaci> I thought applications were completely separated from the + microkernel in use by the Hurd + <braunr> that level of abstraction is pretty new + <braunr> genode is the only system i know which does that + +[[microkernel/Genode]]. + + <braunr> and it's still for "l4 variants" + <pinotree> ah, thanks (i forgot that name) + <antrik> braunr: Genode also runs on Linux and a few other non-L4 + environments IIRC + <antrik> peo-xaci: I'm not sure binary emulation is really useful. rather, + I'd recompile stuff as "regular" Linux executables, only using a special + glibc + <antrik> where the special glibc could be basically a port of the Hurd + glibc communicating with the Mach emulation instead of real Mach; or it + could do emulation at a higher level + <antrik> a higher level emulation would be more complicated to implement, + but more efficient, and allow better integration with the ordinary + GNU/Linux environment + <antrik> also note that any regular program could be recompiled against the + HELL glibc to run in the Hurdish environment... + <antrik> (well, glibc + hurd server libraries) + <peo-xaci> I'm willing to accept that Hurd-application would need to be + recompiled to work on the HELL + <peo-xaci> but not Linux-applications :) + <antrik> peo-xaci: if you happen to understand German, there is a fairly + good overview in my thesis report ;-) + <antrik> peo-xaci: there are no "Hurd applications" or "Linux applications" + <peo-xaci> well, let me define what I mean by the terms: Hurd applications + use Hurd-specific interfaces/syscalls, and Linux applications use + Linux-specific interfaces/syscalls + <antrik> a few programs use Linux-specific interfaces (and we probably + can't run them in HELL just as we can't run them on actual Hurd); but all + other programs work in any glibc environment + <antrik> (usually in any POSIX environment in fact...) + <antrik> peo-xaci: no sane application uses syscalls + <peo-xaci> they do under the hood + <peo-xaci> I have read about inlined syscalls + <antrik> again, there are *some* applications using Linux-specific + interfaces (sometimes because they are inherently bound to Linux + features, sometimes unnecessarily) + <antrik> so far there are no applications using Hurd-specific interfaces + <peo-xaci> translators do? + <peo-xaci> they are standard executables are they not? + <peo-xaci> I would like so that translators also can be run in the HELL + <antrik> I wouldn't consider them applications. all existing translators + are pretty much components of the Hurd itself + <peo-xaci> okay, it's a question about semantics, perhaps I should use + another word than "applications" :) + <peo-xaci> for me, applications are what have a main-function, or similar + single entry point + <braunr> hum + <braunr> that's not a good enough definition + <antrik> anyways, as I said, I think recompiling translators against a + Hurdish glibc and ported translator libraries seems the most reasonable + approach to me + <braunr> let's say applications are userspace processes that make use of + services provided by the operating system + <braunr> translators being part of the operating system here + <antrik> braunr: do you know whether the Mach-on-POSIX was actually + functional, or just an abandoned experiment?... + <antrik> (I don't remember hearing of it before...) + <braunr> incomplete iirc + <peo-xaci> braunr: still, when I've explained what I meant, even if I used + the wrong term, then my previous statements should come in another light + <peo-xaci> antrik / braunr: are you still interested in hearing my + thoughts/ideas about HELL? + <antrik> oh, there is more to come? ;-) + <peo-xaci> yes! I don't think I have made myself completely understood :/ + <peo-xaci> what I envision is a HELL system that works on as low level as + feasible, to make it possible to do almost anything that can be done on + the real Hurd (except possibly testing hardware drivers and such very low + level stuff). + <braunr> sure + <peo-xaci> I want it to be more than just allowing programs to access a + virtual filesystem à la FUSE. My idea is that all user space system + libraries/programs of the Hurd should be inside the HELL as well, and + they should not be emulated. + <peo-xaci> The system should at the very least be API compatible, so at the + very most a recompilation is necessary. + <peo-xaci> I also want so that GNU/Linux-programs can access the features + of the HELL with little effort on the user. At most perhaps a script that + wraps LD_PRELOADing has to be run on the binary. Best would be if it + could work also with insane assembly programs using raw system calls, or + if glibc happens to have some well hidden syscall being inlined to raw + assembly code. + <peo-xaci> And I think I have an idea on how an implementation could + satisfy these things! + <peo-xaci> By modifying the kernel and replace those syscalls that make + sense for the Hurd/Mach + <peo-xaci> with "the kernel", I meant Linux + <braunr> it's possible but tedious and not very useful so better do that + later + <braunr> mach did something similar at its time + <braunr> there was a syscall emulation library + <peo-xaci> but isn't it about as much work as emulating the interface on + user-level? + <braunr> and the kernel cooperated so that unmodified unix binaries + performing syscalls would actually jump to functions provided by that + library, which generally made an RPC + <peo-xaci> instead of a bunch of extern-declerations, one would put the + symbols in the syscall table + <braunr> define what "those syscalls that make sense for the Hurd/Mach" + actually means + <peo-xaci> open/close, for example + <braunr> otherwise i don't see another better way than what the old mach + folks did + <braunr> well, with that old, but existing support, your open would perform + a syscall + <braunr> the kernel would catch it and redirect the caller to its syscall + emulation library + <braunr> which would call the open RPC instead + <peo-xaci> wait, so this "existing support" you're talking about; is this a + module for the Linux kernel (or a fork, or something else)? + <peo-xaci> where can I find it? + <braunr> no + <braunr> it was for mach + <braunr> in order to run unmodified unix binaries + <braunr> the opposite of what you're trying to do + <peo-xaci> ah okay + <braunr> well + <braunr> not really either :) + <peo-xaci> does posix/unix define a standard for how a syscall table should + look like, to allow binary syscall compatibility? + <braunr> absolutely not + <peo-xaci> so how could this mach module run any unmodified unix binary? if + they expected different sys calls at different offsets? + <braunr> posix specifically (and very early) states that it almost forbids + itself to deal with anything regarding to ABIs + <braunr> depends + <braunr> since it was old, there weren't that many unix systems + <braunr> and even today, there are techniques like those used by netbsd + (and many other actually) + <braunr> that are able to inspect the binary and load a syscall emulation + environment depending on its exposed ABI + <braunr> e.g. file on an executable states which system it's for + <peo-xaci> hmm, I'm not sure how a kernel would implement that in + practice.. I thought these things were so hard coded and dependent on raw + memory reads that it would not be possible + <braunr> but i really think it's not worth the time for your project + <peo-xaci> to be honest I have virtually no experience of practical kernel + programming + <braunr> with an LDT on x86 for example + <braunr> no, there is really not that much hardcoded + <braunr> quite the contrary + <braunr> there is a lot of runtime detection today + <peo-xaci> well I mean how the syscall table is read + <braunr> it's not read + <peo-xaci> it's read to find the function pointer to the syscall handler in + the kernel? + <braunr> no + <braunr> that's the really basic approach + <braunr> (and in practice it can happen of course) + <braunr> what really happens is that, for example, on linux, the user space + system call code is loaded as a virtual shared library + <braunr> use ldd on an executable to see it + <braunr> this virtual object provides code that, depending on what the + kernel has detected, will use the appropriate method to perform a system + call + <peo-xaci> but this user space system calls need to make some kind of cpu + interupt to communicate with the kernel, right? + <braunr> the glibc itself has no idea how a system call will look like in + the end + <braunr> yes + <peo-xaci> an assembler programmer would be able to get around this glue + code? + <braunr> that's precisely what is embedded in this virtual library + <braunr> it could yes + <braunr> i think even when sysenter/sysexit is supported, legacy traps are + still implemented to support old binaries + <braunr> but then all these different entry points will lead to the same + code inside the kernel + <peo-xaci> but when the glue code is used, then its API compatible, and + then I can understand that the kernel can allow different syscall + implementations for different executables + <braunr> what glue code ? + <peo-xaci> what you talked about above "the user space system call code is + loaded as a virtual shared library" + <braunr> let's call it vdso + <braunr> i have to leave in a few minutes + <braunr> keep going, i'll read later + <peo-xaci> thanks, I looked it up on Wikipedia and understand immediately + :P + <peo-xaci> so VDSOs are provided by the kernel, not a regular library file, + right? + <vdox2> What does HELL stand for :) ? + <dardevelin> vdox2, Hurd Emulation Layer for Linux + <vdox2> dardevelin: thanks + <braunr> peo-xaci: yes + <antrik> peo-xaci: I believe your goals are conflicting. a low-level + implementation makes it basically impossible to interact between the HELL + environment and the GNU/Linux environment in any meaningful way. to allow + such interaction, you *have* to have some glue at a higher semantic level + <braunr> agreed + <antrik> peo-xaci: BTW, if you want regular Linux binaries to get somehow + redirected to access HELL facilities, there is already a framework (don't + remember the name right now) that allows this kind of system call + redirection on Linux + <antrik> (it can run both through LD_PRELOAD or as a kernel module -- where + obviously only the latter would allow raw system call redirection... but + TBH, I don't think that's worthwhile anyways. the rare cases where + programs use raw system calls are usually for extremely system-specific + stuff anyways...) + <antrik> ViewOS is the name + <antrik> err... View-OS I mean + <antrik> or maybe View OS ? ;-) + <antrik> whatever, you'll find it :-) + +[[Virtual_Square_View-OS]]. + + <antrik> I'm not sure it's really worthwhile to use this either + though... the most meaningful interaction is probably at the FS level, + and that can be done with FUSE + <antrik> OHOH, View-OS probably allows doing more interesting stuff that + FUSE, such as modyfing the way the VFS works... + <antrik> OTOH + <antrik> so it could expose more of the Hurd features, at least in theory + + +## IRC, freenode, #hurd, 2012-10-13 + + <peo-xaci> antrik / braunr: thanks for your input! I'm not entirely + convinced though. :) I will probably return to this project once I have + acquired a lot more knowledge about low level stuff. I want to see for + myself whether a low level HELL is not feasible. :P + <braunr> peo-xaci: what's the point of a low level hell ? + <peo-xaci> more Hurd code can be tested in the hell, if the hell is at a + low level + <peo-xaci> at a higher level, some Hurd code cannot run, because the + interfaces they use would not be accessible from the higher level + emulation + <antrik> peo-xaci: I never said it's not possible. I actually said it would + be easier to do. I just said you can't do it low level *and* have + meaningful interaction with the host system + <peo-xaci> I don't understand why + <braunr> peo-xaci: i really don't see what you want to achieve with low + level support + <braunr> what would be unavailable with a higher level approach ? diff --git a/open_issues/inotify_file_notice_changes.mdwn b/open_issues/inotify_file_notice_changes.mdwn new file mode 100644 index 00000000..6d644788 --- /dev/null +++ b/open_issues/inotify_file_notice_changes.mdwn @@ -0,0 +1,47 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <barrucadu> I've been going through the xmlfs code, and plan to have it + monitor the backing store (xml file) for changes and update the presented + directory hierarchy when something is changed; is there a better way to + check a file for changes beyond checking its modification time every few + minutes? + <tschwinge> barrucadu: In the Hurd spirit, you'd use file_notice_changes + (fs.defs). + <barrucadu> thanks + <youpi> we should manage to work out an inotify interface around it, btw + <pochu> like gamin? + <pinotree> imho making gamin work should gain all the fam-using + applications + <pochu> (which, looking at the sources, seems to support hurd already, not + sure why it's not built) + <pinotree> pochu: the hurd_notify of gamin does not build OOTB + <pochu> > /build/buildd/gamin-0.1.10/./libgamin/gam_data.c:476: error: + 'PTHREAD_MUTEX_RECURSIVE' undeclared (first use in this function) + <pinotree> there are few patches in bugzilla to make it compile + <pochu> if they work, and you point me to them, I can upload a new gamin + with them included + <pinotree> #315644, #588337. #605246 + <pinotree> and iirc there's something else i have locally but not send yet + <pochu> please check and submit :) + <pinotree> ah no, those three contains all the build issues + <pinotree> .. plus relative proposed fixes + <pochu> ok, I'll try to get to it soonish + <pinotree> and you should know about two of them already ;D + <pochu> please remind me if I don't :) + +--- + +Apparently fanotify is cosidered inotify's successor, so we might directly go +supporting that one instead, or both. --[[tschwinge]], 2011-05-10 diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn new file mode 100644 index 00000000..72bb3b77 --- /dev/null +++ b/open_issues/issue_tracking.mdwn @@ -0,0 +1,196 @@ +[[!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]]."]]"""]] + +[[!toc]] + + +# Savannah Trackers, Open Issues, debbugs + +There are the Savannah trackers. Nobody really likes them. + +There is a proposal to add/move to <http://debbugs.gnu.org/>. It can be +operated by email, Debian people (developers and users) already know how to use +it. + +There are the [[Open_Issues]] pages. This is basically just free-form text +enriched by some tags for grouping, editable via the web and through Git +commit. [[tschwinge]] added this to the set, and/but mostly is the sole user +of it, even though casually there are a few other people contributing, and +surely these pages do show up in web searches. A more traditional system (like +the Savannah trackers or the new debbugs) do have their advantages, too, so +perhaps there's a niche for both these and the [[Open_Issues]]. + +IRC, freenode, #hurd, 2011-08-31: + + <tschwinge> So. Savannah trackers vs. Open Issues vs. debbugs. Any input? + <youpi> I like *both* open issues and debbugs + <youpi> open issues is good for exposing things that people may encounter + in other situations + <youpi> while debbugs is useful to actually work on a bug + <tschwinge> youpi: The advantage of debbugs being the email interface and + the well-known procedure, or something else? + <youpi> email interface, which nicely flows into a mailing list + <youpi> the savannah bug updates suffer from the additional layout + <tschwinge> How does one decide what to put in a debbug and what in an Open + Issue page? + <youpi> I'd say it's not exclusive at all + <youpi> like, a bug on a specific case can start as debbug, and as we + discover it's more general and will not be fixed immediately, get an open + issue page + <youpi> and conversely, when we know some shortcoming, start with an open + issue, and if some bugs are submitted which are actually due to it, + cross-link + <tschwinge> OK. + <youpi> (some general short coming I mean, like SIGINFO) + <tschwinge> And we would keep the current stuff in the trackers, and let + these ``get empty'' gradually (it'll be years...) ;-) or migrate the + remaining issues? + <tschwinge> What we can do is inhibiting the creation of new issues in the + trackers. + <youpi> I'd say move + <youpi> else they will be forgotten + <tschwinge> Hrm. + <antrik> actually, I considered creating a track-like plugin for ikiwiki, + as both the popularity of trac and the usefulness of open_issues show + that something wiki-like is actually more useful than a rigid traditional + bugtracker. but I'm not really willing to do the work, which is why I + didn't propose it before :-) + <antrik> err... trac-like + <youpi> yes, the wiki part is really useful to keep a good summary of the + issue + <tschwinge> antrik: Same for me. I always hoped that someone would do + it... :-) + <antrik> hehe + <tschwinge> antrik: But, as you surely know, this email parsing business is + just too ugly to do realiable, etc. + <antrik> youpi: my point is that adding a few additional bits (like a + comfortable tagging functionality, and some mail interface) could turn + into a full-blown tracker unifying the advantages of both... but as I + said, I'm not really willing to do the work :-) + <youpi> additional to open_issue you mean? + <youpi> yes, but like you say :) + <antrik> tschwinge: hm... seems to work well enough it debbugs + <youpi> debbugs just piles things + <youpi> and has a few commands + <youpi> you'd still need the web interface to edit the wiki part for + instance + <antrik> of course. that wouldn't change at all + <antrik> (except for adding a tagging GUI perhaps) + <antrik> (debbugs of course is not the only mail-operable bugtracking + system... there are a number of others -- and I heard rumors even + bugzilla grew a mail interface now...) + <youpi> antrik: a .mdwn diff should however be sent to the bug for + information + <youpi> atm, what happens sometimes is somebody saying something here on + #hurd, tschwinge turning that into an open_issue, and it does not show up + on the mailing list + <tschwinge> debbugs surely has the advantage that it is available (nearly) + right now. + <mattl> RT (request tracker) and ikiwiki play quite nicely together. + <tschwinge> mattl: You'Re using that at GNU/FSF/somewhere, right? + <mattl> you can close tickets from the wiki, and RT has a good command line + interface, email interface and web interface. + <mattl> tschwinge: yeah, we use RT and ikiwiki. + <mattl> RT for all FSF communications, and ikiwiki for internal organising. + <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 + + * ikiwiki + + * <http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/> + + * <http://ikiwiki.info/todo/Better_bug_tracking_support/> + + * <http://ikiwiki.info/todo/tracking_bugs_with_dependencies/> + + * <http://ikiwiki.info/todo/Updated_bug_tracking_example/> + + * <http://bugseverywhere.org/> diff --git a/open_issues/keymap_mach_console.mdwn b/open_issues/keymap_mach_console.mdwn new file mode 100644 index 00000000..3063dd00 --- /dev/null +++ b/open_issues/keymap_mach_console.mdwn @@ -0,0 +1,40 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-04-26 + + <guillem> pavkac: btw are you aware there's already some code to change the + keymap for the mach console (I think originally from the hurdfr guys, but + I cannot remember exactly from where I got it from :/) + <guillem> pavkac: http://www.hadrons.org/~guillem/tmp/hurd-keymap.tgz + <pavkac> guillem: No, I didn't know. I'll diff it and try to follow. + <guillem> pavkac: it would be nice to maybe integrate it properly into the + hurd + <guillem> you'll see the code is pretty basic, so extending it would be + nice too I guess :) + <pavkac> guillem: OK, I'll see to it. Unfortunately I'm quite busy this + week. Have a lot of homeworks to school. :/ + <pavkac> guillem: But, I'll find some time during weekend. + <youpi> maybe it'd be simpler to add it to the hurd package and use that + from the console-setup package indeed + <youpi> but copyright issues should be solved + <youpi> unless we simply put this into hurdextras + <guillem> ok found this: + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg02456.html + <guillem> and + http://www.mail-archive.com/debian-hurd@lists.debian.org/msg01173.html + <guillem> which seems to be the original Mark's code + <guillem> AFAIR I contributed the the spanish keymap and some additional + key definitions for loadkeys + <guillem> and http://lists.debian.org/debian-hurd/2000/10/msg00130.html + <pavkac> I've fetched all. :) But I must leave, good night if you're in + Europe. :) + <guillem> pavkac: the tarball I provided should be the latest, the others + are mostly to track the provenance of the source diff --git a/open_issues/kvm.mdwn b/open_issues/kvm.mdwn new file mode 100644 index 00000000..6dfffc9a --- /dev/null +++ b/open_issues/kvm.mdwn @@ -0,0 +1,25 @@ +[[!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]]."]]"""]] + +Issues when running Hurd under KVM: un-synced filesystems, etc. No problems +with Virtualbox. + +2010-07-28, #hurd + + <youpi> pochu: you were the one reporting issues with qemu/kvm and hurd, right? + <youpi> is your machine somehow smp (like multicore for instance) + <youpi> ? + <pochu> youpi: yes, it's a Core 2 Duo + <pochu> so 2 cores + <youpi> ok, you might want to try to bind qemu/kvm + <youpi> e.g. install hwloc, and prepend "hwloc-bind 1 --" before the qemu/kvm command line + <pochu> ok, ty + +2010-07-31, GNU Mach commit 039176372b4271f370ef38eb2ee5d43923a5b28b. diff --git a/open_issues/largefile.mdwn b/open_issues/largefile.mdwn new file mode 100644 index 00000000..a6f76a0e --- /dev/null +++ b/open_issues/largefile.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 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, 2012-04-26 + + <pinotree> i kind of understood why (at least in some parts) largefile doesn't seem to work properly + <pinotree> libdiskfs/io-seek.c, SEEK_SET case: cred->po->filepointer = offset; + <pinotree> offset is off_t, which becomes off64_t when compiled with largefile, but filepointer seems to be... int + <pinotree> at least in libdiskfs/diskfs.h, while in libnetfs/netfs.h seems ok (loff_t) + <pinotree> diskfs.h is a public header though :/ + <youpi> well, we can change the soname to mark ABI change diff --git a/open_issues/latrace.mdwn b/open_issues/latrace.mdwn new file mode 100644 index 00000000..b5a2928c --- /dev/null +++ b/open_issues/latrace.mdwn @@ -0,0 +1,11 @@ +[[!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]]."]]"""]] + +Check whether <http://people.redhat.com/jolsa/latrace/> works. diff --git a/open_issues/lexical_dot-dot.mdwn b/open_issues/lexical_dot-dot.mdwn new file mode 100644 index 00000000..3299dfa0 --- /dev/null +++ b/open_issues/lexical_dot-dot.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]]."]]"""]] + +[[!meta title="Lexical .. Resolution"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +There is a [[!FF_project 279]][[!tag bounty]] on this task. + + +# Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/lexical_dot-dot feeds=no]] diff --git a/open_issues/libc_variant_selection.mdwn b/open_issues/libc_variant_selection.mdwn new file mode 100644 index 00000000..afcd9ae0 --- /dev/null +++ b/open_issues/libc_variant_selection.mdwn @@ -0,0 +1,34 @@ +[[!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 +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_porting]] + +There is a [[!FF_project 274]][[!tag bounty]] on this task. + +There are now specialized variants of Debian's libc package, libc0.3-i686 and +libc0.3-xen. + + +On Thu, Oct 07, 2010 at 11:22:46AM +0200, Samuel Thibault wrote: +> Thomas Schwinge, le Thu 07 Oct 2010 10:11:07 +0200, a écrit : +> > Also, this text says ``will be selected instead when running under Xen'' +> > -- is this meant to be automatically done? +> +> It's supposed to be, we need to add support for it. +> +> > If so, then it didn't work. +> +> Yes, you need to copy it by hand. Same for libc0.3-i686, we just need to +> steal the cpuid code from the kfreebsd port of glibc. + +--- + +Having working CPUID code inside [[glibc]] is also a prerequisite for proper +[[IFUNC]] support. diff --git a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn new file mode 100644 index 00000000..1e4a6acb --- /dev/null +++ b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn @@ -0,0 +1,20 @@ +[[!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. + + <tschwinge> By the way: your libdiskfs ., .. fix -- is that relevant for libnetfs as well? (Didn't look it up so far.) + <youpi> it could be a good idea to protect netfs users directly from there yes + <tschwinge> But probably the backend (e.g., NFS server) would protect us in the netfs case, right? + <youpi> possibly, but we could have locking issues in between like in libdiskfs + <youpi> and POSIX says it's invalid anyway + <youpi> so we'd probably better just forbid it 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/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn new file mode 100644 index 00000000..57eb403d --- /dev/null +++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn @@ -0,0 +1,115 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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_hurd]] + +[[!toc]] + + +# bug-hurd discussion. + + +# IRC, freenode, #hurd, 2010-08-12 + + <jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all" + target do something, and shouldn't pretty much everything depend on them? + As it stands it seems that the system headers are used and the + potentially newer ones never get built, except maybe on "install" (which + is seemingly never called from the top-level Makefile) + <jkoenig> I would fix it, but something tells me that maybe it's a feature + :-) + <antrik> jkoenig: the headers are provided by glibc, along with the stubs + <jkoenig> antrik, you mean, even those built from the .defs files in hurd/ + ? + <antrik> yes + <jkoenig> oh, ok then. + <antrik> as glibc provides the stubs (in libhurduser), the headers also + have to come from there, or they would get out of sync + <jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids, + then? + <antrik> jkoenig: not necessarily. the msgids describe what the servers + actually understand. if the stubs are missing from libhurduser, that's no + reason to leave out the msgids... + <jkoenig> ok this makes sense + + +# IRC, OFTC, #debian-hurd, 2011-09-29 + + <tschwinge> pinotree: I don't like their existence. IMO (but I haven't + researched this in very much detail), every user of RPC stubs should + generated them for themselves (and glibc should directly include the + stubs it uses internally). + <pinotree> sounds fair + <pinotree> maybe they could be moved from glibc to hurd? + <tschwinge> pinotree: Yeah; someone needs to research why we have them (or + if it's only convenience), and whether we want to keep them. + <pinotree> you could move them to hurd, leaving them unaltered, so binary + compatibility with eventual 3rd party users is not broken + <pinotree> but those using them, other than hurd itself, won't compile + anymore, so you fix them progressively + + +# IRC, freenode, #hurd, 2011-11-16 + + <braunr> is the mach_debug interface packaged in debian ? + <antrik> what mach_debug interface? + <braunr> include/include/mach_debug/mach_debug.defs in gnumach + <braunr> include/mach_debug/mach_debug.defs in gnumach + <antrik> what exactly is supposed to be packaged there? + <braunr> i'm talking about the host_*_info client code + <antrik> braunr: you mean MIG-generated stubs? + <braunr> antrik: yes + <braunr> i wrote a tiny slabinfo tool, and rpctrace doesn't show the + host_slab_info call + <braunr> do you happen to know why ? + <antrik> braunr: doesn't show it at all, or just doesn't translate? + <braunr> antrik: doesn't at all, the msgids file contains what's needed to + translate + <braunr> btw, i was able to build the libc0.3 packages with a kernel using + the slab allocator today, while monitoring it with the aforementioned + slabinfo tool, everything went smoothly + <antrik> great :-) + <braunr> i'll probably add a /proc/slabinfo entry some day + <braunr> and considering the current state of our beloved kernel, i'm + wondering why host_*_info rpcs are considered debugging calls + <braunr> imo, they should always be included by default + <braunr> and part of the standard mach interface + <braunr> (if the rpc is missing, an error is simply returned) + <antrik> I guess that's been inherited from original Mach + <antrik> so you think the stubs should be provided by libmachuser? + <braunr> i'm not sure + <antrik> actually, it's a bit arguable. if interfaces are not needed by + libc itself, it isn't really necessary to build them as part of the libc + build... + <braunr> i don't know the complete list of potential places for such calls + <antrik> OTOH, as any updates will happen in sync with other Mach updates, + it makes sense to keep them in one place, to reduce transition pain + <braunr> and i didn't want to imply they should be part of libc + <braunr> on the contrary, libmachuser seems right + <antrik> libmachuser is part of libc + <braunr> ah + <braunr> :) + <braunr> why so ? + <antrik> well, for one, libc needs the Mach (and Hurd) stubs itself + <antrik> also, it's traditionally the role of libc to provide the call + wrappers for syscalls... so it makes some sense + <braunr> sure, but why doesn't it depend on an external libmachuser instead + of embedding it ? + <braunr> right + <antrik> now that's a good question... no idea TBH :-) + + +# IRC, freenode, #hurd, 2012-07-23 + + <pinotree> aren't libmachuser and libhurduser supposed to be slowly faded + out? + <tschwinge> pinotree: That discussion has not yet come to a conclusion, I + think. (I'd say: yes.) diff --git a/open_issues/libnetfs_io_map.mdwn b/open_issues/libnetfs_io_map.mdwn new file mode 100644 index 00000000..dc6da202 --- /dev/null +++ b/open_issues/libnetfs_io_map.mdwn @@ -0,0 +1,42 @@ +[[!meta copyright="Copyright © 2012 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="libnetfs: io_map"]] + +[[!tag open_issue_hurd]] + +This hampers [[hurd/translator/nfs]] usability, for example: + + $ fsysopts ./ + /hurd/nfs [...] + $ cp -a /bin/true ./ + cp: failed to preserve authorship for `./true': Operation not supported + $ ./true + $ /lib/ld.so /bin/true + $ /lib/ld.so $PWD/true + [...]/true: error while loading shared libraries: [...]/true: failed to map segment from shared object: Error 1073741869 + +IRC, freenode, #hurd, 2012-03-14: + + <civodul> i just realized that ld.so uses mmap unconditionally + <civodul> so executables or shared libs can't be used off a netfs-based + file system + <civodul> that's annoying + <tschwinge> civodul: Do you know what it takes to fix libnetfs? I have no + idea. + <tschwinge> Never looked at it. + <civodul> tschwinge: implementing io_map + <civodul> but i think the idea is that io_map typically isn't convenient + for network file systems + <civodul> which is why it doesn't have it + <civodul> the GCS says "thou shall not require mmap" ;-) + +<http://lists.gnu.org/archive/html/bug-hurd/2001-10/msg00306.html>. Analysis +to be found on [[glibc/mmap]] page. diff --git a/open_issues/libnfs.mdwn b/open_issues/libnfs.mdwn new file mode 100644 index 00000000..8cadefa4 --- /dev/null +++ b/open_issues/libnfs.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2012 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, 2012-01-09: + + <pinotree> https://github.com/sahlberg/libnfs ← maybe it could be used for + nfs support, instead of the rpc stuff "removed" in newer glibc versions + <antrik> pinotree: sounds like it could do much more than just the RPC + stuff -- definitely interesting :-) + <pinotree> hm but it seems to be an abstraction over either classic rpc or + tirpc + <pinotree> (anyway, it is packaged already in debian) + <antrik> good licensing too + <antrik> I guess I'll modify the GSoC task to "rework the Hurd NFS client + to use libnfs" :-) + <pinotree> the nfs translator? + <antrik> yes + +[[hurd/translator/nfs]] diff --git a/open_issues/libpager_deadlock.mdwn b/open_issues/libpager_deadlock.mdwn new file mode 100644 index 00000000..017ecff6 --- /dev/null +++ b/open_issues/libpager_deadlock.mdwn @@ -0,0 +1,165 @@ +[[!meta copyright="Copyright © 2010, 2012 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]] + +Deadlocks in libpager/periodic sync have been found. + + +# [[gnumach_page_cache_policy]] + + +## IRC, freenode, #hurd, 2012-07-12 + + <braunr> ah great, a paper about the mach pageout daemon ! + <mcsim> braunr: Where is paper about the mach pageout daemon? + <braunr> ftp://ftp.cs.cmu.edu/project/mach/doc/published/defaultmm.ps + <braunr> might give us a clue about the swap deadlock (although i still + have a few ideas to check) + <braunr> + http://www.sceen.net/~rbraun/moving_the_default_memory_manager_out_of_the_mach_kernel.pdf + <braunr> we should more seriously consider sergio's advisory pageout branch + some day + <braunr> i'll try to get in touch with him about that before he completely + looses interest + <braunr> i'll include it in my "make that page cache as decent as possible" + task + <braunr> many of his comments match what i've seen + <braunr> and we both did a few optimizations the same way + <braunr> (like not deactivating pages when they enter the cache) + + +## IRC, freenode, #hurd, 2012-07-13 + + <braunr> antrik: i'm able to consistently reproduce the swap deadlocks you + regularly had when using apt with my page cache patch + <braunr> it happens when lots of dirty pages are write back to their pagers + <braunr> so apt, or a big file copy or anything that writes several MiB + very quickly is a good candidate + <braunr> written* + <antrik> braunr: nice... + <braunr> antrik: well in a way, yes, as it will allow us to track it more + easily + + +## IRC, freenode, #hurd, 2012-07-15 + + <braunr> oh btw, i think i can say with confidence that the hurd *doesn't* + deadlock + <braunr> (at least, concerning swapping) + <braunr> lol, one of my hurd systems has been hitting the "swap deadlock" + for more than an hour, and suddenly got out of it + <braunr> something is really wrong in the pageout daemon, but it's not a + deadlock + <youpi> a livelock then + <braunr> do you get out of livelocks ? + <braunr> i mean, it's not even a "lock" + <braunr> just a big damn tricky slowdown + <youpi> yes, you can, by giving a few more resources for instance + <youpi> depends on the kind of livelock of course + <braunr> i think it's that + <braunr> the pageout daemon clearly throttles itself, waiting for pagers to + complete + <braunr> and another dangerous thing is the line in vm_resident, which only + wakes on thread to avoid starvation + <braunr> hum, during the livelock, the kernel spends much time waiting in + db_read_address + <braunr> could be a bad stack + <braunr> so, the pageout daemon seems to slow itself as much as waiting + several seconds between each iteration when under load + <braunr> but each iteration possibly removes clean pages + <braunr> so at some point, there is enough memory to unblock waiting pagers + <braunr> for now i'll try a simple solution, like limiting the pausing + delay + <braunr> but we'll need more page lists in the future (inactive-clean, + inactive-dirty, etc..) + <braunr> limiting the amount of dirty pages is the only way to really make + it safe actually + <braunr> wow, the pageout loop is still running even after many pages were + freed, and it unable to free more pages + <braunr> i think i have an idea about the livelock + <braunr> i think it comes from the periodic syncing + <bddebian> Too often? + <braunr> that's not the problem + <braunr> the problem is that it can happen at the same time with paging + <bddebian> Oh + <braunr> if paging gets slow, it won't stop the periodic syncing + <braunr> which will grab any page it can as soon as some are free + <braunr> but then, before it even finishes, another sync may occur + <braunr> i have yet to check that it is possible + <braunr> and i don't understand why syncing isn't done by the kernel + <braunr> the kernel is supposed to handle the paging policy + <braunr> and it would make paging really scale + <bddebian> It's done on the Hurd side? + <braunr> (instead of having external pagers make one request for each + object, even if they're clean) + <braunr> yes + <bddebian> Hmm, interesting + <braunr> ofc, with ext2fs --debug, i can't reproduce anything + <bddebian> Ugh + <braunr> sync are serialized + <braunr> grmbl + <braunr> there is a big lock taken at sync time though + <braunr> uhg + + +## IRC, freenode, #hurd, 2012-07-16 + + <braunr> all right so, there *is* a deadlock, and it may be due to the + default pager actually + <braunr> the vm_page_laundry_count doesn't decrease at some point, even + when there are more than enough free pages + <braunr> antrik: the thing is, i think the deadlock concerns the default + pager + <antrik> the deadlock? + <braunr> yes + <braunr> when swapping + + +## IRC, freenode, #hurd, 2012-07-17 + + <braunr> i can't even reproduce the swap deadlock when using upstrea ext2fs + :( + <braunr> upstream* + + +## IRC, freenode, #hurd, 2012-07-19 + + <braunr> the libpager deadlock patch looks wrong to me + <braunr> hm no, the libpager patch is ok acually + + +## [[synchronous_ipc]] + +### IRC, freenode, #hurd, 2012-07-20 + + <braunr> but actually after reviewing more, the debian patch for this + particular issue seems correct + <antrik> well, it's most probably done by youpi, so I would be shocked if + it wasn't correct... ;-) + <braunr> he wasn't sure at all about it + <antrik> still ;-) + <braunr> :) + <antrik> well, if you also think it's correct, I guess it's time to push it + upstream... + + +## IRC, freenode, #hurd, 2012-07-23 + + <braunr> i still can't conclude if we have any pageout deadlock, or if it's + simply a side effect of the active and inactive lists getting very very + large + <braunr> but almost every time this issue happens, it somehow recovers, + sometimes hours later + + +# See Also + + * [[ext2fs_deadlock]] diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn new file mode 100644 index 00000000..befc1378 --- /dev/null +++ b/open_issues/libpthread.mdwn @@ -0,0 +1,1328 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]] + +[[!toc]] + + +# cthreads -> pthreads + +Get rid of cthreads; switch to pthreads. + +There is a [[!FF_project 275]][[!tag bounty]] on this task. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]] + + +## IRC, freenode, #hurd, 2012-04-26 + + <pinotree> youpi: just to be sure: even if libpthread is compiled inside + glibc (with proper symbols forwarding etc), it doesn't change that you + cannot use both cthreads and pthreads in the same app, right? + +[[Packaging_libpthread]]. + + <youpi> it's the same libpthread + <youpi> symbol forwarding does not magically resolve that libpthread lacks + some libthread features :) + <pinotree> i know, i was referring about the clash between actively using + both + <youpi> there'll still be the issue that only one will be initialized + <youpi> and one that provides libc thread safety functions, etc. + <pinotree> that's what i wanted to knew, thanks :) + + +## IRC, freenode, #hurd, 2012-07-23 + + <bddebian> So I am not sure what to do with the hurd_condition_wait stuff + <braunr> i would also like to know what's the real issue with cancellation + here + <braunr> because my understanding is that libpthread already implements it + <braunr> does it look ok to you to make hurd_condition_timedwait return an + errno code (like ETIMEDOUT and ECANCELED) ? + <youpi> braunr: that's what pthread_* function usually do, yes + <braunr> i thought they used their own code + <youpi> no + <braunr> thanks + <braunr> well, first, do you understand what hurd_condition_wait is ? + <braunr> it's similar to condition_wait or pthread_cond_wait with a subtle + difference + <braunr> it differs from the original cthreads version by handling + cancellation + <braunr> but it also differs from the second by how it handles cancellation + <braunr> instead of calling registered cleanup routines and leaving, it + returns an error code + <braunr> (well simply !0 in this case) + <braunr> so there are two ways + <braunr> first, change the call to pthread_cond_wait + <bddebian> Are you saying we could fix stuff to use pthread_cond_wait() + properly? + <braunr> it's possible but not easy + <braunr> because you'd have to rewrite the cancellation code + <braunr> probably writing cleanup routines + <braunr> this can be hard and error prone + <braunr> and is useless if the code already exists + <braunr> so it seems reasonable to keep this hurd extension + <braunr> but now, as it *is* a hurd extension noone else uses + <antrik> braunr: BTW, when trying to figure out a tricky problem with the + auth server, cfhammer digged into the RPC cancellation code quite a bit, + and it's really a horrible complex monstrosity... plus the whole concept + is actually broken in some regards I think -- though I don't remember the + details + <braunr> antrik: i had the same kind of thoughts + <braunr> antrik: the hurd or pthreads ones ? + <antrik> not sure what you mean. I mean the RPC cancellation code -- which + is involves thread management too + <braunr> ok + <antrik> I don't know how it is related to hurd_condition_wait though + <braunr> well i found two main entry points there + <braunr> hurd_thread_cancel and hurd_condition_wait + <braunr> and it didn't look that bad + <braunr> whereas in the pthreads code, there are many corner cases + <braunr> and even the standard itself looks insane + <antrik> well, perhaps the threading part is not that bad... + <antrik> it's not where we saw the problems at any rate :-) + <braunr> rpc interruption maybe ? + <antrik> oh, right... interruption is probably the right term + <braunr> yes that thing looks scary + <braunr> :)) + <braunr> the migration thread paper mentions some things about the problems + concerning threads controllability + <antrik> I believe it's a very strong example for why building around + standard Mach features is a bad idea, instead of adapting the primitives + to our actual needs... + <braunr> i wouldn't be surprised if the "monstrosities" are work arounds + <braunr> right + + +## IRC, freenode, #hurd, 2012-07-26 + + <bddebian> Uhm, where does /usr/include/hurd/signal.h come from? + <pinotree> head -n4 /usr/include/hurd/signal. + <pinotree> h + <bddebian> Ohh glibc? + <bddebian> That makes things a little more difficult :( + <braunr> why ? + <bddebian> Hurd includes it which brings in cthreads + <braunr> ? + <braunr> the hurd already brings in cthreads + <braunr> i don't see what you mean + <bddebian> Not anymore :) + <braunr> the system cthreads header ? + <braunr> well it's not that difficult to trick the compiler not to include + them + <bddebian> signal.h includes cthreads.h I need to stop that + <braunr> just define the _CTHREADS_ macro before including anything + <braunr> remember that header files are normally enclosed in such macros to + avoid multiple inclusions + <braunr> this isn't specific to cthreads + <pinotree> converting hurd from cthreads to pthreads will make hurd and + glibc break source and binary compatibility + <bddebian> Of course + <braunr> reminds me of the similar issues of the late 90s + <bddebian> Ugh, why is he using _pthread_self()? + <pinotree> maybe because it accesses to the internals + <braunr> "he" ? + <bddebian> Thomas in his modified cancel-cond.c + <braunr> well, you need the internals to implement it + <braunr> hurd_condition_wait is similar to pthread_condition_wait, except + that instead of stopping the thread and calling cleanup routines, it + returns 1 if cancelled + <pinotree> not that i looked at it, but there's really no way to implement + it using public api? + <bddebian> Even if I am using glibc pthreads? + <braunr> unlikely + <bddebian> God I had all of this worked out before I dropped off for a + couple years.. :( + <braunr> this will come back :p + <pinotree> that makes you the perfect guy to work on it ;) + <bddebian> I can't find a pt-internal.h anywhere.. :( + <pinotree> clone the hurd/libpthread.git repo from savannah + <bddebian> Of course when I was doing this libpthread was still in hurd + sources... + <bddebian> So if I am using glibc pthread, why can't I use pthread_self() + instead? + <pinotree> that won't give you access to the internals + <bddebian> OK, dumb question time. What internals? + <pinotree> the libpthread ones + <braunr> that's where you will find if your thread has been cancelled or + not + <bddebian> pinotree: But isn't that assuming that I am using hurd's + libpthread? + <pinotree> if you aren't inside libpthread, no + <braunr> pthread_self is normally not portable + <braunr> you can only use it with pthread_equal + <braunr> so unless you *know* the internals, you can't use it + <braunr> and you won't be able to do much + <braunr> so, as it was done with cthreads, hurd_condition_wait should be + close to the libpthread implementation + <braunr> inside, normally + <braunr> now, if it's too long for you (i assume you don't want to build + glibc) + <braunr> you can just implement it outside, grabbing the internal headers + for now + <pinotree> another "not that i looked at it" question: isn't there no way + to rewrite the code using that custom condwait stuff to use the standard + libpthread one? + <braunr> and once it works, it'll get integrated + <braunr> pinotree: it looks very hard + <bddebian> braunr: But the internal headers are assuming hurd libpthread + which isn't in the source anymore + <braunr> from what i could see while working on select, servers very often + call hurd_condition_wait + <braunr> and they return EINTR if canceleld + <braunr> so if you use the standard pthread_cond_wait function, your thread + won't be able to return anything, unless you push the reply in a + completely separate callback + <braunr> i'm not sure how well mig can cope with that + <braunr> i'd say it can't :) + <braunr> no really it looks ugly + <braunr> it's far better to have this hurd specific function and keep the + existing user code as it is + <braunr> bddebian: you don't need the implementation, only the headers + <braunr> the thread, cond, mutex structures mostly + <bddebian> I should turn <pt-internal.h> to "pt-internal.h" and just put it + in libshouldbelibc, no? + <pinotree> no, that header is not installed + <bddebian> Obviously not the "best" way + <bddebian> pinotree: ?? + <braunr> pinotree: what does it change ? + <pinotree> braunr: it == ? + <braunr> bddebian: you could even copy it entirely in your new + cancel-cond.C and mention where it was copied from + <braunr> pinotree: it == pt-internal.H not being installed + <pinotree> that he cannot include it in libshouldbelibc sources? + <pinotree> ah, he wants to copy it? + <braunr> yes + <braunr> i want him to copy it actually :p + <braunr> it may be hard if there are a lot of macro options + <pinotree> the __pthread struct changes size and content depending on other + internal sysdeps headers + <braunr> well he needs to copy those too :p + <bddebian> Well even if this works we are going to have to do something + more "correct" about hurd_condition_wait. Maybe even putting it in + glibc? + <braunr> sure + <braunr> but again, don't waste time on this for now + <braunr> make it *work*, then it'll get integrated + <bddebian> Like it has already? This "patch" is only about 5 years old + now... ;-P + <braunr> but is it complete ? + <bddebian> Probably not :) + <bddebian> Hmm, I wonder how many undefined references I am going to get + though.. :( + <bddebian> Shit, 5 + <bddebian> One of which is ___pthread_self.. :( + <bddebian> Does that mean I am actually going to have to build hurds + libpthreads in libshouldbeinlibc? + <bddebian> Seriously, do I really need ___pthread_self, __pthread_self, + _pthread_self and pthread_self??? + <bddebian> I'm still unclear what to do with cancel-cond.c. It seems to me + that if I leave it the way it is currently I am going to have to either + re-add libpthreads or still all of the libpthreads code under + libshouldbeinlibc. + <braunr> then add it in libc + <braunr> glib + <braunr> glibc + <braunr> maybe under the name __hurd_condition_wait + <bddebian> Shouldn't I be able to interrupt cancel-cond stuff to use glibc + pthreads? + <braunr> interrupt ? + <bddebian> Meaning interject like they are doing. I may be missing the + point but they are just obfuscating libpthreads thread with some other + "namespace"? (I know my terminology is wrong, sorry). + <braunr> they ? + <bddebian> Well Thomas in this case but even in the old cthreads code, + whoever wrote cancel-cond.c + <braunr> but they use internal thread structures .. + <bddebian> Understood but at some level they are still just getting to a + libpthread thread, no? + <braunr> absolutely not .. + <braunr> there is *no* pthread stuff in the hurd + <braunr> that's the problem :p + <bddebian> Bah damnit... + <braunr> cthreads are directly implement on top of mach threads + <braunr> implemeneted* + <braunr> implemented* + <bddebian> Sure but hurd_condition_wait wasn't + <braunr> of course it is + <braunr> it's almost the same as condition_wait + <braunr> but returns 1 if a cancelation request was made + <bddebian> Grr, maybe I am just confusing myself because I am looking at + the modified (pthreads) version instead of the original cthreads version + of cancel-cond.c + <braunr> well if the modified version is fine, why not directly use that ? + <braunr> normally, hurd_condition_wait should sit next to other pthread + internal stuff + <braunr> it could be renamed __hurd_condition_wait, i'm not sure + <braunr> that's irrelevant for your work anyway + <bddebian> I am using it but it relies on libpthread and I am trying to use + glibc pthreads + <braunr> hum + <braunr> what's the difference between libpthread and "glibc pthreads" ? + <braunr> aren't glibc pthreads the merged libpthread ? + <bddebian> quite possibly but then I am missing something obvious. I'm + getting ___pthread_self in libshouldbeinlibc but it is *UND* + <braunr> bddebian: with unmodified binaries ? + <bddebian> braunr: No I added cancel-cond.c to libshouldbeinlibc + <bddebian> And some of the pt-xxx.h headers + <braunr> well it's normal then + <braunr> i suppose + <bddebian> braunr: So how do I get those defined without including + pthreads.c from libpthreads? :) + <antrik> pinotree: hm... I think we should try to make sure glibc works + both whith cthreads hurd and pthreads hurd. I hope that shoudn't be so + hard. + <antrik> breaking binary compatibility for the Hurd libs is not too + terrible I'd say -- as much as I'd like that, we do not exactly have a + lot of external stuff depending on them :-) + <braunr> bddebian: *sigh* + <braunr> bddebian: just add cancel-cond to glibc, near the pthread code :p + <bddebian> braunr: Wouldn't I still have the same issue? + <braunr> bddebian: what issue ? + <antrik> is hurd_condition_wait() the name of the original cthreads-based + function? + <braunr> antrik: the original is condition_wait + <antrik> I'm confused + <antrik> is condition_wait() a standard cthreads function, or a + Hurd-specific extension? + <braunr> antrik: as standard as you can get for something like cthreads + <bddebian> braunr: Where hurd_condition_wait is looking for "internals" as + you call them. I.E. there is no __pthread_self() in glibc pthreads :) + <braunr> hurd_condition_wait is the hurd-specific addition for cancelation + <braunr> bddebian: who cares ? + <braunr> bddebian: there is a pthread structure, and conditions, and + mutexes + <braunr> you need those definitions + <braunr> so you either import them in the hurd + <antrik> braunr: so hurd_condition_wait() *is* also used in the original + cthread-based implementation? + <braunr> or you write your code directly where they're available + <braunr> antrik: what do you call "original" ? + <antrik> not transitioned to pthreads + <braunr> ok, let's simply call that cthreads + <braunr> yes, it's used by every hurd servers + <braunr> virtually + <braunr> if not really everyone of them + <bddebian> braunr: That is where you are losing me. If I can just use + glibc pthreads structures, why can't I just use them in the new pthreads + version of cancel-cond.c which is what I was originally asking.. :) + <braunr> you *have* to do that + <braunr> but then, you have to build the whole glibc + * bddebian shoots himself + <braunr> and i was under the impression you wanted to avoid that + <antrik> do any standard pthread functions use identical names to any + standard cthread functions? + <braunr> what you *can't* do is use the standard pthreads interface + <braunr> no, not identical + <braunr> but very close + <braunr> bddebian: there is a difference between using pthreads, which + means using the standard posix interface, and using the glibc pthreads + structure, which means toying with the internale implementation + <braunr> you *cannot* implement hurd_condition_wait with the standard posix + interface, you need to use the internal structures + <braunr> hurd_condition_wait is actually a shurd specific addition to the + threading library + <braunr> hurd* + <antrik> well, in that case, the new pthread-based variant of + hurd_condition_wait() should also use a different name from the + cthread-based one + <braunr> so it's normal to put it in that threading library, like it was + done for cthreads + <braunr> 21:35 < braunr> it could be renamed __hurd_condition_wait, i'm not + sure + <bddebian> Except that I am trying to avoid using that threading library + <braunr> what ? + <bddebian> If I am understanding you correctly it is an extention to the + hurd specific libpthreads? + <braunr> to the threading library, whichever it is + <braunr> antrik: although, why not keeping the same name ? + <antrik> braunr: I don't think having hurd_condition_wait() for the cthread + variant and __hurd_condition_wait() would exactly help clarity... + <antrik> I was talking about a really new name. something like + pthread_hurd_condition_wait() or so + <antrik> braunr: to avoid confusion. to avoid accidentally pulling in the + wrong one at build and/or runtime. + <antrik> to avoid possible namespace conflicts + <braunr> ok + <braunr> well yes, makes sense + <bddebian> braunr: Let me state this as plainly as I hope I can. If I want + to use glibc's pthreads, I have no choice but to add it to glibc? + <braunr> and pthread_hurd_condition_wait is a fine name + <braunr> bddebian: no + <braunr> bddebian: you either add it there + <braunr> bddebian: or you copy the headers defining the internal structures + somewhere else and implement it there + <braunr> but adding it to glibc is better + <braunr> it's just longer in the beginning, and now i'm working on it, i'm + really not sure + <braunr> add it to glibc directly :p + <bddebian> That's what I am trying to do but the headers use pthread + specific stuff would should be coming from glibc's pthreads + <braunr> yes + <braunr> well it's not the headers you need + <braunr> you need the internal structure definitions + <braunr> sometimes they're in c files for opacity + <bddebian> So ___pthread_self() should eventually be an obfuscation of + glibcs pthread_self(), no? + <braunr> i don't know what it is + <braunr> read the cthreads variant of hurd_condition_wait, understand it, + do the same for pthreads + <braunr> it's easy :p + <bddebian> For you bastards that have a clue!! ;-P + <antrik> I definitely vote for adding it to the hurd pthreads + implementation in glibc right away. trying to do it externally only adds + unnecessary complications + <antrik> and we seem to agree that this new pthread function should be + named pthread_hurd_condition_wait(), not just hurd_condition_wait() :-) + + +## IRC, freenode, #hurd, 2012-07-27 + + <bddebian> OK this hurd_condition_wait stuff is getting ridiculous the way + I am trying to tackle it. :( I think I need a new tactic. + <braunr> bddebian: what do you mean ? + <bddebian> braunr: I know I am thick headed but I still don't get why I + cannot implement it in libshouldbeinlibc for now but still use glibc + pthreads internals + <bddebian> I thought I was getting close last night by bringing in all of + the hurd pthread headers and .c files but it just keeps getting uglier + and uglier + <bddebian> youpi: Just to verify. The /usr/lib/i386-gnu/libpthread.so that + ships with Debian now is from glibc, NOT libpthreads from Hurd right? + Everything I need should be available in glibc's libpthreads? (Except for + hurd_condition_wait obviously). + <braunr> 22:35 < antrik> I definitely vote for adding it to the hurd + pthreads implementation in glibc right away. trying to do it externally + only adds unnecessary complications + <youpi> bddebian: yes + <youpi> same as antrik + <bddebian> fuck + <youpi> libpthread *already* provides some odd symbols (cthread + compatibility), it can provide others + <braunr> bddebian: don't curse :p it will be easier in the long run + * bddebian breaks out glibc :( + <braunr> but you should tell thomas that too + <bddebian> braunr: I know it just adds a level of complexity that I may not + be able to deal with + <braunr> we wouldn't want him to waste too much time on the external + libpthread + <braunr> which one ? + <bddebian> glibc for one. hurd_condition_wait() for another which I don't + have a great grasp on. Remember my knowledge/skillsets are limited + currently. + <braunr> bddebian: tschwinge has good instructions to build glibc + <braunr> keep your tree around and it shouldn't be long to hack on it + <braunr> for hurd_condition_wait, i can help + <bddebian> Oh I was thinking about using Debian glibc for now. You think I + should do it from git? + <braunr> no + <braunr> debian rules are even more reliable + <braunr> (just don't build all the variants) + <pinotree> `debian/rules build_libc` builds the plain i386 variant only + <bddebian> So put pthread_hurd_cond_wait in it's own .c file or just put it + in pt-cond-wait.c ? + <braunr> i'd put it in pt-cond-wait.C + <bddebian> youpi or braunr: OK, another dumb question. What (if anything) + should I do about hurd/hurd/signal.h. Should I stop it from including + cthreads? + <youpi> it's not a dumb question. it should probably stop, yes, but there + might be uncovered issues, which we'll have to take care of + <bddebian> Well I know antrik suggested trying to keep compatibility but I + don't see how you would do that + <braunr> compability between what ? + <braunr> and source and/or binary ? + <youpi> hurd/signal.h implicitly including cthreads.h + <braunr> ah + <braunr> well yes, it has to change obviously + <bddebian> Which will break all the cthreads stuff of course + <bddebian> So are we agreeing on pthread_hurd_cond_wait()? + <braunr> that's fine + <bddebian> Ugh, shit there is stuff in glibc using cthreads?? + <braunr> like what ? + <bddebian> hurdsig, hurdsock, setauth, dtable, ... + <youpi> it's just using the compatibility stuff, that pthread does provide + <bddebian> but it includes cthreads.h implicitly + <bddebian> s/it/they in many cases + <youpi> not a problem, we provide the functions + <bddebian> Hmm, then what do I do about signal.h? It includes chtreads.h + because it uses extern struct mutex ... + <youpi> ah, then keep the include + <youpi> the pthread mutexes are compatible with that + <youpi> we'll clean that afterwards + <bddebian> arf, OK + <youpi> that's what I meant by "uncover issues" + + +## IRC, freenode, #hurd, 2012-07-28 + + <bddebian> Well crap, glibc built but I have no symbol for + pthread_hurd_cond_wait in libpthread.so :( + <bddebian> Hmm, I wonder if I have to add pthread_hurd_cond_wait to + forward.c and Versions? (Versions obviously eventually) + <pinotree> bddebian: most probably not about forward.c, but definitely you + have to export public stuff using Versions + + +## IRC, freenode, #hurd, 2012-07-29 + + <bddebian> braunr: http://paste.debian.net/181078/ + <braunr> ugh, inline functions :/ + <braunr> "Tell hurd_thread_cancel how to unblock us" + <braunr> i think you need that one too :p + <bddebian> ?? + <braunr> well, they work in pair + <braunr> one cancels, the other notices it + <braunr> hurd_thread_cancel is in the hurd though, iirc + <braunr> or uh wait + <braunr> no it's in glibc, hurd/thread-cancel.c + <braunr> otherwise it looks like a correct reuse of the original code, but + i need to understand the pthreads internals better to really say anything + + +## IRC, freenode, #hurd, 2012-08-03 + + <braunr> pinotree: what do you think of + condition_implies/condition_unimplies ? + <braunr> the work on pthread will have to replace those + + +## IRC, freenode, #hurd, 2012-08-06 + + <braunr> bddebian: so, where is the work being done ? + <bddebian> braunr: Right now I would just like to testing getting my glibc + with pthread_hurd_cond_wait installed on the clubber subhurd. It is in + /home/bdefreese/glibc-debian2 + <braunr> we need a git branch + <bddebian> braunr: Then I want to rebuild hurd with Thomas's pthread + patches against that new libc + <bddebian> Aye + <braunr> i don't remember, did thomas set a git repository somewhere for + that ? + <bddebian> He has one but I didn't have much luck with it since he is using + an external libpthreads + <braunr> i can manage the branches + <bddebian> I was actually patching debian/hurd then adding his patches on + top of that. It is in /home/bdefreese/debian-hurd but he has updateds + some stuff since then + <bddebian> Well we need to agree on a strategy. libpthreads only exists in + debian/glibc + <braunr> it would be better to have something upstream than to work on a + debian specific branch :/ + <braunr> tschwinge: do you think it can be done + <braunr> ? + + +## IRC, freenode, #hurd, 2012-08-07 + + <tschwinge> braunr: You mean to create on Savannah branches for the + libpthread conversion? Sure -- that's what I have been suggesting to + Barry and Thomas D. all the time. + + <bddebian> braunr: OK, so I installed my glibc with + pthread_hurd_condition_wait in the subhurd and now I have built Debian + Hurd with Thomas D's pthread patches. + <braunr> bddebian: i'm not sure we're ready for tests yet :p + <bddebian> braunr: Why not? :) + <braunr> bddebian: a few important bits are missing + <bddebian> braunr: Like? + <braunr> like condition_implies + <braunr> i'm not sure they have been handled everywhere + <braunr> it's still interesting to try, but i bet your system won't finish + booting + <bddebian> Well I haven't "installed" the built hurd yet + <bddebian> I was trying to think of a way to test a little bit first, like + maybe ext2fs.static or something + <bddebian> Ohh, it actually mounted the partition + <bddebian> How would I actually "test" it? + <braunr> git clone :p + <braunr> building a debian package inside + <braunr> removing the whole content after + <braunr> that sort of things + <bddebian> Hmm, I think I killed clubber :( + <bddebian> Yep.. Crap! :( + <braunr> ? + <braunr> how did you do that ? + <bddebian> Mounted a new partition with the pthreads ext2fs.static then did + an apt-get source hurd to it.. + <braunr> what partition, and what mount point ? + <bddebian> I added a new 2Gb partition on /dev/hd0s6 and set the translator + on /home/bdefreese/part6 + <braunr> shouldn't kill your hurd + <bddebian> Well it might still be up but killed my ssh session at the very + least :) + <braunr> ouch + <bddebian> braunr: Do you have debugging enabled in that custom kernel you + installed? Apparently it is sitting at the debug prompt. + + +## IRC, freenode, #hurd, 2012-08-12 + + <braunr> hmm, it seems the hurd notion of cancellation is actually not the + pthread one at all + <braunr> pthread_cancel merely marks a thread as being cancelled, while + hurd_thread_cancel interrupts it + <braunr> ok, i have a pthread_hurd_cond_wait_np function in glibc + + +## IRC, freenode, #hurd, 2012-08-13 + + <braunr> nice, i got ext2fs work with pthreads + <braunr> there are issues with the stack size strongly limiting the number + of concurrent threads, but that's easy to fix + <braunr> one problem with the hurd side is the condition implications + <braunr> i think it should be deal separately, and before doing anything + with pthreads + <braunr> but that's minor, the most complex part is, again, the term server + <braunr> other than that, it was pretty easy to do + <braunr> but, i shouldn't speak too soon, who knows what tricky bootstrap + issue i'm gonna face ;p + <braunr> tschwinge: i'd like to know how i should proceed if i want a + symbol in a library overriden by that of a main executable + <braunr> e.g. have libpthread define a default stack size, and let + executables define their own if they want to change it + <braunr> tschwinge: i suppose i should create a weak alias in the library + and a normal variable in the executable, right ? + <braunr> hm i'm making this too complicated + <braunr> don't mind that stupid question + <tschwinge> braunr: A simple variable definition would do, too, I think? + <tschwinge> braunr: Anyway, I'd first like to know why we can'T reduce the + size of libpthread threads from 2 MiB to 64 KiB as libthreads had. Is + that a requirement of the pthread specification? + <braunr> tschwinge: it's a requirement yes + <braunr> the main reason i see is that hurd threadvars (which are still + present) rely on common stack sizes and alignment to work + <tschwinge> Mhm, I see. + <braunr> so for now, i'm using this approach as a hack only + <tschwinge> I'm working on phasing out threadvars, but we're not there yet. + <tschwinge> Yes, that's fine for the moment. + <braunr> tschwinge: a simple definition wouldn't work + <braunr> tschwinge: i resorted to a weak symbol, and see how it goes + <braunr> tschwinge: i supposed i need to export my symbol as a global one, + otherwise making it weak makes no sense, right ? + <braunr> suppose* + <braunr> tschwinge: also, i'm not actually sure what you meant is a + requirement about the stack size, i shouldn't have answered right away + <braunr> no there is actually no requirement + <braunr> i misunderstood your question + <braunr> hm when adding this weak variable, starting a program segfaults :( + <braunr> apparently on ___pthread_self, a tls variable + <braunr> fighting black magic begins + <braunr> arg, i can't manage to use that weak symbol to reduce stack sizes + :( + <braunr> ah yes, finally + <braunr> git clone /path/to/glibc.git on a pthread-powered ext2fs server :> + <braunr> tschwinge: seems i have problems using __thread in hurd code + <braunr> tschwinge: they produce undefined symbols + <braunr> tschwinge: forget that, another mistake on my part + <braunr> so, current state: i just need to create another patch, for the + code that is included in the debian hurd package but not in the upstream + hurd repository (e.g. procfs, netdde), and i should be able to create + hurd packages taht completely use pthreads + + +## IRC, freenode, #hurd, 2012-08-14 + + <braunr> tschwinge: i have weird bootstrap issues, as expected + <braunr> tschwinge: can you point me to important files involved during + bootstrap ? + <braunr> my ext2fs.static server refuses to start as a rootfs, whereas it + seems to work fine otherwise + <braunr> hm, it looks like it's related to global signal dispositions + + +## IRC, freenode, #hurd, 2012-08-15 + + <braunr> ahah, a subhurd running pthreads-powered hurd servers only + <LarstiQ> braunr: \o/ + <braunr> i can even long on ssh + <braunr> log + <braunr> pinotree: for reference, i uploaded my debian-specific changes + there : + <braunr> http://git.sceen.net/rbraun/debian_hurd.git/ + <braunr> darnassus is now running a pthreads-enabled hurd system :) + + +## IRC, freenode, #hurd, 2012-08-16 + + <braunr> my pthreads-enabled hurd systems can quickly die under load + <braunr> youpi: with hurd servers using pthreads, i occasionally see thread + storms apparently due to a deadlock + <braunr> youpi: it makes me think of the problem you sometimes have (and + had often with the page cache patch) + <braunr> in cthreads, mutex and condition operations are macros, and they + check the mutex/condition queue without holding the internal + mutex/condition lock + <braunr> i'm not sure where this can lead to, but it doesn't seem right + <pinotree> isn't that a bit dangerous? + <braunr> i believe it is + <braunr> i mean + <braunr> it looks dangerous + <braunr> but it may be perfectly safe + <pinotree> could it be? + <braunr> aiui, it's an optimization, e.g. "dont take the internal lock if + there are no thread to wake" + <braunr> but if there is a thread enqueuing itself at the same time, it + might not be waken + <pinotree> yeah + <braunr> pthreads don't have this issue + <braunr> and what i see looks like a deadlock + <pinotree> anything can happen between the unlocked checking and the + following instruction + <braunr> so i'm not sure how a situation working around a faulty + implementation would result in a deadlock with a correct one + <braunr> on the other hand, the error youpi reported + (http://lists.gnu.org/archive/html/bug-hurd/2012-07/msg00051.html) seems + to indicate something is deeply wrong with libports + <pinotree> it could also be the current code does not really "works around" + that, but simply implicitly relies on the so-generated behaviour + <braunr> luckily not often + <braunr> maybe + <braunr> i think we have to find and fix these issues before moving to + pthreads entirely + <braunr> (ofc, using pthreads to trigger those bugs is a good procedure) + <pinotree> indeed + <braunr> i wonder if tweaking the error checking mode of pthreads to abort + on EDEADLK is a good approach to detecting this problem + <braunr> let's try ! + <braunr> youpi: eh, i think i've spotted the libports ref mistake + <youpi> ooo! + <youpi> .oOo.!! + <gnu_srs> Same problem but different patches + <braunr> look at libports/bucket-iterate.c + <braunr> in the HURD_IHASH_ITERATE loop, pi->refcnt is incremented without + a lock + <youpi> Mmm, the incrementation itself would probably be compiled into an + INC, which is safe in UP + <youpi> it's an add currently actually + <youpi> 0x00004343 <+163>: addl $0x1,0x4(%edi) + <braunr> 40c4: 83 47 04 01 addl $0x1,0x4(%edi) + <youpi> that makes it SMP unsafe, but not UP unsafe + <braunr> right + <braunr> too bad + <youpi> that still deserves fixing :) + <braunr> the good side is my mind is already wired for smp + <youpi> well, it's actually not UP either + <youpi> in general + <youpi> when the processor is not able to do the add in one instruction + <braunr> sure + <braunr> youpi: looks like i'm wrong, refcnt is protected by the global + libports lock + <youpi> braunr: but aren't there pieces of code which manipulate the refcnt + while taking another lock than the global libports lock + <youpi> it'd not be scalable to use the global libports lock to protect + refcnt + <braunr> youpi: imo, the scalability issues are present because global + locks are taken all the time, indeed + <youpi> urgl + <braunr> yes .. + <braunr> when enabling mutex checks in libpthread, pfinet dies :/ + <braunr> grmbl, when trying to start "ls" using my deadlock-detection + libpthread, the terminal gets unresponsive, and i can't even use ps .. :( + <pinotree> braunr: one could say your deadlock detection works too + good... :P + <braunr> pinotree: no, i made a mistake :p + <braunr> it works now :) + <braunr> well, works is a bit fast + <braunr> i can't attach gdb now :( + <braunr> *sigh* + <braunr> i guess i'd better revert to a cthreads hurd and debug from there + <braunr> eh, with my deadlock-detection changes, recursive mutexes are now + failing on _pthread_self(), which for some obscure reason generates this + <braunr> => 0x0107223b <+283>: jmp 0x107223b + <__pthread_mutex_timedlock_internal+283> + <braunr> *sigh* + + +## IRC, freenode, #hurd, 2012-08-17 + + <braunr> aw, the thread storm i see isn't a deadlock + <braunr> seems to be mere contention .... + <braunr> youpi: what do you think of the way + ports_manage_port_operations_multithread determines it needs to spawn a + new thread ? + <braunr> it grabs a lock protecting the number of threads to determine if + it needs a new thread + <braunr> then releases it, to retake it right after if a new thread must be + created + <braunr> aiui, it could lead to a situation where many threads could + determine they need to create threads + <youpi> braunr: there's no reason to release the spinlock before re-taking + it + <youpi> that can indeed lead to too much thread creations + <braunr> youpi: a harder question + <braunr> youpi: what if thread creation fails ? :/ + <braunr> if i'm right, hurd servers simply never expect thread creation to + fail + <youpi> indeed + <braunr> and as some patterns have threads blocking until another produce + an event + <braunr> i'm not sure there is any point handling the failure at all :/ + <youpi> well, at least produce some output + <braunr> i added a perror + <youpi> so we know that happened + <braunr> async messaging is quite evil actually + <braunr> the bug i sometimes have with pfinet is usually triggered by + fakeroot + <braunr> it seems to use select a lot + <braunr> and select often destroys ports when it has something to return to + the caller + <braunr> which creates dead name notifications + <braunr> and if done often enough, a lot of them + <youpi> uh + <braunr> and as pfinet is creating threads to service new messages, already + existing threads are starved and can't continue + <braunr> which leads to pfinet exhausting its address space with thread + stacks (at about 30k threads) + <braunr> i initially thought it was a deadlock, but my modified libpthread + didn't detect one, and indeed, after i killed fakeroot (the whole + dpkg-buildpackage process hierarchy), pfinet just "cooled down" + <braunr> with almost all 30k threads simply waiting for requests to + service, and the few expected select calls blocking (a few ssh sessions, + exim probably, possibly others) + <braunr> i wonder why this doesn't happen with cthreads + <youpi> there's a 4k guard between stacks, otherwise I don't see anything + obvious + <braunr> i'll test my pthreads package with the fixed + ports_manage_port_operations_multithread + <braunr> but even if this "fix" should reduce thread creation, it doesn't + prevent the starvation i observed + <braunr> evil concurrency :p + + <braunr> youpi: hm i've just spotted an important difference actually + <braunr> youpi: glibc sched_yield is __swtch(), cthreads is + thread_switch(MACH_PORT_NULL, SWITCH_OPTION_DEPRESS, 10) + <braunr> i'll change the glibc implementation, see how it affects the whole + system + + <braunr> youpi: do you think bootsting the priority or cancellation + requests is an acceptable workaround ? + <braunr> boosting + <braunr> of* + <youpi> workaround for what? + <braunr> youpi: the starvation i described earlier + <youpi> well, I guess I'm not into the thing enough to understand + <youpi> you meant the dead port notifications, right? + <braunr> yes + <braunr> they are the cancellation triggers + <youpi> cancelling whaT? + <braunr> a blocking select for example + <braunr> ports_do_mach_notify_dead_name -> ports_dead_name -> + ports_interrupt_notified_rpcs -> hurd_thread_cancel + <braunr> so it's important they are processed quickly, to allow blocking + threads to unblock, reply, and be recycled + <youpi> you mean the threads in pfinet? + <braunr> the issue applies to all servers, but yes + <youpi> k + <youpi> well, it can not not be useful :) + <braunr> whatever the choice, it seems to be there will be a security issue + (a denial of service of some kind) + <youpi> well, it's not only in that case + <youpi> you can always queue a lot of requests to a server + <braunr> sure, i'm just focusing on this particular problem + <braunr> hm + <braunr> max POLICY_TIMESHARE or min POLICY_FIXEDPRI ? + <braunr> i'd say POLICY_TIMESHARE just in case + <braunr> (and i'm not sure mach handles fixed priority threads first + actually :/) + <braunr> hm my current hack which consists of calling swtch_pri(0) from a + freshly created thread seems to do the job eh + <braunr> (it may be what cthreads unintentionally does by acquiring a spin + lock from the entry function) + <braunr> not a single issue any more with this hack + <bddebian> Nice + <braunr> bddebian: well it's a hack :p + <braunr> and the problem is that, in order to boost a thread's priority, + one would need to implement that in libpthread + <bddebian> there isn't thread priority in libpthread? + <braunr> it's not implemented + <bddebian> Interesting + <braunr> if you want to do it, be my guest :p + <braunr> mach should provide the basic stuff for a partial implementation + <braunr> but for now, i'll fall back on the hack, because that's what + cthreads "does", and it's "reliable enough" + + <antrik> braunr: I don't think the locking approach in + ports_manage_port_operations_multithread() could cause issues. the worst + that can happen is that some other thread becomes idle between the check + and creating a new thread -- and I can't think of a situation where this + could have any impact... + <braunr> antrik: hm ? + <braunr> the worst case is that many threads will evalute spawn to 1 and + create threads, whereas only one of them should have + <antrik> braunr: I'm not sure perror() is a good way to handle the + situation where thread creation failed. this would usually happen because + of resource shortage, right? in that case, it should work in non-debug + builds too + <braunr> perror isn't specific to debug builds + <braunr> i'm building glibc packages with a pthreads-enabled hurd :> + <braunr> (which at one point run the test allocating and filling 2 GiB of + memory, which passed) + <braunr> (with a kernel using a 3/1 split of course, swap usage reached + something like 1.6 GiB) + <antrik> braunr: BTW, I think the observation that thread storms tend to + happen on destroying stuff more than on creating stuff has been made + before... + <braunr> ok + <antrik> braunr: you are right about perror() of course. brain fart -- was + thinking about assert_perror() + <antrik> (which is misused in some places in existing Hurd code...) + <antrik> braunr: I still don't see the issue with the "spawn" + locking... the only situation where this code can be executed + concurrently is when multiple threads are idle and handling incoming + request -- but in that case spawning does *not* happen anyways... + <antrik> unless you are talking about something else than what I'm thinking + of... + <braunr> well imagine you have idle threads, yes + <braunr> let's say a lot like a thousand + <braunr> and the server gets a thousand requests + <braunr> a one more :p + <braunr> normally only one thread should be created to handle it + <braunr> but here, the worst case is that all threads run internal_demuxer + roughly at the same time + <braunr> and they all determine they need to spawn a thread + <braunr> leading to another thousand + <braunr> (that's extreme and very unlikely in practice of course) + <antrik> oh, I see... you mean all the idle threads decide that no spawning + is necessary; but before they proceed, finally one comes in and decides + that it needs to spawn; and when the other ones are scheduled again they + all spawn unnecessarily? + <braunr> no, spawn is a local variable + <braunr> it's rather, all idle threads become busy, and right before + servicing their request, they all decide they must spawn a thread + <antrik> I don't think that's how it works. changing the status to busy (by + decrementing the idle counter) and checking that there are no idle + threads is atomic, isn't it? + <braunr> no + <antrik> oh + <antrik> I guess I should actually look at that code (again) before + commenting ;-) + <braunr> let me check + <braunr> no sorry you're right + <braunr> so right, you can't lead to that situation + <braunr> i don't even understand how i can't see that :/ + <braunr> let's say it's the heat :p + <braunr> 22:08 < braunr> so right, you can't lead to that situation + <braunr> it can't lead to that situation + + +## IRC, freenode, #hurd, 2012-08-18 + + <braunr> one more attempt at fixing netdde, hope i get it right this time + <braunr> some parts assume a ddekit thread is a cthread, because they share + the same address + <braunr> it's not as easy when using pthread_self :/ + <braunr> good, i got netdde work with pthreads + <braunr> youpi: for reference, there are now glibc, hurd and netdde + packages on my repository + <braunr> youpi: the debian specific patches can be found at my git + repository (http://git.sceen.net/rbraun/debian_hurd.git/ and + http://git.sceen.net/rbraun/debian_netdde.git/) + <braunr> except a freeze during boot (between exec and init) which happens + rarely, and the starvation which still exists to some extent (fakeroot + can cause many threads to be created in pfinet and pflocal), the + glibc/hurd packages have been working fine for a few days now + <braunr> the threading issue in pfinet/pflocal is directly related to + select, which the io_select_timeout patches should fix once merged + <braunr> well, considerably reduce at least + <braunr> and maybe fix completely, i'm not sure + + +## IRC, freenode, #hurd, 2012-08-27 + + <pinotree> braunr: wrt a78a95d in your pthread branch of hurd.git, + shouldn't that job theorically been done using pthread api (of course + after implementing it)? + <braunr> pinotree: sure, it could be done through pthreads + <braunr> pinotree: i simply restricted myself to moving the hurd to + pthreads, not augment libpthread + <braunr> (you need to remember that i work on hurd with pthreads because it + became a dependency of my work on fixing select :p) + <braunr> and even if it wasn't the reason, it is best to do these tasks + (replace cthreads and implement pthread scheduling api) separately + <pinotree> braunr: hm ok + <pinotree> implementing the pthread priority bits could be done + independently though + + <braunr> youpi: there are more than 9000 threads for /hurd/streamio kmsg on + ironforge oO + <youpi> kmsg ?! + <youpi> it's only /dev/klog right? + <braunr> not sure but it seems so + <pinotree> which syslog daemon is running? + <youpi> inetutils + <youpi> I've restarted the klog translator, to see whether when it grows + again + + <braunr> 6 hours and 21 minutes to build glibc on darnassus + <braunr> pfinet still runs only 24 threads + <braunr> the ext2 instance used for the build runs 2k threads, but that's + because of the pageouts + <braunr> so indeed, the priority patch helps a lot + <braunr> (pfinet used to have several hundreds, sometimes more than a + thousand threads after a glibc build, and potentially increasing with + each use of fakeroot) + <braunr> exec weights 164M eww, we definitely have to fix that leak + <braunr> the leaks are probably due to wrong mmap/munmap usage + +[[exec_leak]]. + + +### IRC, freenode, #hurd, 2012-08-29 + + <braunr> youpi: btw, after my glibc build, there were as little as between + 20 and 30 threads for pflocal and pfinet + <braunr> with the priority patch + <braunr> ext2fs still had around 2k because of pageouts, but that's + expected + <youpi> ok + <braunr> overall the results seem very good and allow the switch to + pthreads + <youpi> yep, so it seems + <braunr> youpi: i think my first integration branch will include only a few + changes, such as this priority tuning, and the replacement of + condition_implies + <youpi> sure + <braunr> so we can push the move to pthreads after all its small + dependencies + <youpi> yep, that's the most readable way + + +## IRC, freenode, #hurd, 2012-09-03 + + <gnu_srs> braunr: Compiling yodl-3.00.0-7: + <gnu_srs> pthreads: real 13m42.460s, user 0m0.000s, sys 0m0.030s + <gnu_srs> cthreads: real 9m 6.950s, user 0m0.000s, sys 0m0.020s + <braunr> thanks + <braunr> i'm not exactly certain about what causes the problem though + <braunr> it could be due to libpthread using doubly-linked lists, but i + don't think the overhead would be so heavier because of that alone + <braunr> there is so much contention sometimes that it could + <braunr> the hurd would have been better off with single threaded servers + :/ + <braunr> we should probably replace spin locks with mutexes everywhere + <braunr> on the other hand, i don't have any more starvation problem with + the current code + + +### IRC, freenode, #hurd, 2012-09-06 + + <gnu_srs> braunr: Yes you are right, the new pthread-based Hurd is _much_ + slower. + <gnu_srs> One annoying example is when compiling, the standard output is + written in bursts with _long_ periods of no output in between:-( + <braunr> that's more probably because of the priority boost, not the + overhead + <braunr> that's one of the big issues with our mach-based model + <braunr> we either give high priorities to our servers, or we can suffer + from message floods + <braunr> that's in fact more a hurd problem than a mach one + <gnu_srs> braunr: any immediate ideas how to speed up responsiveness the + pthread-hurd. It is annoyingly slow (slow-witted) + <braunr> gnu_srs: i already answered that + <braunr> it doesn't look that slower on my machines though + <gnu_srs> you said you had some ideas, not which. except for mcsims work. + <braunr> i have ideas about what makes it slower + <braunr> it doesn't mean i have solutions for that + <braunr> if i had, don't you think i'd have applied them ? :) + <gnu_srs> ok, how to make it more responsive on the console? and printing + stdout more regularly, now several pages are stored and then flushed. + <braunr> give more details please + <gnu_srs> it behaves like a loaded linux desktop, with little memory + left... + <braunr> details about what you're doing + <gnu_srs> apt-get source any big package and: fakeroot debian/rules binary + 2>&1 | tee ../binary.logg + <braunr> isee + <braunr> well no, we can't improve responsiveness + <braunr> without reintroducing the starvation problem + <braunr> they are linked + <braunr> and what you're doing involes a few buffers, so the laggy feel is + expected + <braunr> if we can fix that simply, we'll do so after it is merged upstream + + +### IRC, freenode, #hurd, 2012-09-07 + + <braunr> gnu_srs: i really don't feel the sluggishness you described with + hurd+pthreads on my machines + <braunr> gnu_srs: what's your hardware ? + <braunr> and your VM configuration ? + <gnu_srs> Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz + <gnu_srs> kvm -m 1024 -net nic,model=rtl8139 -net + user,hostfwd=tcp::5562-:22 -drive + cache=writeback,index=0,media=disk,file=hurd-experimental.img -vnc :6 + -cdrom isos/netinst_2012-07-15.iso -no-kvm-irqchip + <braunr> what is the file system type where your disk image is stored ? + <gnu_srs> ext3 + <braunr> and how much physical memory on the host ? + <braunr> (paste meminfo somewhere please) + <gnu_srs> 4G, and it's on the limit, 2 kvm instances+gnome,etc + <gnu_srs> 80% in use by programs, 14% in cache. + <braunr> ok, that's probably the reason then + <braunr> the writeback option doesn't help a lot if you don't have much + cache + <gnu_srs> well the other instance is cthreads based, and not so sluggish. + <braunr> we know hurd+pthreads is slower + <braunr> i just wondered why i didn't feel it that much + <gnu_srs> try to fire up more kvm instances, and do a heavy compile... + <braunr> i don't do that :) + <braunr> that's why i never had the problem + <braunr> most of the time i have like 2-3 GiB of cache + <braunr> and of course more on shattrath + <braunr> (the host of the sceen.net hurdboxes, which has 16 GiB of ram) + + +### IRC, freenode, #hurd, 2012-09-11 + + <gnu_srs> Monitoring the cthreads and the pthreads load under Linux shows: + <gnu_srs> cthread version: load can jump very high, less cpu usage than + pthread version + <gnu_srs> pthread version: less memory usage, background cpu usage higher + than for cthread version + <braunr> that's the expected behaviour + <braunr> gnu_srs: are you using the lifothreads gnumach kernel ? + <gnu_srs> for experimental, yes. + <gnu_srs> i.e. pthreads + <braunr> i mean, you're measuring on it right now, right ? + <gnu_srs> yes, one instance running cthreads, and one pthreads (with lifo + gnumach) + <braunr> ok + <gnu_srs> no swap used in either instance, will try a heavy compile later + on. + <braunr> what for ? + <gnu_srs> E.g. for memory when linking. I have swap available, but no swap + is used currently. + <braunr> yes but, what do you intend to measure ? + <gnu_srs> don't know, just to see if swap is used at all. it seems to be + used not very much. + <braunr> depends + <braunr> be warned that using the swap means there is pageout, which is one + of the triggers for global system freeze :p + <braunr> anonymous memory pageout + <gnu_srs> for linux swap is used constructively, why not on hurd? + <braunr> because of hard to squash bugs + <gnu_srs> aha, so it is bugs hindering swap usage:-/ + <braunr> yup :/ + <gnu_srs> Let's find them thenO:-), piece of cake + <braunr> remember my page cache branch in gnumach ? :) + +[[gnumach_page_cache_policy]]. + + <gnu_srs> not much + <braunr> i started it before fixing non blocking select + <braunr> anyway, as a side effect, it should solve this stability issue + too, but it'll probably take time + <gnu_srs> is that branch integrated? I only remember slab and the lifo + stuff. + <gnu_srs> and mcsims work + <braunr> no it's not + <braunr> it's unfinished + <gnu_srs> k! + <braunr> it correctly extends the page cache to all available physical + memory, but since the hurd doesn't scale well, it slows the system down + + +## IRC, freenode, #hurd, 2012-09-14 + + <braunr> arg + <braunr> darnassus seems to eat 100% cpu and make top freeze after some + time + <braunr> seems like there is an important leak in the pthreads version + <braunr> could be the lifothreads patch :/ + <cjbirk> there's a memory leak? + <cjbirk> in pthreads? + <braunr> i don't think so, and it's not a memory leak + <braunr> it's a port leak + <braunr> probably in the kernel + + +### IRC, freenode, #hurd, 2012-09-17 + + <braunr> nice, the port leak is actually caused by the exim4 loop bug + + +### IRC, freenode, #hurd, 2012-09-23 + + <braunr> the port leak i observed a few days ago is because of exim4 (the + infamous loop eating the cpu we've been seeing regularly) + +[[fork_deadlock]]? + + <youpi> oh + <braunr> next time it happens, and if i have the occasion, i'll examine the + problem + <braunr> tip: when you can't use top or ps -e, you can use ps -e -o + pid=,args= + <youpi> or -M ? + <braunr> haven't tested + + +## IRC, freenode, #hurd, 2012-09-23 + + <braunr> tschwinge: i committed the last hurd pthread change, + http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads + <braunr> tschwinge: please tell me if you consider it ok for merging + + +### IRC, freenode, #hurd, 2012-11-27 + + <youpi> braunr: btw, I forgot to forward here, with the glibc patch it does + boot fine, I'll push all that and build some almost-official packages for + people to try out what will come when eglibc gets the change in unstable + <braunr> youpi: great :) + <youpi> thanks for managing the final bits of this + <youpi> (and thanks for everybody involved) + <braunr> sorry again for the non obvious parts + <braunr> if you need the debian specific parts refined (e.g. nice commits + for procfs & others), i can do that + <youpi> I'll do that, no pb + <braunr> ok + <braunr> after that (well, during also), we should focus more on bug + hunting + + +## IRC, freenode, #hurd, 2012-10-26 + + <mcsim1> hello. What does following error message means? "unable to adjust + libports thread priority: Operation not permitted" It appears when I set + translators. + <mcsim1> Seems has some attitude to libpthread. Also following appeared + when I tried to remove translator: "pthread_create: Resource temporarily + unavailable" + <mcsim1> Oh, first message appears very often, when I use translator I set. + <braunr> mcsim1: it's related to a recent patch i sent + <braunr> mcsim1: hurd servers attempt to increase their priority on startup + (when a thread is created actually) + <braunr> to reduce message floods and thread storms (such sweet names :)) + <braunr> but if you start them as an unprivileged user, it fails, which is + ok, it's just a warning + <braunr> the second way is weird + <braunr> it normally happens when you're out of available virtual space, + not when shutting a translator donw + <mcsim1> braunr: you mean this patch: libports: reduce thread starvation on + message floods? + <braunr> yes + <braunr> remember you're running on darnassus + <braunr> with a heavily modified hurd/glibc + <braunr> you can go back to the cthreads version if you wish + <mcsim1> it's better to check translators privileges, before attempting to + increase their priority, I think. + <braunr> no + <mcsim1> it's just a bit annoying + <braunr> privileges can be changed during execution + <braunr> well remove it + <mcsim1> But warning should not appear. + <braunr> what could be done is to limit the warning to one occurrence + <braunr> mcsim1: i prefer that it appears + <mcsim1> ok + <braunr> it's always better to be explicit and verbose + <braunr> well not always, but very often + <braunr> one of the reasons the hurd is so difficult to debug is the lack + of a "message server" à la dmesg + +[[translator_stdout_stderr]]. + + +### IRC, freenode, #hurd, 2012-12-10 + + <youpi> braunr: unable to adjust libports thread priority: (ipc/send) + invalid destination port + <youpi> I'll see what package brought that + <youpi> (that was on a buildd) + <braunr> wow + <youpi> mkvtoolnix_5.9.0-1: + <pinotree> shouldn't that code be done in pthreads and then using such + pthread api? :p + <braunr> pinotree: you've already asked that question :p + <pinotree> i know :p + <braunr> the semantics of pthreads are larger than what we need, so that + will be done "later" + <braunr> but this error shouldn't happen + <braunr> it looks more like a random mach bug + <braunr> youpi: anything else on the console ? + <youpi> nope + <braunr> i'll add traces to know which step causes the error + + +## IRC, freenode, #hurd, 2012-12-05 + + <braunr> tschwinge: i'm currently working on a few easy bugs and i have + planned improvements for libpthreads soon + <pinotree> wotwot, which ones? + <braunr> pinotree: first, fixing pthread_cond_timedwait (and everything + timedsomething actually) + <braunr> pinotree: then, fixing cancellation + <braunr> pinotree: and last but not least, optimizing thread wakeup + <braunr> i also want to try replacing spin locks and see if it does what i + expect + <pinotree> which fixes do you plan applying to cond_timedwait? + <braunr> see sysdeps/generic/pt-cond-timedwait.c + <braunr> the FIXME comment + <pinotree> ah that + <braunr> well that's important :) + <braunr> did you have something else in mind ? + <pinotree> hm, __pthread_timedblock... do you plan fixing directly there? i + remember having seem something related to that (but not on conditions), + but wasn't able to see further + <braunr> it has the same issue + <braunr> i don't remember the details, but i wrote a cthreads version that + does it right + <braunr> in the io_select_timeout branch + <braunr> see + http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cancel-cond.c?h=rbraun/select_timeout + for example + * pinotree looks + <braunr> what matters is the msg_delivered member used to synchronize + sleeper and waker + <braunr> the waker code is in + http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/libthreads/cprocs.c?h=rbraun/select_timeout + <pinotree> never seen cthreads' code before :) + <braunr> soon you shouldn't have any more reason to :p + <pinotree> ah, so basically the cthread version of the pthread cleanup + stack + cancelation (ie the cancel hook) broadcasts the condition + <braunr> yes + <pinotree> so a similar fix would be needed in all the places using + __pthread_timedblock, that is conditions and mutexes + <braunr> and that's what's missing in glibc that prevents deploying a + pthreads based hurd currently + <braunr> no that's unrelated + <pinotree> ok + <braunr> the problem is how __pthread_block/__pthread_timedblock is + synchronized with __pthread_wakeup + <braunr> libpthreads does exactly the same thing as cthreads for that, + i.e. use messages + <braunr> but the message alone isn't enough, since, as explained in the + FIXME comment, it can arrive too late + <braunr> it's not a problem for __pthread_block because this function can + only resume after receiving a message + <braunr> but it's a problem for __pthread_timedblock which can resume + because of a timeout + <braunr> my solution is to add a flag that says whether a message was + actually sent, and lock around sending the message, so that the thread + resume can accurately tell in which state it is + <braunr> and drain the message queue if needed + <pinotree> i see, race between the "i stop blocking because of timeout" and + "i stop because i got a message" with the actual check for the real cause + <braunr> locking around mach_msg may seem overkill but it's not in + practice, since there can only be one message at most in the message + queue + <braunr> and i checked that in practice by limiting the message queue size + and check for such errors + <braunr> but again, it would be far better with mutexes only, and no spin + locks + <braunr> i wondered for a long time why the load average was so high on the + hurd under even "light" loads + <braunr> now i know :) diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn new file mode 100644 index 00000000..37231c66 --- /dev/null +++ b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2012 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_libphread]] + +`t/have_kernel_resources` + + +# IRC, freenode, #hurd, 2012-08-30 + + <braunr> tschwinge: this issue needs more cooperation with the kernel + <braunr> tschwinge: i.e. the ability to tell the kernel where the stack is, + so it's unmapped when the thread dies + <braunr> which requiring another thread to perform this deallocation diff --git a/open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn b/open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn new file mode 100644 index 00000000..4396cf59 --- /dev/null +++ b/open_issues/libpthread_1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal.mdwn @@ -0,0 +1,849 @@ +[[!meta copyright="Copyright 2012 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]] + +Things found in a `git diff +1fcd93fd3c733eb19bcad8d03e65f13ec4b0e998..master-viengoos-on-bare-metal` that +are not specific to L4 or Viengoos, and may be worth having on master, too. + + +# `__pthread_alloc` init with `malloc` or `calloc` + + diff --git a/pthread/pt-alloc.c b/pthread/pt-alloc.c + index 6af2da9..c63801f 100644 + --- a/pthread/pt-alloc.c + +++ b/pthread/pt-alloc.c + @@ -123,7 +123,7 @@ __pthread_alloc (struct __pthread **pthread) + } + + /* Allocate a new thread structure. */ + - new = malloc (sizeof (struct __pthread)); + + new = calloc (sizeof (struct __pthread), 1); + if (new == NULL) + return ENOMEM; + + + +# `atomic.h` + +Later on master, commit 608a12659f15d57abf42a972c1e56c6a24cfe244: `Rename +bits/atomic.h to bits/pt-atomic.h`. + + diff --git a/pthread/pt-create.c b/pthread/pt-create.c + index 8f62b78..504cacc 100644 + --- a/pthread/pt-create.c + +++ b/pthread/pt-create.c + @@ -22,7 +22,7 @@ + #include <pthread.h> + #include <signal.h> + + -#include <bits/atomic.h> + +#include <atomic.h> + + #include <pt-internal.h> + + @@ -33,7 +33,7 @@ + /* The total number of pthreads currently active. This is defined + here since it would be really stupid to have a threads-using + program that doesn't call `pthread_create'. */ + -__atomic_t __pthread_total; + +atomic_fast32_t __pthread_total; + + + /* The entry-point for new threads. */ + @@ -163,7 +163,7 @@ __pthread_create_internal (struct __pthread **thread, + the number of threads from within the new thread isn't an option + since this thread might return and call `pthread_exit' before the + new thread runs. */ + - __atomic_inc (&__pthread_total); + + atomic_increment (&__pthread_total); + + /* Store a pointer to this thread in the thread ID lookup table. We + could use __thread_setid, however, we only lock for reading as no + @@ -190,7 +190,7 @@ __pthread_create_internal (struct __pthread **thread, + + failed_starting: + __pthread_setid (pthread->thread, NULL); + - __atomic_dec (&__pthread_total); + + atomic_decrement (&__pthread_total); + failed_sigstate: + __pthread_sigstate_destroy (pthread); + failed_setup: + diff --git a/pthread/pt-exit.c b/pthread/pt-exit.c + index 5fe0ba8..68c56d7 100644 + --- a/pthread/pt-exit.c + +++ b/pthread/pt-exit.c + @@ -24,7 +24,7 @@ + + #include <pt-internal.h> + + -#include <bits/atomic.h> + +#include <atomic.h> + + + /* Terminate the current thread and make STATUS available to any + @@ -57,7 +57,7 @@ pthread_exit (void *status) + + /* Decrease the number of threads. We use an atomic operation to + make sure that only the last thread calls `exit'. */ + - if (__atomic_dec_and_test (&__pthread_total)) + + if (atomic_decrement_and_test (&__pthread_total)) + /* We are the last thread. */ + exit (0); + + diff --git a/pthread/pt-internal.h b/pthread/pt-internal.h + index cb441d0..986ec6b 100644 + --- a/pthread/pt-internal.h + +++ b/pthread/pt-internal.h + @@ -26,13 +26,15 @@ + #include <signal.h> + #include <assert.h> + + -#include <bits/atomic.h> + +#include <atomic.h> + [...] + @@ -136,7 +144,7 @@ __pthread_dequeue (struct __pthread *thread) + ) + + /* The total number of threads currently active. */ + -extern __atomic_t __pthread_total; + +extern atomic_fast32_t __pthread_total; + + /* The total number of thread IDs currently in use, or on the list of + available thread IDs. */ + diff --git a/sysdeps/ia32/bits/atomic.h b/sysdeps/ia32/bits/atomic.h + deleted file mode 100644 + index 0dfc1f6..0000000 + --- a/sysdeps/ia32/bits/atomic.h + +++ /dev/null + @@ -1,66 +0,0 @@ + -/* Atomic operations. i386 version. + - Copyright (C) 2000 Free Software Foundation, Inc. + - This file is part of the GNU C Library. + - + - The GNU C Library is free software; you can redistribute it and/or + - modify it under the terms of the GNU Library General Public License as + - published by the Free Software Foundation; either version 2 of the + - License, or (at your option) any later version. + - + - The GNU C Library is distributed in the hope that it will be useful, + - but WITHOUT ANY WARRANTY; without even the implied warranty of + - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + - Library General Public License for more details. + - + - You should have received a copy of the GNU Library General Public + - License along with the GNU C Library; see the file COPYING.LIB. If not, + - write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + - Boston, MA 02111-1307, USA. */ + - + -#ifndef _BITS_ATOMIC_H + -#define _BITS_ATOMIC_H 1 + - + -typedef __volatile int __atomic_t; + - + -static inline void + -__atomic_inc (__atomic_t *__var) + -{ + - __asm__ __volatile ("lock; incl %0" : "=m" (*__var) : "m" (*__var)); + -} + - + -static inline void + -__atomic_dec (__atomic_t *__var) + -{ + - __asm__ __volatile ("lock; decl %0" : "=m" (*__var) : "m" (*__var)); + -} + - + -static inline int + -__atomic_dec_and_test (__atomic_t *__var) + -{ + - unsigned char __ret; + - + - __asm__ __volatile ("lock; decl %0; sete %1" + - : "=m" (*__var), "=qm" (__ret) : "m" (*__var)); + - return __ret != 0; + -} + - + -/* We assume that an __atomicptr_t is only used for pointers to + - word-aligned objects, and use the lowest bit for a simple lock. */ + -typedef __volatile int * __atomicptr_t; + - + -/* Actually we don't implement that yet, and assume that we run on + - something that has the i486 instruction set. */ + -static inline int + -__atomicptr_compare_and_swap (__atomicptr_t *__ptr, void *__oldval, + - void * __newval) + -{ + - char __ret; + - int __dummy; + - + - __asm__ __volatile ("lock; cmpxchgl %3, %1; sete %0" + - : "=q" (__ret), "=m" (*__ptr), "=a" (__dummy) + - : "r" (__newval), "m" (*__ptr), "a" (__oldval)); + - return __ret; + -} + - + -#endif + + +# Memory Barries + + diff --git a/sysdeps/generic/bits/memory.h b/sysdeps/generic/bits/memory.h + new file mode 100644 + index 0000000..7b88a7e + --- /dev/null + +++ b/sysdeps/generic/bits/memory.h + @@ -0,0 +1,36 @@ + +/* Memory barrier operations. Generic version. + + Copyright (C) 2008 Free Software Foundation, Inc. + + This file is part of the GNU Hurd. + + + + The GNU Hurd is free software; you can redistribute it and/or + + modify it under the terms of the GNU General Public License as + + published by the Free Software Foundation; either version 3 of the + + License, or (at your option) any later version. + + + + The GNU Hurd is distributed in the hope that it will be useful, but + + WITHOUT ANY WARRANTY; without even the implied warranty of + + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + + General Public License for more details. + + + + You should have received a copy of the GNU General Public License + + along with this program. If not, see + + <http://www.gnu.org/licenses/>. */ + + + +#ifndef _BITS_MEMORY_H + +#define _BITS_MEMORY_H 1 + + + +/* Prevent read and write reordering across this function. */ + +static inline void + +__memory_barrier (void) + +{ + + /* Any lock'ed instruction will do. */ + + __sync_synchronize (); + +} + + + +/* Prevent read reordering across this function. */ + +#define __memory_read_barrier __memory_barrier + + + +/* Prevent write reordering across this function. */ + +#define __memory_write_barrier __memory_barrier + + + +#endif + + +# Spin Locks + + diff --git a/sysdeps/generic/bits/spin-lock-inline.h b/sysdeps/generic/bits/spin-lock-inline.h + new file mode 100644 + index 0000000..6c3e06e + --- /dev/null + +++ b/sysdeps/generic/bits/spin-lock-inline.h + @@ -0,0 +1,99 @@ + +/* Machine-specific definitions for spin locks. Generic version. + + Copyright (C) 2000, 2005, 2008 Free Software Foundation, Inc. + + This file is part of the GNU C Library. + + + + The GNU C Library is free software; you can redistribute it and/or + + modify it under the terms of the GNU Library General Public License as + + published by the Free Software Foundation; either version 2 of the + + License, or (at your option) any later version. + + + + The GNU C Library is distributed in the hope that it will be useful, + + but WITHOUT ANY WARRANTY; without even the implied warranty of + + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + + Library General Public License for more details. + + + + You should have received a copy of the GNU Library General Public + + License along with the GNU C Library; see the file COPYING.LIB. If not, + + write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, + + Boston, MA 02111-1307, USA. */ + + + +/* + + * Never include this file directly; use <pthread.h> or <cthreads.h> instead. + + */ + + + +#ifndef _BITS_SPIN_LOCK_INLINE_H + +#define _BITS_SPIN_LOCK_INLINE_H 1 + + + +#include <features.h> + +#include <bits/spin-lock.h> + + + +__BEGIN_DECLS + + + +#if defined __USE_EXTERN_INLINES || defined _FORCE_INLINES + + + +# if !defined (__EBUSY) || !defined (__EINVAL) + +# include <errno.h> + +# ifndef __EBUSY + +# define __EBUSY EBUSY + +# endif + +# ifndef __EINVAL + +# define __EINVAL EINVAL + +# endif + +# endif + + + +# ifndef __PT_SPIN_INLINE + +# define __PT_SPIN_INLINE __extern_inline + +# endif + + + +__PT_SPIN_INLINE int __pthread_spin_destroy (__pthread_spinlock_t *__lock); + + + +__PT_SPIN_INLINE int + +__pthread_spin_destroy (__pthread_spinlock_t *__lock) + +{ + + return 0; + +} + + + +__PT_SPIN_INLINE int __pthread_spin_init (__pthread_spinlock_t *__lock, + + int __pshared); + + + +__PT_SPIN_INLINE int + +__pthread_spin_init (__pthread_spinlock_t *__lock, int __pshared) + +{ + + *__lock = __SPIN_LOCK_INITIALIZER; + + return 0; + +} + + + +__PT_SPIN_INLINE int __pthread_spin_trylock (__pthread_spinlock_t *__lock); + + + +__PT_SPIN_INLINE int + +__pthread_spin_trylock (__pthread_spinlock_t *__lock) + +{ + + int __locked = __sync_val_compare_and_swap (__lock, 0, 1); + + return __locked ? __EBUSY : 0; + +} + + + +__extern_inline int __pthread_spin_lock (__pthread_spinlock_t *__lock); + +extern int _pthread_spin_lock (__pthread_spinlock_t *__lock); + + + +__extern_inline int + +__pthread_spin_lock (__pthread_spinlock_t *__lock) + +{ + + if (__pthread_spin_trylock (__lock)) + + return _pthread_spin_lock (__lock); + + return 0; + +} + + + +__PT_SPIN_INLINE int __pthread_spin_unlock (__pthread_spinlock_t *__lock); + + + +__PT_SPIN_INLINE int + +__pthread_spin_unlock (__pthread_spinlock_t *__lock) + +{ + + int __locked = __sync_val_compare_and_swap (__lock, 1, 0); + + return __locked ? 0 : __EINVAL; + +} + + + +#endif /* Use extern inlines or force inlines. */ + + + +__END_DECLS + + + +#endif /* bits/spin-lock.h */ + diff --git a/sysdeps/l4/bits/pthread-np.h b/sysdeps/generic/bits/spin-lock.h + similarity index 67% + rename from sysdeps/l4/bits/pthread-np.h + rename to sysdeps/generic/bits/spin-lock.h + index 6a02bdc..c2ba332 100644 + --- a/sysdeps/l4/bits/pthread-np.h + +++ b/sysdeps/generic/bits/spin-lock.h + @@ -1,5 +1,5 @@ + -/* Non-portable functions. L4 version. + - Copyright (C) 2003, 2007 Free Software Foundation, Inc. + +/* Machine-specific definitions for spin locks. Generic version. + + Copyright (C) 2000, 2005, 2008 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + @@ -21,15 +21,19 @@ + * Never include this file directly; use <pthread.h> or <cthreads.h> instead. + */ + + -#ifndef _BITS_PTHREAD_NP_H + -#define _BITS_PTHREAD_NP_H 1 + +#ifndef _BITS_SPIN_LOCK_H + +#define _BITS_SPIN_LOCK_H 1 + + -#include <l4.h> + +#include <features.h> + + -/* Add the thread TID to the internal kernel thread pool. */ + -extern int pthread_pool_add_np (l4_thread_id_t tid); + +__BEGIN_DECLS + + -/* Get the first thread from the pool. */ + -extern l4_thread_id_t pthread_pool_get_np (void); + +/* The type of a spin lock object. */ + +typedef __volatile int __pthread_spinlock_t; + + -#endif /* bits/pthread-np.h */ + +/* Initializer for a spin lock object. */ + +# define __SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + + + +__END_DECLS + + + +#endif /* bits/spin-lock.h */ + + +# Signal Stuff + + diff --git a/pthread/pt-internal.h b/pthread/pt-internal.h + index cb441d0..986ec6b 100644 + --- a/pthread/pt-internal.h + +++ b/pthread/pt-internal.h + @@ -26,13 +26,15 @@ + [...] + #include <pt-sysdep.h> + #include <pt-machdep.h> + + +#include <sig-internal.h> + + + /* Thread state. */ + enum pthread_state + { + @@ -54,6 +56,10 @@ enum pthread_state + # define PTHREAD_SYSDEP_MEMBERS + #endif + + +#ifndef PTHREAD_SIGNAL_MEMBERS + +# define PTHREAD_SIGNAL_MEMBERS + +#endif + + + /* This structure describes a POSIX thread. */ + struct __pthread + { + @@ -89,6 +95,8 @@ struct __pthread + + PTHREAD_SYSDEP_MEMBERS + + + PTHREAD_SIGNAL_MEMBERS + + + struct __pthread *next, **prevp; + }; + + diff --git a/signal/kill.c b/signal/kill.c + index 27c9c32..c281640 100644 + --- a/signal/kill.c + +++ b/signal/kill.c + @@ -20,6 +20,8 @@ + + #include "sig-internal.h" + + +#include <string.h> + + + int + kill (pid_t pid, int signo) + { + @@ -65,6 +67,12 @@ kill (pid_t pid, int signo) + current thread has blocked the signal, the correct thing to do is + to iterate over all the other threads and find on that hasn't + blocked it. */ + + + + extern int __pthread_num_threads; + + if (__pthread_num_threads == 0) + + panic ("signal %d received before pthread library is able to handle it", + + signo); + + + return pthread_kill (pthread_self (), signo); + } + + diff --git a/signal/pt-kill-siginfo-np.c b/signal/pt-kill-siginfo-np.c + index 9bdf6cc..35642c3 100644 + --- a/signal/pt-kill-siginfo-np.c + +++ b/signal/pt-kill-siginfo-np.c + @@ -75,7 +75,8 @@ pthread_kill_siginfo_np (pthread_t tid, siginfo_t si) + || (ss->stack.ss_flags & SS_DISABLE) + || (ss->stack.ss_flags & SS_ONSTACK))) + /* We are sending a signal to ourself and we don't use an + - alternate stack. */ + + alternate stack. (Recall: SA_ONSTACK means use the alt + + stack.) */ + signal_dispatch (ss, &si); + else + signal_dispatch_lowlevel (ss, tid, si); + diff --git a/signal/signal-dispatch.c b/signal/signal-dispatch.c + index 40440b7..6fafcc1 100644 + --- a/signal/signal-dispatch.c + +++ b/signal/signal-dispatch.c + @@ -20,6 +20,8 @@ + + #include "sig-internal.h" + + +#include <viengoos/math.h> + + + /* This is the signal handler entry point. A thread is forced into + this state when it receives a signal. We need to save the thread's + state and then invoke the high-level signal dispatcher. SS->LOCK + @@ -107,7 +109,7 @@ signal_dispatch (struct signal_state *ss, siginfo_t *si) + sigset_t pending = ~ss->blocked & ss->pending; + if (! pending) + pending = ~ss->blocked & process_pending; + - signo = l4_lsb64 (pending); + + signo = vg_lsb64 (pending); + } + while (signo); + + diff --git a/signal/sigwaiter.c b/signal/sigwaiter.c + index 8d041ac..adc05ca 100644 + --- a/signal/sigwaiter.c + +++ b/signal/sigwaiter.c + @@ -20,7 +20,7 @@ + + #include "sig-internal.h" + + -#include <hurd/futex.h> + +#include <viengoos/futex.h> + + struct sigwaiter *sigwaiters; + + diff --git a/signal/sigwaitinfo.c b/signal/sigwaitinfo.c + index 1b47079..dea3ef4 100644 + --- a/signal/sigwaitinfo.c + +++ b/signal/sigwaitinfo.c + @@ -43,7 +43,7 @@ sigwaitinfo (const sigset_t *restrict set, siginfo_t *restrict info) + + assert (extant); + + - int signo = l4_msb64 (extant); + + int signo = vg_msb64 (extant); + + if (info) + { + + +# `ALWAYS_TRACK_MUTEX_OWNER` + + diff --git a/sysdeps/generic/pt-mutex-timedlock.c b/sysdeps/generic/pt-mutex-timedlock.c + index ee43219..265a453 100644 + --- a/sysdeps/generic/pt-mutex-timedlock.c + +++ b/sysdeps/generic/pt-mutex-timedlock.c + @@ -36,7 +36,6 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex, + if (__pthread_spin_trylock (&mutex->__held) == 0) + /* Successfully acquired the lock. */ + { + -#ifdef ALWAYS_TRACK_MUTEX_OWNER + #ifndef NDEBUG + self = _pthread_self (); + if (self) + @@ -48,7 +47,6 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex, + mutex->owner = _pthread_self (); + } + #endif + -#endif + + if (mutex->attr) + switch (mutex->attr->mutex_type) + @@ -75,16 +73,14 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex, + self = _pthread_self (); + assert (self); + + - if (! mutex->attr || mutex->attr->mutex_type == PTHREAD_MUTEX_NORMAL) + - { + -#if defined(ALWAYS_TRACK_MUTEX_OWNER) + - assert (mutex->owner != self); + -#endif + - } + - else + + if (mutex->attr) + { + switch (mutex->attr->mutex_type) + { + + case PTHREAD_MUTEX_NORMAL: + + assert (mutex->owner != self); + + break; + + + case PTHREAD_MUTEX_ERRORCHECK: + if (mutex->owner == self) + { + @@ -106,10 +102,9 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex, + LOSE; + } + } + + else + + assert (mutex->owner != self); + + -#if !defined(ALWAYS_TRACK_MUTEX_OWNER) + - if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL) + -#endif + assert (mutex->owner); + + if (abstime && (abstime->tv_nsec < 0 || abstime->tv_nsec >= 1000000000)) + @@ -146,12 +141,9 @@ __pthread_mutex_timedlock_internal (struct __pthread_mutex *mutex, + else + __pthread_block (self); + + -#if !defined(ALWAYS_TRACK_MUTEX_OWNER) + - if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL) + -#endif + - { + +#ifndef NDEBUG + assert (mutex->owner == self); + - } + +#endif + + if (mutex->attr) + switch (mutex->attr->mutex_type) + diff --git a/sysdeps/generic/pt-mutex-transfer-np.c b/sysdeps/generic/pt-mutex-transfer-np.c + index 7796ac4..bcb809d 100644 + --- a/sysdeps/generic/pt-mutex-transfer-np.c + +++ b/sysdeps/generic/pt-mutex-transfer-np.c + @@ -45,12 +45,7 @@ __pthread_mutex_transfer_np (struct __pthread_mutex *mutex, pthread_t tid) + } + + #ifndef NDEBUG + -# if !defined(ALWAYS_TRACK_MUTEX_OWNER) + - if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL) + -# endif + - { + mutex->owner = thread; + - } + #endif + + return 0; + diff --git a/sysdeps/generic/pt-mutex-unlock.c b/sysdeps/generic/pt-mutex-unlock.c + index 7645fd4..f299750 100644 + --- a/sysdeps/generic/pt-mutex-unlock.c + +++ b/sysdeps/generic/pt-mutex-unlock.c + @@ -33,16 +33,19 @@ __pthread_mutex_unlock (pthread_mutex_t *mutex) + + if (! mutex->attr || mutex->attr->mutex_type == PTHREAD_MUTEX_NORMAL) + { + -#if defined(ALWAYS_TRACK_MUTEX_OWNER) + # ifndef NDEBUG + if (_pthread_self ()) + { + assert (mutex->owner); + - assert (mutex->owner == _pthread_self ()); + + assertx (mutex->owner == _pthread_self (), + + "%p("VG_THREAD_ID_FMT") != %p("VG_THREAD_ID_FMT")", + + mutex->owner, + + ((struct __pthread *) mutex->owner)->threadid, + + _pthread_self (), + + _pthread_self ()->threadid); + mutex->owner = NULL; + } + # endif + -#endif + } + else + switch (mutex->attr->mutex_type) + @@ -81,12 +84,7 @@ __pthread_mutex_unlock (pthread_mutex_t *mutex) + __pthread_dequeue (wakeup); + + #ifndef NDEBUG + -# if !defined (ALWAYS_TRACK_MUTEX_OWNER) + - if (mutex->attr && mutex->attr->mutex_type != PTHREAD_MUTEX_NORMAL) + -# endif + - { + mutex->owner = wakeup; + - } + #endif + + /* We do not unlock MUTEX->held: we are transferring the ownership + + +# `t/fix_have_kernel_resources` + +See topic branch of that name. + + diff --git a/sysdeps/mach/hurd/pt-sysdep.h b/sysdeps/mach/hurd/pt-sysdep.h + index f14a136..83bad96 100644 + --- a/sysdeps/mach/hurd/pt-sysdep.h + +++ b/sysdeps/mach/hurd/pt-sysdep.h + @@ -1,5 +1,5 @@ + /* Internal defenitions for pthreads library. + - Copyright (C) 2000, 2002, 2008 Free Software Foundation, Inc. + + Copyright (C) 2000, 2002 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + @@ -32,8 +32,7 @@ + + #define PTHREAD_SYSDEP_MEMBERS \ + thread_t kernel_thread; \ + - mach_msg_header_t wakeupmsg; \ + - int have_kernel_resources; + + mach_msg_header_t wakeupmsg; + + #define _HURD_THREADVAR_THREAD _HURD_THREADVAR_DYNAMIC_USER + + diff --git a/sysdeps/mach/pt-thread-alloc.c b/sysdeps/mach/pt-thread-alloc.c + index 3d7c046..1acba98 100644 + --- a/sysdeps/mach/pt-thread-alloc.c + +++ b/sysdeps/mach/pt-thread-alloc.c + @@ -1,5 +1,5 @@ + /* Start thread. Mach version. + - Copyright (C) 2000, 2002, 2005, 2008 Free Software Foundation, Inc. + + Copyright (C) 2000, 2002, 2005 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + @@ -63,9 +63,6 @@ create_wakeupmsg (struct __pthread *thread) + int + __pthread_thread_alloc (struct __pthread *thread) + { + - if (thread->have_kernel_resources) + - return 0; + - + error_t err; + + err = create_wakeupmsg (thread); + @@ -100,7 +97,5 @@ __pthread_thread_alloc (struct __pthread *thread) + return EAGAIN; + } + + - thread->have_kernel_resources = 1; + - + return 0; + } + + +# Miscellaneous + + diff --git a/Makefile b/Makefile + index 04dfb26..a4c0c52 100644 + --- a/Makefile + +++ b/Makefile + @@ -71,7 +71,6 @@ SRCS := pt-attr.c pt-attr-destroy.c pt-attr-getdetachstate.c \ + pt-mutex-init.c pt-mutex-destroy.c \ + pt-mutex-lock.c pt-mutex-trylock.c pt-mutex-timedlock.c \ + pt-mutex-unlock.c \ + - pt-mutex-transfer-np.c \ + pt-mutex-getprioceiling.c pt-mutex-setprioceiling.c \ + \ + pt-rwlock-attr.c \ + @@ -100,7 +99,6 @@ SRCS := pt-attr.c pt-attr-destroy.c pt-attr-getdetachstate.c \ + pt-thread-dealloc.c \ + pt-thread-start.c \ + pt-thread-halt.c \ + - pt-startup.c \ + \ + pt-getconcurrency.c pt-setconcurrency.c \ + \ + @@ -143,7 +141,6 @@ sysdeps_headers = \ + semaphore.h \ + \ + bits/pthread.h \ + - bits/pthread-np.h \ + bits/mutex.h \ + bits/condition.h \ + bits/condition-attr.h \ + diff --git a/Makefile.am b/Makefile.am + index e59c946..e73d8d6 100644 + --- a/Makefile.am + +++ b/Makefile.am + @@ -20,17 +20,18 @@ + if ARCH_IA32 + arch=ia32 + endif + +if ARCH_X86_64 + + arch=x86_64 + +endif + if ARCH_POWERPC + arch=powerpc + endif + + # The source files are scattered over several directories. Add + # all these directories to the vpath. + -SYSDEP_PATH = $(srcdir)/sysdeps/l4/hurd/${arch} \ + - $(srcdir)/sysdeps/l4/${arch} \ + +SYSDEP_PATH = $(srcdir)/sysdeps/viengoos/${arch} \ + $(srcdir)/sysdeps/${arch} \ + - $(srcdir)/sysdeps/l4/hurd \ + - $(srcdir)/sysdeps/l4 \ + + $(srcdir)/sysdeps/viengoos \ + $(srcdir)/sysdeps/hurd \ + $(srcdir)/sysdeps/generic \ + $(srcdir)/sysdeps/posix \ + @@ -68,7 +69,6 @@ libpthread_a_SOURCES = pt-attr.c pt-attr-destroy.c pt-attr-getdetachstate.c \ + pt-alloc.c \ + pt-create.c \ + pt-getattr.c \ + - pt-pool-np.c \ + pt-equal.c \ + pt-dealloc.c \ + pt-detach.c \ + diff --git a/headers.m4 b/headers.m4 + index 5a58b9b..7c73cf2 100644 + --- a/headers.m4 + +++ b/headers.m4 + @@ -14,10 +14,9 @@ AC_CONFIG_LINKS([ + sysroot/include/pthread.h:libpthread/include/pthread.h + sysroot/include/pthread/pthread.h:libpthread/include/pthread/pthread.h + sysroot/include/pthread/pthreadtypes.h:libpthread/include/pthread/pthreadtypes.h + - sysroot/include/bits/memory.h:libpthread/sysdeps/${arch}/bits/memory.h + - sysroot/include/bits/spin-lock.h:libpthread/sysdeps/${arch}/bits/spin-lock.h + - sysroot/include/bits/spin-lock-inline.h:libpthread/sysdeps/${arch}/bits/spin-lock-inline.h + - sysroot/include/bits/pthreadtypes.h:libpthread/sysdeps/generic/bits/pthreadtypes.h + + sysroot/include/bits/memory.h:libpthread/sysdeps/generic/bits/memory.h + + sysroot/include/bits/spin-lock.h:libpthread/sysdeps/generic/bits/spin-lock.h + + sysroot/include/bits/spin-lock-inline.h:libpthread/sysdeps/generic/bits/spin-lock-inline.h + sysroot/include/bits/barrier-attr.h:libpthread/sysdeps/generic/bits/barrier-attr.h + sysroot/include/bits/barrier.h:libpthread/sysdeps/generic/bits/barrier.h + sysroot/include/bits/cancelation.h:libpthread/sysdeps/generic/bits/cancelation.h + @@ -30,9 +29,8 @@ AC_CONFIG_LINKS([ + sysroot/include/bits/rwlock-attr.h:libpthread/sysdeps/generic/bits/rwlock-attr.h + sysroot/include/bits/rwlock.h:libpthread/sysdeps/generic/bits/rwlock.h + sysroot/include/bits/thread-attr.h:libpthread/sysdeps/generic/bits/thread-attr.h + - sysroot/include/bits/thread-barrier.h:libpthread/sysdeps/generic/bits/thread-barrier.h + sysroot/include/bits/thread-specific.h:libpthread/sysdeps/generic/bits/thread-specific.h + - sysroot/include/bits/pthread-np.h:libpthread/sysdeps/l4/hurd/bits/pthread-np.h + + sysroot/include/bits/pthread-np.h:libpthread/sysdeps/viengoos/bits/pthread-np.h + sysroot/include/semaphore.h:libpthread/include/semaphore.h + sysroot/include/bits/semaphore.h:libpthread/sysdeps/generic/bits/semaphore.h + sysroot/include/signal.h:libpthread/signal/signal.h + @@ -41,5 +39,5 @@ AC_CONFIG_LINKS([ + AC_CONFIG_COMMANDS_POST([ + mkdir -p sysroot/lib libpthread && + ln -sf ../../libpthread/libpthread.a sysroot/lib/ && + - touch libpthread/libpthread.a + + echo '/* This file intentionally left blank. */' >libpthread/libpthread.a + ]) + diff --git a/sysdeps/hurd/pt-setspecific.c b/sysdeps/hurd/pt-setspecific.c + index 89ca4d7..d2d1157 100644 + --- a/sysdeps/hurd/pt-setspecific.c + +++ b/sysdeps/hurd/pt-setspecific.c + @@ -1,5 +1,5 @@ + /* pthread_setspecific. Generic version. + - Copyright (C) 2002 Free Software Foundation, Inc. + + Copyright (C) 2002, 2008 Free Software Foundation, Inc. + This file is part of the GNU C Library. + + The GNU C Library is free software; you can redistribute it and/or + @@ -30,7 +30,8 @@ pthread_setspecific (pthread_key_t key, const void *value) + + if (! self->thread_specifics) + { + - err = hurd_ihash_create (&self->thread_specifics, HURD_IHASH_NO_LOCP); + + err = hurd_ihash_create (&self->thread_specifics, false, + + HURD_IHASH_NO_LOCP); + if (err) + return ENOMEM; + } + diff --git a/sysdeps/mach/pt-thread-halt.c b/sysdeps/mach/pt-thread-halt.c + index 973cde1..9f86024 100644 + --- a/sysdeps/mach/pt-thread-halt.c + +++ b/sysdeps/mach/pt-thread-halt.c + @@ -30,8 +30,14 @@ + being halted, thus the last action should be halting the thread + itself. */ + void + -__pthread_thread_halt (struct __pthread *thread) + +__pthread_thread_halt (struct __pthread *thread, int need_dealloc) + { + - error_t err = __thread_terminate (thread->kernel_thread); + + error_t err; + + thread_t tid = thread->kernel_thread; + + + + if (need_dealloc) + + __pthread_dealloc (thread); + + + + err = __thread_terminate (tid); + assert_perror (err); + } diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn new file mode 100644 index 00000000..5a99778b --- /dev/null +++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn @@ -0,0 +1,117 @@ +[[!meta copyright="Copyright © 2012 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: CLOCK_MONOTONIC"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]] + + +# IRC, freenode, #hurd, 2012-04-22 + + <pinotree> youpi: what i thought would be creating a + glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and + _hurd_clock_{gettime,settime,getres} to it and making the current .c in + sysdeps call those + <youpi> yep + <youpi> that's unfortunate, but that's what nptl actually does + <pinotree> this way we could add inside hurdtime.c the mapped time stuff + too + <pinotree> most probably a noobish question, but why does rt link to + pthread? + <youpi> no idea :) + <youpi> possibly due to aio implementation + <youpi> ./sysdeps/pthread/aio_cancel.c + <youpi> probably due to that + <youpi> (and others) + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> pinotree: about librt vs libpthread, don't worry too much for now + <youpi> libpthread can lib against the already-installed librt + <youpi> it does work + <pinotree> youpi: wouldn't that cause a dependency loop? + <youpi> pinotree: what dependency loop? + <pinotree> youpi: librt wouldd link to pthread, no? + <youpi> and ? + <youpi> I don't think it's an issue that .so link with each other + <pinotree> it isn't? + <youpi> well, try + * pinotree never did that + <youpi> but I don't think it will pose problem + <youpi> well, perhaps initialization order + <youpi> anyway, I now have packages built, I'll test that + <youpi> pinotree: ok, it seems it doesn't work indeed :) + <youpi> early in initialization + <youpi> pinotree: the initialization bug might actually not be due to librt + at all + <youpi> pinotree: yes, things work even with -lrt + <pinotree> wow + + +## IRC, OFTC, #debian-hurd, 2012-06-04 + + <youpi> pinotree: -lrt in libpthread is what is breaking glib2.0 + <youpi> during ./configure it makes clock_gettime linked in, while at + library link it doesn't + <youpi> probably for obscure reasons + <youpi> I'll have to disable it in debian + + +### IRC, OFTC, #debian-hurd, 2012-06-05 + + <pinotree> youpi: i saw your message about the linking issues with + pthread/rt; do you want me to provide a patch to switch clock_gettime → + gettimeofday in libpthread? + <youpi> you mean switch it back as it was previously? + <pinotree> kind of, yes + <youpi> I have reverted the change in libc for now + <pinotree> ok + + +## IRC, freenode, #hurd, 2012-07-22 + + <tschwinge> pinotree, youpi: I once saw you discussing issue with librt + usage is libpthread -- is it this issue? http://sourceware.org/PR14304 + <youpi> tschwinge: (librt): no + <youpi> it's the converse + <pinotree> tschwinge: kind of + <youpi> unexpectedly loading libpthread is almost never a problem + <youpi> it's unexpectedly loading librt which was a problem for glib + <youpi> tschwinge: basically what happened with glib is that at configure + time, it could find clock_gettime without any -lrt, because of pulling + -lpthread, but at link time that wouldn't happen + + +## IRC, freenode, #hurd, 2012-07-23 + + <braunr> pinotree: oh, i see you changed __pthread_timedblock to use + clock_gettime + <braunr> i wonder if i should do the same in libthreads + <pinotree> yeah, i realized later it was a bad move + <braunr> ok + <braunr> i'll stick to gettimeofday for now + <pinotree> it'll be safe when implementing some private + __hurd_clock_get{time,res} in libc proper, making librt just forward to + it and adapting the gettimeofday to use it + + +## IRC, freenode, #hurd, 2012-10-22 + + <pinotree> youpi: apparently somebody in glibc land is indirectly solving + our "libpthread needs lirt which pulls libphtread" circular issue by + moving the clock_* functions to libc proper + <youpi> I've seen that yes :) + +[[!sourceware_PR 14304]], [[!sourceware_PR 14743]], [[!message-id +"CAH6eHdQRyTgkXE7k+UVpaObNTOZf7QF_fNoU-bqbMhfzXxXUDg@mail.gmail.com"]], commit +6e6249d0b461b952d0f544792372663feb6d792a (2012-10-24). diff --git a/open_issues/libpthread_addon.mdwn b/open_issues/libpthread_addon.mdwn new file mode 100644 index 00000000..26b24549 --- /dev/null +++ b/open_issues/libpthread_addon.mdwn @@ -0,0 +1,150 @@ +[[!meta copyright="Copyright © 2012 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 as glibc addon"]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +This page lists all the notes, issues, etc, only about compiling libpthread +as addon for glibc, *not* for general libpthread issues. + +# Building + +To build libpthread as glibc addon, copy libpthread inside the glibc tree, +and then tell glibc's configure to use it: + + $ cp /path/to/libpthread libpthread + $ ./configure [...] --enable-add-ons=[...],libpthread + +Currently, it is build like that in Debian since eglibc 2.13-31. + +# Issues and notes + +### `bits/` headers not used + +Recompiling glibc (e.g. on a Debian system) and running the +`check-local-headers` test, `check-local-headers.out` shows: + + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/pthread.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/thread-attr.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/mutex-attr.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/mutex.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/condition-attr.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/condition.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/rwlock-attr.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/rwlock.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/barrier-attr.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/barrier.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/thread-specific.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/once.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/cancelation.h + *** $(common-objpfx)elf/tst-thrlock.o: uses /usr/include/i386-gnu/bits/pthread-np.h + +This happens because these headers are in the `bits/` subdirectory in +`sysdeps/generic` -- a `generic` sysdep is used only for the top-level +`sysdeps` directory in glibc. + +### Use of hurd's libihash + +libpthread makes use of the ihash hurd library, as also glibc's +`check-local-headers` test shows: + + *** $(common-objpfx)libpthread/pt-alloc.o: uses /usr/include/hurd/ihash.h + +Possible alternatives: [[hurd/libihash]]. + +### Executable stack + +Running glibc's `check-execstack` test gives in `check-execstack.out`: + + $BUILDDIR/libpthread/libpthread.so.phdr: *** executable stack signaled + +### Extra PLT references + +Running glibc's `check-localplt` test gives in `check-localplt.out`: + + Extra PLT reference: libpthread.so: pthread_detach + Extra PLT reference: libpthread.so: pthread_mutex_lock + Extra PLT reference: libpthread.so: pthread_mutexattr_settype + Extra PLT reference: libpthread.so: pthread_rwlock_rdlock + Extra PLT reference: libpthread.so: _pthread_spin_lock + Extra PLT reference: libpthread.so: pthread_attr_setstacksize + Extra PLT reference: libpthread.so: pthread_attr_getstacksize + Extra PLT reference: libpthread.so: pthread_attr_getstackaddr + Extra PLT reference: libpthread.so: pthread_attr_setstackaddr + Extra PLT reference: libpthread.so: pthread_exit + Extra PLT reference: libpthread.so: pthread_getspecific + Extra PLT reference: libpthread.so: __mutex_lock_solid + Extra PLT reference: libpthread.so: pthread_mutex_unlock + Extra PLT reference: libpthread.so: pthread_setcanceltype + Extra PLT reference: libpthread.so: pthread_key_create + Extra PLT reference: libpthread.so: pthread_cond_wait + Extra PLT reference: libpthread.so: pthread_rwlock_wrlock + Extra PLT reference: libpthread.so: pthread_once + Extra PLT reference: libpthread.so: pthread_cond_broadcast + Extra PLT reference: libpthread.so: pthread_setspecific + Extra PLT reference: libpthread.so: __pthread_get_cleanup_stack + Extra PLT reference: libpthread.so: pthread_rwlock_unlock + Extra PLT reference: libpthread.so: pthread_create + Extra PLT reference: libpthread.so: pthread_mutex_init + Extra PLT reference: libpthread.so: pthread_mutexattr_init + Extra PLT reference: libpthread.so: __mutex_unlock_solid + Extra PLT reference: libpthread.so: pthread_mutexattr_destroy + Extra PLT reference: libpthread.so: pthread_setcancelstate + +### `pthread` sysdep + +glibc provides a `pthread` sysdep (`sysdeps/pthread`) with pthread-based +implementations of most of the `aio_*` and `lio_*` functions. + +[[!message-id "201209302353.51055.toscano.pino@tiscali.it"]] + +The above patches allows also to cleanly set the libpthread string version, +returned e.g. for the `_CS_GNU_LIBPTHREAD_VERSION` value of `confstr`. + +About the glibc aio tests, they would all compile and work, except: + + - `tst-aio` -- fails + - `tst-aio9`, `tst-aio10` -- time out + +### `bits/posix_opt.h` + +`bits/posix_opt.h` is the glibc header defining the various +supported/unsupported `_POSIX_*` defines (e.g. `_POSIX_THREADS`, etc). + +Currently, glibc's `sysdeps/mach/hurd/bits/posix_opt.h` is patched in Debian +to add all the defines advertizing thread-related support. +An idea to avoid this would be to follow what is done in NPTL, and do the +following: + + - in glibc: leave `sysdeps/mach/hurd/bits/posix_opt.h` with *no* +thread-related macros at all. + + - in libpthread: provide `sysdeps/mach/hurd/bits/posix_opt.h` which would +be a copy of glibc's `sysdeps/mach/hurd/bits/posix_opt.h` with also the thread +macros. + +This approach would have the drawback that changes in the glibc header must be +mirrored also in the libpthread version, but with the advantage that defines +according to supported features in libpthread can be added in libpthread's own +version (and glibc would pick it automatically). + +### Tests + +The (few) existing tests are not built (thus neither run) just like other tests +in glibc. + +### `gai_misc.h` + +A pthread version of `gai_misc.h` must be provided by libpthread (just like +NPTL provides one), either in `sysdeps/mach/hurd` or `sysdeps/pthread` +(better, see above). + +Currently, it is provided in glibc itself in Debian. 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_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..05a07ef2 --- /dev/null +++ b/open_issues/libpthread_dlopen.mdwn @@ -0,0 +1,129 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2010-01-24 + + <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed + libraries + <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs, + we're the only one with such configuration + <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it + be it does not set THREADLIBS in the configure.ac switch case? + <youpi> that's expected + <youpi> on linux the libc provides hooks itself, on hurd-i386 it's + pthread-stubs + <pinotree> why not explicitly link to pthread though? + <youpi> because there is no strict need to, for applications that don't + need libpthread + <youpi> the dlopen case is a tricky case that pthread-stubs had not thought + about + <pinotree> hm + <pinotree> what if the pthread stubs would be moved in our glibc? + <youpi> that's what we should do yes + <youpi> (ideally) + <youpi> but for this we need to build libpthread along glibc, to get it + really working + +[[Packaging_libpthread]]. + + <youpi> and that's the tricky part (Makefile & such) which hasn't been done + yet + <pinotree> why both (stubs + actual libpthread)? + <youpi> because you need the stubs to be able to call the actual libpthread + <youpi> as soon libpthread gets dlopened for instance + <youpi> +as + <pinotree> i see + <youpi> (remember that nptl does this if you want to see how) + <youpi> (it's the libc files in nptl/) + <youpi> (and forward.c) + <guillem> also if libpthreads gets integrated with glibc don't we need to + switch the hurd from cthreads then? Which has been the blocker all this + time AFAIR? + <youpi> we don't _need_ to + <guillem> ok + + +# IRC, OFTC, #debian-hurd, 2011-07-21 + + <youpi> there's one known issue with pthreads + <youpi> you can't dlopen() it + +... if the main application is not already linked against it. + + <youpi> which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + <youpi> (so as to get libpthread initialized early, not at the dlopen() + call) + <lucas> I get this while building simgrid: + <lucas> 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 + <lucas> 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 + <lucas> 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. + <lucas> Aborted (core dumped) + <youpi> that's it, yes + <youpi> (or at least it has the same symptoms) + <lucas> it would need fixing in lua, not in SG, then, right? + <youpi> yes + <lucas> ok, thanks + +The fix thus being: link the main application with -lpthread. + +IRC, freenode, #hurd, 2011-08-17 + + < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but + openjade itself is not liked against libpthread + < youpi> which means unexpectedly loading pthreads on the fly, which is + not implemented + < youpi> (and hard to implement of course) + < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread + < gnu_srs> Shuoldn't missing linking with pthread create an error when + building openjade then? + < youpi> no + < youpi> because it's just a module which needs pthread + < youpi> and that module _is_ linked with -lpthread + < youpi> and dlopen() loads libpthreads too due to that + < youpi> but that's unexpected, for the libpthread initialization stuff + < youpi> (and too late to fix initlaization) + < gnu_srs> How come that other OSes build opensp w/o problems? + < youpi> because there are stubs in the libc + < gnu_srs> Sorry for the delay: What hinders stubs to be present also in + the Hurd libc parts too, to cope with this problem? + < youpi> doing it + < youpi> which is hard because you need libpthread bits inside the libc + < youpi> making it simpler would need building libpthread at the same time + as libc + +[[packaging_libpthread]] + +--- + +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) + [...] + +openjade links against *both* libthreads and libpthread. The result is that libc +early-initializes libthreads only, and thus libpthread is not early-initialized, +and later on raises assertions. The solution is to just get rid of libthreads, +to have only one threading library. diff --git a/open_issues/libpthread_glibc_nptl_testsuite.mdwn b/open_issues/libpthread_glibc_nptl_testsuite.mdwn new file mode 100644 index 00000000..87204c9c --- /dev/null +++ b/open_issues/libpthread_glibc_nptl_testsuite.mdwn @@ -0,0 +1,26 @@ +[[!meta copyright="Copyright © 2012 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]] + +For fun and profit we should run [[glibc]]'s [[NPTL]] testsuite against +[[libpthread]]. + +Also, there are sometimes issues fixed in NPTL that libpthread should also be +checked against. Totally incomplete list: + + * `pthread_cancel` when single-threaded, glibc + 439bf404b8fa125cf950dc1aa37838702c5353ea, [[!sourceware_PR 13613]], + [[!message-id "20120509202437.268a72b9@spoyarek"]]. + * `__libc_stack_end`, glibc 9c6ea9facbba4d430807bd21fa82892d713b1ecd, + 18b5e737de22462ab6b3fc89f26c9ad480ebb843, [[!sourceware_PR 12416]], + [[!message-id "20120419120021.4780e8c8@spoyarek"]], [[!message-id + "20120615005913.4f517e02@spoyarek"]], [[!message-id + "4FE378DE.8050906@mentor.com"]]. 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/libpthread_timeout_dequeue.mdwn b/open_issues/libpthread_timeout_dequeue.mdwn new file mode 100644 index 00000000..5ebb2e11 --- /dev/null +++ b/open_issues/libpthread_timeout_dequeue.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2012 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, freenode, #hurd, 2012-08-17 + + <braunr> pthread_cond_timedwait and pthread_mutex_timedlock *can* produce + segfaults in our implementation + <braunr> if a timeout happens, but before the thread dequeues itself, + another tries to wake it, it will be dequeued twice + <braunr> this is the issue i spent a week on when working on fixing select + +[[select]] diff --git a/open_issues/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn new file mode 100644 index 00000000..6f135979 --- /dev/null +++ b/open_issues/libpthread_weak_symbols.mdwn @@ -0,0 +1,50 @@ +[[!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_glibc open_issue_libpthread]] + +IRC, unknown channel, unknown date. + + <youpi> btw, the issue with pthread_cancel is tricky + <youpi> I'm afraid there might be no fix + <youpi> clean fix, I mean + <pinotree> oh, hm + <pinotree> where it the problem located, actually? + <youpi> it's a lot more than just one place + <youpi> in some c++ header there is a weak reference to pthread_cancel + <youpi> libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well + <youpi> problem comes when also linking with a library which pulls libpthread + <youpi> oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel + <youpi> it couldn't implement it anyway + <youpi> and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread + <youpi> and can't find it + <youpi> I don't know how this translate to english, but we're “walking on eggs + <youpi> ” on this issue + <pinotree> i see + <youpi> i.e. we already know we're not respecting the ELF standard + <youpi> we need a feature that is not in the standard to make pthread symbols working + <youpi> the solution would be to integrate libpthread into the glibc + <pinotree> you mean in the sources, but still providing separate libc.so and libpthread.so? + <youpi> yes + <pinotree> would that be difficult/tricky? + <youpi> because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux + <youpi> problem is upstream, you know... + <youpi> if we put libpthread there, it'll be difficult for us to maintain it + <pinotree> ah, the friendly ulrich mate? + <youpi> we already have difficults to get almost trivial patches commited + <youpi> and the "yes I'll handle it someday" Roland mate + <youpi> Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment + <youpi> what we could do is to do it in Debian for the moment + <pinotree> yeah + <pinotree> iirc eglibc is maintained within git, isn't it? + <pinotree> maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that + <youpi> we're already moving to something like that, yes + <youpi> at least for all the other glibc patches we have + <youpi> maybe we'll just do that on sourceware actually diff --git a/open_issues/librpci.mdwn b/open_issues/librpci.mdwn new file mode 100644 index 00000000..a3af16b1 --- /dev/null +++ b/open_issues/librpci.mdwn @@ -0,0 +1,31 @@ +[[!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_hurd]] + +2004 to 2007, Anand Babu has been working some on this project. It is still in +rather early stages. It's meant to become an extension/complement to +[[hurd/debugging/rpctrace]]. + + * <https://savannah.nongnu.org/projects/rpci> + + > A C language library for interposing ports of a Hurd task running on top + > of GNU Mach micro-kernel. Using this library, it would be possible to + > implement a trace/replay system, RPC debugger, sandbox, etc. + + On top of that, a debugger was planned: + + > A RPC level debugger with useful command set to analyze/manipulate a task + > at run time. For example, the user will be able to set RPC break points, + > manipulate port rights and data, trace and replay a task. + +If there is interest, the existing source code could be moved from the CVS +repository into the [[source_repositories/incubator]] ([[tschwinge]] already +locally converted it to Git.) diff --git a/open_issues/libstore_parted.mdwn b/open_issues/libstore_parted.mdwn new file mode 100644 index 00000000..852c8fa8 --- /dev/null +++ b/open_issues/libstore_parted.mdwn @@ -0,0 +1,11 @@ +[[!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 redir=hurd/libstore/part]] diff --git a/open_issues/libtool.mdwn b/open_issues/libtool.mdwn new file mode 100644 index 00000000..7b2e0fe0 --- /dev/null +++ b/open_issues/libtool.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 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_porting]] + +# [[GCC]]: `libtool: finish`: `ldconfig` is not run for the Hurd. + +This probably comes from libtool's `libltdl/m4/libtool.m4` (or similar): +`finish_cmds`. + +There are a few other differences between `gnu` and `linux* | k*bsd*-gnu | +kopensolaris*-gnu`. diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn new file mode 100644 index 00000000..1d84d777 --- /dev/null +++ b/open_issues/linux_as_the_kernel.mdwn @@ -0,0 +1,237 @@ +[[!meta copyright="Copyright © 2012 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]]."]]"""]] + +Instead of attempting a [[history/port_to_another_microkernel]], or writing an +own one, an implementation of a Hurd system could use another existing +operating system/kernel, like [[UNIX]], for example, the Linux kernel. This is +not a [[microkernel]], but that is not an inherent hindrance; depending on what +the goals are. + +There has been an attempt for building a [[Mach_on_top_of_POSIX]]. + + +# IRC, freenode, #hurd, 2012-02-08 + +Richard's X-15 Mach re-implementation: + + <braunr> and in case you didn't notice, it's stalled + <braunr> actually i don't intend to work on it for the time being + <braunr> i'd rather do as neal suggested: take linux, strip it, and give it + a mach interface + <braunr> (if your goal really is to get something usable for real world + tasks) + <antrik> braunr: why would you want to strip down Linux? I think one of the + major benefits of building a Linux-Frankenmach would be the ability to + use standard Linux functionality alongside Hurd... + <braunr> we could have a linux x86_64 based mach replacement in "little" + time, with a compatible i386 interface for the hurd + <braunr> antrik: well, many of the vfs and network subsystems would be hard + to use + <antrik> BTW, one of the talks at FOSDEM was about the possibility of using + different kernels for Genode, and pariticularily focused on the + possibilities with using Linux... unfortunately, I wasn't able to follow + the whole talk; but they mentioned similar possibilities to what I'm + envisioning here :-) + + +## IRC, freenode, #hurd, 2012-03-28 + + <mel__> is there currently any work going on with respect to + Mach-alternatives? + <antrik> mel__: no + <antrik> we have other priorities to take care of :-) + <braunr> antrik: i still intend to try giving linux a "mach personality" :) + <braunr> antrik: but i don't have much time for development currently :( + <mel__> antrik: which means that the hope is that Mach can be turned into + something really well working (i.e. secure/scalable/etc.)? + <antrik> mel__: yes, that's the venue we are pursuing + <antrik> (and IMHO the right one... though the Linux layer mentioned by + braunr is also one of my favourite projects, that we should pursue *in + parallel* to the existing Mach-based implementation) + <mel__> what is this Linux Layer exactly? + <mel__> a Linux instance running on top of Mach in parallel to Hurd + serverS? + <braunr> mel__: not exactly + <braunr> mel__: it would involve adding a mach layer on top of linux + actually + <braunr> mel__: so that linux can be used as a mach kernel + <mel__> Ah! + <mel__> Running Hurd on top of Linux + <mel__> :-D + <mel__> Funny + <braunr> ironic, yes + <braunr> but very pragmatic + <mel__> and THEN + <antrik> yeah. I most like the name: Hurd Emulation Layer on + Linux... i.e. HELL :-) + <mel__> we use a device driver framework something so that we can use Linux + device drivers in Hurd! + <mel__> on top of Linux.... + <braunr> yes + <braunr> i guess a transition phase would include using in kernel drivers + directly for a while + <mel__> and somebody is working on that? + <antrik> mel__: well, for using Linux drivers we are persuing DDE, which + allows us doing that with Mach as well + <braunr> then grabbing them out of the kernel and into dde + <braunr> not yet + <antrik> (in fact we have been using Linux drivers since forever... they + just haven't been updated for ages) + <mel__> I would _guess_ that it is not that hard. + <braunr> it's not + <mel__> Basically one would need to implement the message passing interface + thing in linux I guess. + <braunr> and many exported kernel objects like tasks, threads, etc.. + <braunr> and implement all the RPCs normally implemented by the kernel + <braunr> but it's doable + <antrik> mel__: the IPC aspect is one part, but probably the less tricky + one. the external pager interface is really the crucial element + <mel__> uh + <mel__> yeah + <mel__> hooking into linux virtual memory stuff + <mel__> sounds delicate + <braunr> it's true that some interactions between the linux VM and file + systems (the linux equivalent of our pagers) is synchronous + <braunr> but i don't think it would be that hard considering the amount of + facilities available in linux + <braunr> it's just work, takes time, needs debugging, reviewing, testing, + etc.. + <lcc> hurd on top of linux. how would that work? + <braunr> 15:30 < braunr> antrik: i still intend to try giving linux a "mach + personality" :) + <braunr> lcc: 7 system calls and a few hundreds of RPCs on top, the + internal magic of course, and voila .. + <antrik> of course porting Mach still requires work + <mel__> that would then be GNU/Hurd/Linux + <mel__> :-) + <antrik> hehe + <braunr> eh + <antrik> braunr: BTW, are you more thinking of a userspace solution on top + of standard Linux mechanisms, or additions to Linux itself?... + <antrik> (we probably talked about it already, but I don't remember all the + details...) + <braunr> antrik: adding to linux + <antrik> do you think a pure userspace solution would be realistic at all? + (at the expense of some performance of course) + <mel__> it's probably comparable to the qemu vs. qemu/kvm thing + <antrik> yeah, I guess that pretty much sums it up... + <braunr> antrik: i don't know :/ + <antrik> OK + <lcc> how challenging is it to port mach? + <antrik> lcc: it requires good low-level knowledge of the platform in + question. having that, I guess it shouldn't be too hard to add the + necessary code in Mach... + <antrik> TBH I'm not sure how much knowledge of Mach internals is required + <braunr> the pmap module is the main thing to port + <antrik> braunr: well, sartakov seemed to have most trouble with the + scheduler when he attempted the ARM port... + <braunr> that's strange + <antrik> at least there was quite a long thread where he asked about how + task switching works in Mach + <braunr> ok + <braunr> that would be interesting + <braunr> i thought intereacting with the hardclock was enough + + +## IRC, freenode, #hurd, 2012-04-05 + + <braunr> antrik: don't you think HELL is worth a try for the GSoC btw ? + <antrik> braunr: definitely. I haven't managed to rework the project ideas + list at all this year... but it's something I wanted there for a long + time + + <youngrw> just out of curiousity, what is HELL ? + <antrik> Hurd Emulation Layer on Linux + <braunr> youngrw: it can be described in several ways + <braunr> youngrw: basically, it's a mach interface on top of linux + <youngrw> implementing I suppose both the IPC mechanism and memory + management interface? + <mel__> youngrw: basically that. more generally: implement everything in + order to let Hurd run on that layer. + <antrik> well, it's slightly more complicated in my view... it's basically + anything that allows running a Hurdish environment on top of + GNU/Linux. it might be simply an implementation/emulation of Mach + mechanisms; but it also *might* work on a slightly higher level... + <youngrw> antrik: how might HELL operate at the slighty higher level like + you describe? + <antrik> let's call it low-level HELL and high-level HELL ;-) + <antrik> (a more descriptive name would be hurdenv... but HELL is so much + more catchy :-) ) + <antrik> so, high-level HELL... basically, the idea would be not to emulate + the kernel facilities and run all the real Hurd servers; but instead to + use special servers implementing the Hurd interfaces, but on top of + standard Linux facilities + <antrik> hurdish programs could run in such an environment, as long as they + aren't too low-level + <antrik> I wonder whether generic RPC interfaces could be implemented with + some side channel tunneled though the ordinary Linux FS interfaces... + <antrik> so translators would be loaded as FUSE modules for example, but + could still present generic interfaces + <youngrw> That's actually pretty different from what I was expecting + <antrik> what were you expecting? + <youngrw> maybe something where the entire kernel interface is emulated by + a running user process, like a kind of virtual machine + <youngrw> I hope that makes sense--I may be using my words incorrectly. + <antrik> youngrw: that would be in the low-level HELL category + <youngrw> antrik: right; I had the misconception that the level was defined + by how it made use of the underlying linux system + <youngrw> and that different HELL designs would always implement the mach + interface + + +## IRC, freenode, #hurd, 2012-04-06 + + <braunr> antrik: i think we have diverging ideas about how to use linux for + the hurd + <braunr> antrik: what you seem to want are really emulation componants, + like e.g. ext2fs and pfinet actually using the linux implementation + <braunr> (correct me if i'm mistaken) + <braunr> whereas my project is to make linux behave as a mach clone + <antrik> braunr: as I said, I consider both variants -- either a high-level + HELL or a low-level HELL + <braunr> ok + <antrik> (or perhaps a mix of both) + <braunr> a mix would be best imho + <antrik> yeah, probably + <braunr> so we have the real hurd, the real mach interface, and a set of + native translators (e.g. ext2fs) along some emulating their functionality + using linux code (e.g. a hypothetical ext4fs) + <antrik> I don't think we would have emulation servers for individual Linux + filesystems. rather, a generic server interfacing with the Linux VFS + tree... + <braunr> ok + + <antrik> braunr: BTW, I think I mentioned a couple of years ago that the + most realistic route towards a modern Mach in my opinion would be taking + a modern BSD (or Linux), and redo what the original Mach developers did + -- i.e. add the Mach-specific features, and drop the unnecessary UNIX + stuff + <braunr> antrik: :) + <braunr> we had discussions about it some time ago yes + <antrik> later I realised that it's better *not* to drop the UNIX + interfaces, but rather to keep them in parallel :-) + <braunr> antrik: for what purpose ? + <braunr> (i can imagine a few, but i'd like to know your idea) + <antrik> for the purpose of HELL :-) + <braunr> well hell would be the implementation, but what do you keep these + unix interfaces for ? + <antrik> i.e. people being able to play around with a Hurd environment + while staying with their existing system + <braunr> yes, i see + <braunr> i was considering doing that for development, yes + <braunr> uml first, and then i realized i wouldn't need it :) + <braunr> then i remembed netbsd and its syscall emulation layer + <antrik> also we might leverage some "foreign" userspace infrastructure + that way, such as udev + <antrik> (in the case of Linux that is... not sure whether NetBSD has + something similar at all ;-) ) + <braunr> i'll have to check, it's been a long time since i've really used + it + <braunr> they must use a pure devfs instance now diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn new file mode 100644 index 00000000..a4311d3e --- /dev/null +++ b/open_issues/linux_vmsig.mdwn @@ -0,0 +1,29 @@ +[[!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="Linux: vmsig"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + + * *cooperating with the VM when memory pressure increases* + + * *notify user applications of virtual memory events via real-time signals* + +<http://www.cs.umass.edu/~emery/pubs/bookmarking-collector/>, and discussion at +<http://lambda-the-ultimate.org/node/2391> and +<http://marc.info/?t=113269321800003&r=1&w=2>. + +Found this via <http://lambda-the-ultimate.org/node/4094#comment-62100>, which +was linked from [LWN](http://lwn.net/Articles/409416/). + +From a quick glance, this sounds to [[me|tschwinge]] quite a bit like +mechanisms also found in (originating in?) Mach's +[[microkernel/mach/external_pager_mechanism]]. May be worth having a look at +it. diff --git a/open_issues/lisp_cross-compile.mdwn b/open_issues/lisp_cross-compile.mdwn new file mode 100644 index 00000000..c9100aec --- /dev/null +++ b/open_issues/lisp_cross-compile.mdwn @@ -0,0 +1,11 @@ +[[!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]]."]]"""]] + +flaviocruz-soc2008-lisp-branch: lisp stuff can't be cross-compiled. diff --git a/open_issues/llvm.mdwn b/open_issues/llvm.mdwn new file mode 100644 index 00000000..d0b7b91d --- /dev/null +++ b/open_issues/llvm.mdwn @@ -0,0 +1,17 @@ +[[!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_llvm open_issue_porting]] + +[LLVM](http://www.llvm.org/) needs a little bit of porting for being usable on +GNU/Hurd. + +Apparently this has already been done within Debian; +<http://anonscm.debian.org/viewvc/pkg-llvm/llvm/trunk/debian/patches/>. diff --git a/open_issues/locking_issues.mdwn b/open_issues/locking_issues.mdwn new file mode 100644 index 00000000..e15562bc --- /dev/null +++ b/open_issues/locking_issues.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_hurd]] + +There are locking issues in the Hurd's libraries. + +[[!toc]] + + +# Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/libdiskfs_locking feeds=no]] + + +# ext2fs Deadlock + +[[ext2fs_deadlock]]. + + +# Formal Verification + +Methods of [[formal_verification]] should be applied to get an understanding of +the behavior of the locking logic. There are tools for formal +verification/[[code_analysis]] that can likely help here. + +There is a [[!FF_project 278]][[!tag bounty]] on this task. diff --git a/open_issues/low_memory.mdwn b/open_issues/low_memory.mdwn new file mode 100644 index 00000000..22470c65 --- /dev/null +++ b/open_issues/low_memory.mdwn @@ -0,0 +1,113 @@ +[[!meta copyright="Copyright © 2012 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_glibc open_issue_hurd]] + +Issues relating to system behavior under memory pressure. + +[[!toc]] + + +# [[gnumach_page_cache_policy]] + + +# IRC, freenode, #hurd, 2012-07-08 + + <braunr> am i mistaken or is the default pager simply not vm privileged ? + <braunr> (which would explain the hangs when memory is very low) + <youpi> no idea + <youpi> but that's very possible + <youpi> we start it by hand from the init scripts + <braunr> actually, i see no way provided by mach to set that + <braunr> i'd assume it would set the property when a thread would register + itself as the default pager, but it doesn't + <braunr> i'll check at runtime and see if fixing helps + <youpi> thread_wire(host, thread, 1) ? + <youpi> ./hurd/mach-defpager/wiring.c: kr = + thread_wire(priv_host_port, + <braunr> no + <braunr> look in cprocs.c + <braunr> iir + <braunr> iirc + <braunr> iiuc, it sets a 1:1 kernel/user mapping + <youpi> ?? + <youpi> thread_wire, not cthread_wire + <braunr> ah + <braunr> right, i'm getting tired + <braunr> youpi: do you understand the comment in default_pager_thread() ? + <youpi> well, I'm not sure to know what external vs internal is + <braunr> i'm almost sure the default pager is blocked because of a relation + with an unprivlege thread + <braunr> +d + <braunr> when hangs happen, the pageout daemon is still running, waiting + for an event so he can continue + <braunr> it* + + <braunr> all right, our pageout stuff completely sucks + <braunr> when you think the system is hanged, it's actually not + <pinotree> and what's happening instead? + <braunr> instead, it seems it's in a very complex resursive state which + ends in the slab allocator not being able to allocate kernel map entries + <braunr> recursive* + <braunr> the pageout daemon, unable to continue, progressively slows + <braunr> in hope the default pager is able to service the pageout requests, + but it's not + <braunr> probably the most complicated deadlock i've seen :) + <braunr> luckily ! + <braunr> i've been playing with some tunables involved in waking up the + pageout daemon + <braunr> and got good results so far + <braunr> (although it's clearly not a proper solution) + <braunr> one thing the kernel lacks is a way to separate clean from dirty + pages + <braunr> this stupid kernel doesn't try to free clean pages first .. :) + <braunr> hm + <braunr> now i can see the system recover, but some applications are still + stuck :( + <braunr> (but don't worry, my tests are rather aggressive) + <braunr> what i mean by aggressive is several builds and various dd of a + few hundred MiB in parallel, on various file systems + <braunr> so far the file systems have been very resilient + <braunr> ok, let's try running the hurd with 64 MiB of RAM + <braunr> after some initial swapping, it runs smoothly :) + <braunr> uh ? + <braunr> ah no, i'm still doing my parallel builds + <braunr> although less + <braunr> gcc: internal compiler error: Resource lost (program as) + <braunr> arg + <braunr> lol + <braunr> the file system crashed under the compiler + <pinotree> too much memory required during linking? or ram+swap should have + been enough? + <braunr> there is a lot of swap, i doubt it + <braunr> the hurd is such a dumb and impressive system at the same time + <braunr> pinotree: what does this tell you ? + <braunr> git: hurdsig.c:948: post_signal: Unexpected error: (os/kern) + failure. + <pinotree> something samuel spots often during the builds of haskell + packages + +Probably also the *sigpost* case mentioned in [[!message-id +"87bol6aixd.fsf@schwinge.name"]]. + + <braunr> actually i should be asking jkoenig + <braunr> it seems the lack of memory has a strong impact on signal delivery + <braunr> which is bad + <antrik> braunr: I have a vague recollection of slpz also saying something + about missing dirty page tracking a while back... I might be confusing + stuff though + <braunr> pinotree: yes it happens often during links + <braunr> which makes sense + <pinotree> braunr: "happens often" == "hurdsig.c:948: post_signal: ..."? + <braunr> yes + <pinotree> if you can reproduce it often, what about debugging it? :P + <braunr> i mean, the few times i got it, it was often during a link :p + <braunr> i'd rather debug the pageout deadlock :( + <braunr> but it's hard diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn new file mode 100644 index 00000000..2cbf2302 --- /dev/null +++ b/open_issues/lsof.mdwn @@ -0,0 +1,13 @@ +[[!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]]."]]"""]] + +We don't have a `lsof` tool. Perhaps we could cook something with having a +look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]] +does, for example)? diff --git a/open_issues/ltrace.mdwn b/open_issues/ltrace.mdwn new file mode 100644 index 00000000..cf0df759 --- /dev/null +++ b/open_issues/ltrace.mdwn @@ -0,0 +1,19 @@ +[[!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_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> it'd be good to have ltrace eventually + <youpi> rpctrace has too many issues to be usable + <youpi> (and a lot of them are hard to fix iirc) + <youpi> ltrace traces library calls + <youpi> in principle it should just work at the dynamic linker stage, so should be portable diff --git a/open_issues/m4_vs_stack.mdwn b/open_issues/m4_vs_stack.mdwn new file mode 100644 index 00000000..c92cfb00 --- /dev/null +++ b/open_issues/m4_vs_stack.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009 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_porting]] + + m4 (1.4.13-1+hurd.2) unreleased; urgency=low + + * Drop stack overflow (checks/stackovf) check, test-c-stack and + test-c-stack2 checks, and /dev/null/ (test-open and test-fopen) checks. + + -- Samuel Thibault <samuel.thibault@ens-lyon.org> Tue, 18 Aug 2009 20:54:30 +0000 + + <youpi> that was a quick fix (as not having m4 makes autoconf uninstallable, which is quite a problem) + <youpi> there's probably something wrong in the stack management of the Hurd, I haven't investigated diff --git a/open_issues/mach-defpager_debugging.mdwn b/open_issues/mach-defpager_debugging.mdwn new file mode 100644 index 00000000..33e717d9 --- /dev/null +++ b/open_issues/mach-defpager_debugging.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2011, 2012 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_gdb]] + +IRC, freenode, #hurd, 2011-11-10: + + <mcsim> hello. Is there any way to debug mach-defpager? When I set + breakpoint to any function in it, pager never breaks. + +IRC, freenode, #hurd, 2011-11-11: + + <mcsim> hello. I've read that hde tried to debug defpager and wrote some + patches for debugging defpager, but I couldn't find them. Does anybody + know are these patches in public? diff --git a/open_issues/mach-defpager_malloc_hook.mdwn b/open_issues/mach-defpager_malloc_hook.mdwn new file mode 100644 index 00000000..2bbff75a --- /dev/null +++ b/open_issues/mach-defpager_malloc_hook.mdwn @@ -0,0 +1,14 @@ +[[!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_hurd]] + +*malloc hooks* are used in `[hurd]/mach-defpager/kalloc.c`. But their use is +deprecated (glibc 7d17596c198f11fa85cbcf9587443f262e63b616). diff --git a/open_issues/mach-defpager_swap.mdwn b/open_issues/mach-defpager_swap.mdwn new file mode 100644 index 00000000..7d3b001c --- /dev/null +++ b/open_issues/mach-defpager_swap.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2012 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]] + +[[!toc]] + + +# IRC, OFTC, #debian-hurd, 2012-06-16 + + <lifeng> I allocated a 5GB partition as swap, but hurd only found 1GB + <youpi> use 2GiB swaps only, >2Gib are not supported + <youpi> (and apparently it just truncates the size, to be investigated) diff --git a/open_issues/mach-defpager_vs_defpager.mdwn b/open_issues/mach-defpager_vs_defpager.mdwn new file mode 100644 index 00000000..f03bc67f --- /dev/null +++ b/open_issues/mach-defpager_vs_defpager.mdwn @@ -0,0 +1,33 @@ +[[!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 +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_hurd]] + +IRC, freenode, #hurd, end of May/beginning of June 2010 + + <cfhammar> whats the difference between mach-defpager and defpager? + <cfhammar> i'm guessing defpager is a hurdish version that uses libstore + but was never finished or something + <cfhammar> found an interesting thread about it: + http://mirror.libre.fm/hurd/list/msg01232.html + <slpz> antrik: an interesting thread, indeed :-) + <pochu> slpz: btw is mach-defpager linked statically but not called + mach-defpager.static on purpose? + <slpz> antrik: also, I can confirm that mach-defpager needs a complete + rewrite ;-) + <slpz> pochu: I think the original defpager was launched by serverboot + <slpz> pochu: that could be the reason to have it static, like ext2fs + <slpz> and since there's no need to execute it again during the normal + operation of the system, they probably decided to not create a + dynamically linked version + <slpz> (but I'm just guessing) + <slpz> of perhaps they wanted to prevent mach-defpager from the need of + reading libraries, since it's used when memory is really scarce (guessing + again) diff --git a/open_issues/mach_federations.mdwn b/open_issues/mach_federations.mdwn new file mode 100644 index 00000000..50c939c3 --- /dev/null +++ b/open_issues/mach_federations.mdwn @@ -0,0 +1,66 @@ +[[!meta copyright="Copyright © 2012 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, 2012-08-18 + + <braunr> well replacing parts of it is possible on the hurd, but for core + servers it's limited + <braunr> minix has features for that + <braunr> this was interesting too: + http://static.usenix.org/event/osdi08/tech/full_papers/david/david_html/ + <braunr> lcc: you'll always have some kind of dependency problems which are + hard to solve + <savask> braunr: One my friend asked me if it's possible to run different + parts of Hurd on different computers and make a cluster therefore. So, is + it, at least theoretically? + <braunr> savask: no + <savask> Okay, then I guessed a right answer. + <youpi> well, theorically it's possible, but it's not implemented + <braunr> well it's possible everywhere :p + <braunr> there are projects for that on linux + <braunr> but it requires serious changes in both the protocols and servers + <braunr> and it depends on the features you want (i assume here you want + e.g. process checkpointing so they can be migrated to other machines to + transparently balance loads) + <lcc> is it even theoretically possible to have a system in which core + servers can be modified while the system is running? hm... I will look + more into it. just curious. + <savask> lcc: Linux can be updated on the fly, without rebooting. + <braunr> lcc: to some degree, it is + <braunr> savask: the whole kernel is rebooted actually + <braunr> well not rebooted, but restarted + <braunr> there is a project that provides kernel updates through binary + patches + <braunr> ksplice + <savask> braunr: But it will look like everything continued running. + <braunr> as long as the new code expects the same data structures and other + implications, yes + <braunr> "Ksplice can handle many security updates but not changes to data + structures" + <braunr> obviously + <braunr> so it's good for small changes + <braunr> and ksplice is very specific, it's intended for security updates, + ad the primary users are telecommunication providers who don't want + downtime + <antrik> braunr: well, protocols and servers on Mach-based systems should + be ready for federations... although some Hurd protocols are not clean + for federations with heterogenous architectures, at least on homogenous + clusters it should actually work with only some extra bootstrapping code, + if the support existed in our Mach variant... + <braunr> antrik: why do you want the support in the kernel ? + <antrik> braunr: I didn't say I *want* federation support in the + kernel... in fact I agree with Shapiro that it's probably a bad idea. I + just said that it *should* actually work with the system design as it is + now :-) + <antrik> braunr: yes, I said that it wouldn't work on heterogenous + federations. if all machines use the same architecture it should work. diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn new file mode 100644 index 00000000..c14ce95a --- /dev/null +++ b/open_issues/mach_migrating_threads.mdwn @@ -0,0 +1,17 @@ +[[!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]] + +<http://www.brynosaurus.com/pub/os/thread-migrate.pdf> + + * [[microkernel/mach/memory_object/discussion]] + + * [[resource_management_problems]] diff --git a/open_issues/mach_on_top_of_posix.mdwn b/open_issues/mach_on_top_of_posix.mdwn new file mode 100644 index 00000000..a3e47685 --- /dev/null +++ b/open_issues/mach_on_top_of_posix.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2011, 2012 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="Mach on Top of POSIX"]] + +[[!tag open_issue_gnumach]] + +At the beginning of the 2000s, there was a *Mach on Top of POSIX* port started +by John Edwin Tobey. Status unknown. Ask [[tschwinge]] for the source code. + +See also [[implementing_hurd_on_top_of_another_system]]. diff --git a/open_issues/mach_shadow_objects.mdwn b/open_issues/mach_shadow_objects.mdwn new file mode 100644 index 00000000..0669041a --- /dev/null +++ b/open_issues/mach_shadow_objects.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2012 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]] + +See also [[gnumach_vm_map_entry_forward_merging]]. + + +# IRC, freenode, #hurd, 2012-11-16 + + <mcsim> hi. do I understand correct that following is true: vm_object_t a; + a->shadow->copy == a;? + <braunr> mcsim: not completely sure, but i'd say no + <braunr> but mach terminology isn't always firm, so possible + <braunr> mcsim: apparently you're right, although be careful that it may + not be the case *all* the time + <braunr> there may be inconsistent states diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn new file mode 100644 index 00000000..9abb7639 --- /dev/null +++ b/open_issues/mach_tasks_memory_usage.mdwn @@ -0,0 +1,147 @@ +[[!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-01-06 + + <antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but + the sum of all RSS is <300 MiB... what's the rest? + <braunr> kernel memory ? + <braunr> the zone allocator maybe + <braunr> or the page cache simply + <antrik> braunr: which page cache? AIUI, caches are implemented by the + individual filesystem servers -- in which case any memory used by them + should show up in RSS + <antrik> also, gnumach is listed among other tasks, so I'd assume the + kernel memery also to be accounted for + <braunr> antrik: no, the kernel maintains a page cache, very similar to + what is done in Linux, and almost the same as in FreeBSD + <braunr> the file system servers are just backing stores + <braunr> the RSS for the gnumach tasks only includes kernel memory + <braunr> I don't think the page cache is accounted for + <braunr> because it's not really kernel memory, it's a cache of user space + memory + <antrik> apparently my understanding of Mach paging is still (or again?) + rather incomplete :-( + <antrik> BTW, is there any way to find out how much anonymous memory a + process is using? the "virtual" includes discardable mappings, and is + thus not very helpful... + <antrik> (that applies to Linux as well though) + <braunr> can you provide an example of the output of vmstat please ? + <braunr> I don't have a Hurd VM near me + <antrik> olaf@alien:~$ vmstat + <antrik> pagesize: 4K + <antrik> size: 501M + <antrik> free: 6.39M + <antrik> active: 155M + <antrik> inactive: 310M + <antrik> wired: 29.4M + <antrik> zero filled: 15.3G + <antrik> reactivated: 708M + <antrik> pageins: 3.43G + <antrik> pageouts: 1.55G + <antrik> page faults: 26844574 + <antrik> cow faults: 3736174 + <antrik> memobj hit ratio: 92% + <antrik> swap size: 733M + <antrik> swap free: 432M + <antrik> interesting... closing a single screen window temporarily raises + the "free" value by almost 10 MB + <antrik> I guess bash is rather hungry nowadays ;-) + <braunr> antrik: I guess the only way is using pmap or looking into + /proc/<pid>/maps + <braunr> but it won't give you the amount of physical memory used by + anonymous mappings + <antrik> nah, I don't even want that... just like to know how much memory + (RAM+swap) a process is really using + <braunr> antrik: then the RSS field is what you want + <antrik> OTOH, anonymous doesn't include program code or other actively + used mappings... so not very useful either + <antrik> nah, RSS doesn't count anything that is in swap + <braunr> well + <braunr> don't you have a SWAP column ? + <braunr> hm + <braunr> i guess not + <braunr> antrik: why do you say it doesn't include other actively used + mappings ? + <braunr> antrik: and the inclusion of program code also depends on the + implementation of the ELF handler + <braunr> I don't know how the hurd does that, but some ELF loaders use + anonymous memory for the execution view + <antrik> well, if a program maps a data file, and regularily accesses parts + of the file, they won't occupy physical RAM all the time (and show up in + RSS), but they are not anonymous mappings. similar to program code + <braunr> then this anonymous memory is shared by all processes using that + code + <antrik> oh, interesting + <antrik> is it really a completely distinct mapping, rather than just COW? + <braunr> the first is + <braunr> others are COW + <antrik> so if a program loads 200 MB of libraries, they are all read in on + startup, and occupy RAM or swap subsequently, even if most of the code is + never actually run?... + <kilobug> library code should be backed by the library file on disk, not be + swap + <braunr> depends on the implementation + <braunr> I guess most use the file system backend + <braunr> but in the Hurd, ext2fs.static and ld.so.1 use anonymous memory + <braunr> (that's the case for another reason, still, I don't think the + report in top/ps clearly indicates that fact) + <kilobug> braunr: yeah for bootstrapping issues, makes sense + <braunr> it may also depends on the pic/pie options used when building + libraries + + +IRC, freenode, #hurd, 2011-07-24 + + < braunr> the panic is probably due to memory shortage + < braunr> so as antrik suggested, use more swap + < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory + usage + < antrik> that way we will know for sure whether it's related + < braunr> antrik: it's trickier than that + < braunr> it depends if the zones used are pageable + < antrik> braunr: well, if it's a zone map exhaustion, then the swap size + won't change anything?... + < braunr> antrik: in this case no, but if the zone is pageable and the + pager (backing anonymous memory) refuses to create memory because it + estimates it's full (all swap space is reserved), it will fail to + < braunr> too + < braunr> but i don't think there are much pageable zones in the kernel + < antrik> yes, but in that case we can see the exhaustion in vmstat :-) + < braunr> many* + < braunr> i'm not sure + < braunr> reserved swap space doesn't mean it's used + < braunr> that's one of the major changes in freebsd 4 or 5 i was + mentioning + < antrik> if it's reserved, it wouldn't show up as "free", would it?... + < braunr> (btw, it's also what makes anonymous memory merging so hard) + < braunr> yes it would + < braunr> well, it could, i'm not sure + < braunr> anonymous memory is considered as a file + < braunr> one big file filled with zeroes, which is the swap partition + < braunr> when you allocate pageable anonymous memory, a part of this + "file" is reserved + < braunr> but i don't know if the reported number if the reserved + (allocated) space, or used (actually containing data) + < braunr> is* + < braunr> i also suspect wired allocations can fail because of a full swap + (because the kernel is unable to make free pages) + < braunr> in this case vmstat will show it + < antrik> what does it matter whether there is data there or not? if it's + reserved, it's not free. if it behaves differently, I'd consider that a + serious bug + < braunr> maybe the original developers intended to monitor its actual + usage + < braunr> antrik: i've just checked how the free count gets updated, and it + looks like it is on both seqnos_memory_object_data_initialize and + seqnos_memory_object_data_write + < braunr> antrik: so i guess reserved memory is accounted for diff --git a/open_issues/mach_vm_pageout.mdwn b/open_issues/mach_vm_pageout.mdwn new file mode 100644 index 00000000..dac7fe28 --- /dev/null +++ b/open_issues/mach_vm_pageout.mdwn @@ -0,0 +1,19 @@ +[[!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-09-09 + + <slpz> It's amazing how broken some parts of Mach's VM are + <slpz> currently, it doesn't even keep track of the number of external + pages in the lists + <slpz> and vm_pageout_scan produces a hang if want_pages == FALSE (which + never is, because vm_page_external_count is always 0) diff --git a/open_issues/magic_translator_machtype.mdwn b/open_issues/magic_translator_machtype.mdwn new file mode 100644 index 00000000..1c62b762 --- /dev/null +++ b/open_issues/magic_translator_machtype.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2008, 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="/hurd/magic machtype"]] + +[[!tag open_issue_hurd open_issue_glibc]] + + tschwinge@clubber:~ $ settrans -ca machtype /hurd/magic machtype + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. + thomas@dirichlet:~ $ ssh clubber + Warning: Permanently added '[clubber.bddebian.com]:2251' (RSA) to the list of known hosts. + Last login: Tue Dec 30 08:52:58 2008 from dslb-084-057-196-016.pools.arcor-ip.net + tschwinge@clubber:~ $ cat machtype + Segmentation fault + tschwinge@clubber:~ $ l machtype + Segmentation fault + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. diff --git a/open_issues/memory_object_model_vs_block-level_cache.mdwn b/open_issues/memory_object_model_vs_block-level_cache.mdwn new file mode 100644 index 00000000..7da5dea4 --- /dev/null +++ b/open_issues/memory_object_model_vs_block-level_cache.mdwn @@ -0,0 +1,273 @@ +[[!meta copyright="Copyright © 2012 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 open_issue_hurd open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-02-14 + + <slpz> Open question: what do you think about dropping the memory object + model and implementing a simple block-level cache? + +[[microkernel/mach/memory_object]]. + + <kilobug> slpz: AFAIK the memory object has more purpose than just cache, + it's allow used for passing chunk of data between processes, handling + swap (which similar to cache, but still slightly different), ... + <slpz> kilobug: user processes usually make their way to data with POSIX + operations, so memory objects are only needed for mmap'ed files + <slpz> kilobug: and swap can be replaced for an in-kernel system or even + could still use the memory object + <braunr> slpz: memory objects are used for the page cache + <kilobug> slpz: translators (especially diskfs based) make heavy use of + memory objects, and if "user processes" use POSIX semantics, Hurd process + (translators, pagers, ...) shouldn't be bound to POSIX + <slpz> braunr: and page cache could be moved to a lower level, near to the + devices + <braunr> not likely + <braunr> well, it could, but then you'd still have the file system overhead + <slpz> kilobug: but the use of memory objects it's not compulsory, you can + easily write a fs translator without implementing memory objects at all + (except to mmap) + <braunr> a unified buffer/VM cache as all modern systems have is probably + the most efficient approach + <slpz> braunr: I agree. I want to look at *BSD/Linux vfs systems to seem + how much cache policy depends on the filesystem + <slpz> braunr: Are you aware of any good papers on this matter? + <braunr> netbsd UVM, the linux virtual memory system + <braunr> both a bit old bit still relevant + <slpz> braunr: Thanks. + <slpz> the problem in our case is that having FS and cache information at + different contexts (kernel vs. translator), I find hard to coordinate + them. + <slpz> that's why I though about a block-level cache that GNU Mach could + manage by itself + <slpz> I wonder how QNX deals with this + <braunr> the point of having a simple page cache is explicitely about not + caring if those pages are blocks or files or whatever + <braunr> the kernel (at least, mach) normally has all the accounting + information it needs to implement its cache policy + <braunr> file system translators shouldn't cache much + <braunr> the pager interface could be refined, but it looks ok to me as it + is + <slpz> Mach has the accounting info, but it's not able to purge the cache + without coordination with translators + <braunr> which is normal + <slpz> And this is a big problem when memory pressure increases, as it + doesn't know for sure when memory is going to be freed + <braunr> Mach flushes its cache when it decides to, and sends back dirty + pages if needed by the pager + <braunr> that's the case with every paging implementation + <braunr> the main difference is security with untrusted pagers + <braunr> but that's another issue + <slpz> but in a monolithic implementation, the kernel is able for force a + chunk of cache memory to be freed without hoping for other process to do + the job + <braunr> that's not true + <braunr> they're not process, they're threads, but the timing issue is the + same + <braunr> see pdflush on linux + <slpz> no, it isn't. + <braunr> when memory is scarce, threads that request memory can either wait + or immediately fail, and if they wait, they're usually woken by one of + the vm threads once flushing is done + <slpz> a kernel thread can access all the information in the kernel, and + synchronization is pretty easy. + <braunr> on mach, synchronization is done with messages, that's even easier + than shared kernel locks + <slpz> with processes in different spaces, resource coordination becomes + really difficult + <braunr> and what kind of info would an external pager need when simply + asked to take back its dirty pages + <braunr> what resources ? + <slpz> just take a look at the thread storm problem when GNU Mach needs to + clean a bunch of pages + <braunr> Mach is big enough to correctly account memory + <braunr> there can be thread storms on monolithic systems + <braunr> that's a Mach issue, not a microkernel issue + <braunr> that's why linux limits the number of pdflush thread instances + <slpz> Mach can account memory, but can't assure when be freed by any + means, in a lesser degree than a monolithic system + <braunr> again i disagree + <braunr> no system can guarantee when memory will be freed with paging + <slpz> a block level cache can, for most situations + <braunr> slpz: why ? + <braunr> slpz: or how i mean ? + <slpz> braunr: with a block-level page cache, GNU Mach should be able to + flush dirty pages directly to the underlaying device without all the + complexity and resource cost involved in a m_o_data_return message. It + can also throttle the rate at which pages are being cleaned, and do all + this while blocking new page allocations to deal with memory exhaustion + cases. + <slpz> braunr: in the current state, when cleaning dirty pages, GNU Mach + sends a bunch on m_o_data_return to the corresponding pagers, hoping they + will do their job as soon and as fast as possible. + <slpz> memory is not really freed, but transformed from page cache to + anonymous memory pertaining to the corresponding translator + <slpz> and GNU Mach never knows for sure when this memory is released, if + it ever is. + <slpz> not being able to flush dirty pages synchronously is a big problem + when you need to throttle memory usage + <slpz> and needing allocating more memory when you're trying to free (which + is the case for the m_o_data_return mechanism) makes the problem even + worse + <braunr> your idea of a block level cache means in kernel block drivers + <braunr> that's not the direction we're taking + <braunr> i agree flushing should be a synchronous process, which was one of + the proposed improvements in the thread migration papers + <braunr> (they didn't achieve it but thought about it for future works, so + that the thread at the origin of the fault would handle it itself) + <braunr> but it should be possible to have kernel threads similar to + pdflush and throttle flush requests too + <braunr> again, i really think it's a mach bug, and having a buffer cache + would be stepping backward + <braunr> the real design issue is allocating memory while trying to free + it, yes + <slpz> braunr: thread migration doesn't apply to asynchronous IPC, and the + entire paging mechanism is implemented this way + <slpz> in fact, trying to do a synchronous m_o_data_return will trigger a + deadlock for sure + <slpz> to achieve synchronous flushing with translators, the entire paging + model must be redesigned + <slpz> It's true that I'm not very confident of the viability of user space + drivers + <slpz> at least, not for every device + <slpz> I know this is against the current ideas for most ukernel designs, + but if we want to achieve real work functionality, I think some + sacrifices must be done. Or at least a reasonable compromise. + <braunr> slpz: thread migration for paging requests implies synchronous + RPC, we don't care much about the IPC layer there + <braunr> and it requires large changes of the VM code in addition, yes + <braunr> let's not talk about this, we don't have thread migration anyway + :p + <braunr> except the allocation-on-free-path issue, i really don't see how + the current pager interface or the page cache creates problems wrt + flushing .. + <braunr> monolithic systems also have that problem, with lower impacts + though, but still + <slpz> braunr: because as it doesn't know when memory is really freed, 1) + it just blindly sends a bunch of m_o_data_return to the pagers, usually + overloading them (causing thread storms), and 2) it can't properly + throttle new page requests to deal with resource exhaustion + <braunr> it does know when memory is really freed + <braunr> and yes, it blindly sends a bunch of requests, they can and should + be trottled + <slpz> but dirty pages freed become indistinguishable from common anonymous + chunks released, so it doesn't really know if page flushes are really + working or not (i.e. doesn't know how fast a device is processing write + requests) + <braunr> memory is freed when the pager deallocates it + <braunr> the speed of the operation is irrelevant + <braunr> no system can rely on disk speed to guarantee correct page flushes + <braunr> disk or anything else + <slpz> requests can't be throttled if Mach doesn't know when they are being + processed + <braunr> it can easily know it + <braunr> they are processed as soon as the request is sent from the kernel + <braunr> and processing is done when the pager acknowledges the end of the + flush + <braunr> memory backing the flushed pages should be released before + acknowleding that to avoid starting new requests too soon + <slpz> AFAIK pagers doesn't acknowledge the end of the flush + <braunr> well that's where the interface should be refined + <slpz> Mach just sends the m_o_data_return and continues on its own + <braunr> that's why flushing should be synrhconous + <braunr> are you sure about that however ? + <slpz> so the entire paging system needs a new design... :) + <slpz> pretty sure + <braunr> not a new design .. + <braunr> there is m_o_supply_completed, i don't see how difficult it would + be to add m_o_data_return_completed + <braunr> it's not a small change, but not a difficult one either + <braunr> i'm more worried about the allocation problem + <braunr> the default pager should probably be wired in memory + <braunr> maybe others + <slpz> let's suppose a case in which Mach needs to free memory due to an + increase in its pressure. vm_pageout_daemon starts running, clean pages + are freed easily, but for each dirty one a m_o_data_return in sent. 1) + when should this daemon stop sending m_o_data_return and start waiting + for m_o_data_return_completed? 2) what happens if the translator needs to + read new blocks to fulfill a write request (pretty common in ext2fs)? + <braunr> it should stop after an arbitrary limit is reached + <braunr> a reasonable one + <braunr> linux limits the number of pdflush threads for that reason as i + mentioned (to 8 iirc) + <braunr> the problem of reading blocks while flushing is what i'm worried + about too, hence the need to wire that code + <braunr> well, i'm nto sure it's needed + <braunr> again, a reasonable about of free memory should be reserved for + that at all times + <slpz> but the work for pdflush seems to be a lot easier, as it only deals + directly with block devices (if I understood it correctly, I just started + looking at it). + <braunr> i don't know how other systems compute that, but this is how they + seem to do as well + <braunr> no, i don't think so + <slpz> well, I'll try to invest a few days understanding how pdflush work, + to see if some ideas can be borrowed for Hurd + <braunr> iirc, freebsd has thresholds in percent for each part of its cache + (active, inactive, free, dirty) + <slpz> but I still think simple solutions work better, and using the memory + object for page cache is tremendously complex. + <braunr> the amount of free cache pages is generally sufficient to + guarantee much memory can be released at once if needed, without flushing + anything + <braunr> yes but that's the whole point of the Mach VM + <braunr> and its greatest advance .. + <slpz> what, memory objects? + <braunr> yes + <braunr> using physical memory as a cache for anything, not just block + buffers + <slpz> memory objects work great as a way to provide a shared image of + objects between processes, but as page cache they are an overkill (IMHO). + <slpz> or, at least, in the way we're using them + <braunr> probably + <braunr> http://lwn.net/Articles/326552/ + <braunr> this can help udnerstand the problems we may have without better + knowledge of the underlying devices, yes + <braunr> (e.g. not being able to send multiple requests to pagers that + don't share the same disk) + <braunr> slpz: actually i'm not sure it's that overkill + <braunr> the linux vm uses struct vm_file to represent memory objects iirc + <braunr> there are many links between that structure and some vfs related + subsystems + <braunr> when a system very actively uses the page cache, the kernel has to + maintain a lot of objects to accurately describe the cache content + <braunr> you could consider this overkill at first too + <braunr> the mach way of doing it just implies some ipc messages instead of + function calls, it's not that overkill for me + <braunr> the main problems are recursion (allocation while freeing, + handling page faults in order to handle flushes, that sort of things) + <braunr> struct file and struct address_space actually + <braunr> slpz: see struct address_space, it contains a set of function + pointers that can help understanding the linux pager interface + <braunr> they probably sufferred from similar caveats and worked around + them, adjusting that interface on the way + <slpz> but their strategy makes them able to treat the relationship between + the page cache and the block devices in a really simple way, almost as a + traditional storage cache. + <slpz> meanwhile on Mach+pager scenario, the relationship between a block + in a file and its underlying storage becomes really blurry + <slpz> this is a huge advantage when flusing out data, specially when + resources are scarce + <slpz> I think the idea of using abstract objects for page cache, loses a + bit the point that we just want to avoid accessing constantly to a slow + device + <slpz> and breaking the tight relationship between the device and its + cache, makes things a lot harder + <slpz> this also manifest itself when flushing clean pages, as things like + having an static maximum for cached memory objects + <slpz> we shouldn't care about the number of objects, we just need to + control the number of pages + <slpz> but as we need the pager to flush pages, we need to keep alive a lot + of control ports to them + <mcsim> slpz: When mo_data_return is called, once the memory manager no + longer needs supplied data, it should be deallocated using + vm_deallocate. So this way pagers acknowledges the end of flush. diff --git a/open_issues/metadata_caching.mdwn b/open_issues/metadata_caching.mdwn new file mode 100644 index 00000000..f7f4cb53 --- /dev/null +++ b/open_issues/metadata_caching.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011, 2012 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_hurd]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2012-07-08 + + <braunr> youpi: there is still quite a lot of I/O even for cached objects + <braunr> youpi: i strongly suspect these are for the metadata + <braunr> i.e. we don't have a "buffer cache", only a file cache + <braunr> (gnu is really not unix lol) + <youpi> doesn't ext2fs cache these? + <youpi> (as long as the corresponding object is cached + <youpi> ) + <braunr> i didn't look too much, but if it does, it does a bad job + <braunr> i would guess it does, but possibly only writethrough + <youpi> iirc it does writeback + <youpi> there's a sorta "node needs written" flag somewhere iirc + <braunr> but that's for the files, not the metadata + <youpi> I mean the metadata of the node + <braunr> then i have no idea what happens diff --git a/open_issues/mig_error_reply.mdwn b/open_issues/mig_error_reply.mdwn new file mode 100644 index 00000000..21a5b217 --- /dev/null +++ b/open_issues/mig_error_reply.mdwn @@ -0,0 +1,68 @@ +[[!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_mig]] + +\#hurd, freenode, 2010-05-19 + + <cfhammar> ugh, mig server stubs generated from *_reply.defs don't call the server functions when the reply is an error, since the message size is too small... + <cfhammar> term seems to get around it by turning of type checking + <cfhammar> s/of/off + <cfhammar> but streamio doesn't + <cfhammar> luckily the only other program that makes use of a *_reply.defs is crash, and crash_reply.defs' routines only return an error code so it isn't affected + <slpz> cfhammar: could you point me to a stub with that problem? + <cfhammar> slpz: trans/device_replyServer.c:_Xdevice_open_reply (in build dir) + <slpz> cfhammar: So, if I understand it correctly, the problem is that GNU Mach generated stub doesn't properly set the size of the message if there's an error in the function, thus the type checking in user generated stub discards the reply + <cfhammar> slpz: the size is correct, error messages contain just a return value + <cfhammar> slpz: it is the type checking that is at fault imho + <slpz> cfhammar: even when a server wants to return an error, the size of the message should be the same as the reply structure previously defined + <slpz> cfhammar: on the other hand, I can't understand why streamio is using device_open_request (async RPC) instead of device_open (sync RPC)... + <cfhammar> slpz: the server does not always know the proper size, e.g. when it doesn't understand the message + <slpz> cfhammar: what do you mean by "doesn't understand the message"? + <cfhammar> slpz: if it doesn't implement that interface or is the wrong type, etc. + <cfhammar> slpz: in that case the mig stub needs to send out a generic error reply + <cfhammar> slpz: i don't know why streamio uses it either + <slpz> cfhammar: OK, now I see your point. If the server answers with a generic error code (as MIG_*), device_open_reply will not be called, and device_open_request doesn't get an error. + <slpz> cfhammar: good catch :-) + <cfhammar> slpz: all errors are handled the same way, MIG_* is just an example of why it does so + <slpz> cfhammar: on an unrealted note, I think we should get rid of all asynchronous messages sent from the user to the kernel, since they aren't asynchronous except for sending the reply to a different port (the process is really done by the thread calling mach_msg) + <cfhammar> slpz: i'm not not all that familiar with the low-level parts of message passing so i can't really comment + <slpz> cfhammar: in that point I disagree. If the server function can understand the message (so there isn't a MIG_* error), it can send a reply message with the proper size + <cfhammar> slpz: it could, but what is the advantage if we still need to handle generic errors? + <cfhammar> slpz: "sending the reply to a different port", different from what? + <slpz> cfhammar: to differentiate between message marshalling errors and errors generated by the called function + <slpz> cfhammar: in a synchronous RPC, the same call to mach_msg will send the request and receive the reply by providing a mig generated reply port + <slpz> cfhammar: but in an asynchronous, the reply is received by a port previously generated by the function requesting the message + <cfhammar> slpz: ah, that's a clever optimization + <slpz> cfhammar: if the "asynchronous" message is sent to the kernel, the thread calling for mach_msg will execute the server's function, but the reply will be sent to one of these previously generated ports + <slpz> cfhammar: actually you have a synchronous operation replying to a different port. That doesn't make much sense to me :-) + <antrik> slpz: note that most kernel functions can be implemented by userspace servers, in which case they could be really async... + <cfhammar> slpz: not sure how differentiating mig errors from server errors is useful... + <slpz> antrik: define "most kernel functions" ;-) + <cfhammar> slpz: if nothing else kernel rpcs can be proxied, e.g. rpctrace + <slpz> cfhammar: well, think of device_open_request. If the result is not a mig error, you can still device_open_reply an expect it to properly process the return code from the message + <cfhammar> slpz: it should be able to handle all kinds of errors anyway, the result should be the same as with syncronous rpcs + <slpz> cfhammar: yes, you're right. User generated stub should be able to fill the reply with the error code and call to the reply function. + <slpz> cfhammar: Then someone needs to introduce some changes in MiG's magic... + <cfhammar> slpz: yes, a flag to generate reply side of an interface would be ideal + <cfhammar> slpz: then we could toss out *_reply.defs altogether + <slpz> cfhammar: well, that's a different change from what I was thinking + <cfhammar> slpz: how would you change it? + <slpz> cfhammar: just generating stubs which, in case of error, will properly call to the reply function with the error code in its arguments + <cfhammar> slpz: ah yes, i considered that as well, but i don't think mig can actually distinguish the error code from any other int argument + <cfhammar> slpz: i should double check it though + <slpz> cfhammar: I tag can be used to point to argument of this nature + <slpz> cfhammar: s/I/A/ + <cfhammar> slpz: oh, it already is tagged with retcode, intresting + <slpz> cfhammar: OMG, I'm thinking like MiG! ;-P + <cfhammar> slpz: is that a good or bad ; + <cfhammar> slpz: ;-) + <slpz> cfhammar: I don't know, but it's somewhat scary ;-) + <cfhammar> slpz: apparently retcode is only there for comatibility, mig just ignores it... diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn new file mode 100644 index 00000000..084d7454 --- /dev/null +++ b/open_issues/mig_portable_rpc_declarations.mdwn @@ -0,0 +1,58 @@ +[[!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_mig]] + + +# IRC, freenode, #hurd, 2011-11-14 + + <braunr> also, what's the best way to deal with types such as + <braunr> type cache_info_t = struct[23] of integer_t; + <braunr> whereas cache_info_t contains longs, which are obviously not + integer-wide on 64-bits processors + <braunr> ? + <youpi> you mean, to port mach to 64bit? + <braunr> no, to make the RPC declaration portable + <braunr> just in case :) + <youpi> refine integer_t into something more precise + <youpi> such as size_t, off_t, etc. + <braunr> i can't use a single line then + <braunr> struct cache_info contains ints, vm_size_t, longs + <braunr> should i just use the maximum size it can get ? + <braunr> or declare two sizes depending on the word size ? + <youpi> well, I'd say three + <braunr> youpi: three ? + <youpi> the ints, the vm_size_ts, and the longs + <braunr> youpi: i don't get it + <braunr> youpi: how would i write it in mig language ? + <youpi> I don't know the mig language + <braunr> me neither :) + <youpi> but I'd say don't lie + <braunr> i just see struct[23] of smething + <braunr> the original zone_info struct includes both integer_t and + vm_size_t, and declares it as + <braunr> type zone_info_t = struct[9] of integer_t; + <braunr> in its mig defs file + <braunr> i don't have a good example to reuse + <youpi> which is lying + <braunr> yes + <braunr> which is why i was wondering if mach architects themselves + actually solved that problem :) + <braunr> "There is no way to specify the fields of a + <braunr> C structure to MIG. The size and type-desc are just used to + give the size of + <braunr> the structure. + <braunr> " + <braunr> well, this sucks :/ + <braunr> well, i'll do what the rest of the code seems to do, and let it + rot until a viable solution is available + <antrik> braunr: we discussed the problem of expressing structs with MIG in + the libburn thread + <antrik> (which I still need to follow up on... [sigh]) diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn new file mode 100644 index 00000000..b32d6ba6 --- /dev/null +++ b/open_issues/mission_statement.mdwn @@ -0,0 +1,699 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +[[!toc]] + + +# 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 + + +# IRC, freenode, #hurd, 2011-11-25 + + <antrik> heh, nice: http://telepathy.freedesktop.org/wiki/Rationale + <antrik> most of this could be read as a rationale for the Hurd just as + well ;-) + + +# IRC, freenode, #hurd, 2012-04-06 + + <braunr> LibreMan: the real feature of the hurd is its extensibility + +[[/Extensibility]], [[/advantages]]. + + <braunr> LibreMan: (though it could be improved even further) + <LibreMan> braunr: yeah, I keep reading that ... but that sounds too + abstract, I can not imagine what useful could that provide to the actual + users + <braunr> LibreMan: say fuse, but improved + <braunr> LibreMan: do you see how useful fuse is ? + <braunr> if so, you shouldn't have trouble imagining the gap between linux + without fuse and linux with fuse is about the same as linux with fuse and + the hurd + <braunr> and yes, it's abstract + <braunr> translators are not only about file systems + <LibreMan> braunr: well, its main advantage is that it's running in + user-space and therefore doesn't need root priviledges to mount whatever + fs you want? + <braunr> no + <braunr> you don't need to change the kernel, or implement weird tricks to + get what you want working + <LibreMan> braunr: okay, but there is fuse for Linux ... so the + difference/advantages need to be between Linux WITH fuse and Hurd + <braunr> that's what i'm saying + <LibreMan> the issue I have is that I do not see why anyone would have any + incentive to switch to Hurd + <braunr> there isn't much, which is why we stick with unix instead of, + e.g. plan9 or other advanced systems + <pinotree> try to use fuse on a server where there is no fuse installed + <LibreMan> if I want fuse-like functionallity I just install FUSE, no need + for Hurd ... so the reson to use it is not there + <braunr> LibreMan: read what i wrote + <braunr> using the hurd compared to using linux with fuse is about the same + as using linux with fuse compared to using linux without fuse + <LibreMan> braunr: ah, sorry ... I see + <braunr> it's a step further + <braunr> in theory, developers can add/remove the components they want, + making system development faster and more reliable + <braunr> where with unix, you need stuff like user mode linux or a virtual + machine + <LibreMan> braunr: but in practice it was the opposite so far :) + <braunr> not really + <braunr> it's a lack of manpower + <braunr> not a problem of partice versus theory + <braunr> practice* + <LibreMan> braunr: what do you think are the reasons why Hurd developement + is so slow if it should be faster in theory? + +[[faq/how_many_developers]]. + + <braunr> 17:30 < braunr> it's a lack of manpower + <braunr> pay someone to do the job + <braunr> :p + <LibreMan> braunr: then why does Linux get the manpower but Hurd doesn't? + <braunr> $$ + <LibreMan> braunr: ?? + <braunr> linux developers are paid + <LibreMan> because companies are using it :) + <braunr> yes + <LibreMan> why are they not using Hurd then? + <braunr> because it wasn't reliable enough + <LibreMan> Linux wasn't either at some point + <braunr> sure + <braunr> but when it became, the switch towards its use began + <braunr> now that they have something free and already working, there is no + point switching again + <LibreMan> paid devs join only AFTER volunteers got it to the stage that it + was useful to companies + <braunr> well linux was easier to develop at the beginning (and is still + today because of several kernel hacking features) + <braunr> it followed the traditional unix model, nothing was really new + about it + <LibreMan> braunr: exactly! that's why I think that Hurd needs to have very + compelling technical advantages to overcome that barrier + <braunr> few people/companies really care about such technical advantages + <braunr> they don't care if there are ugly tricks to overcome some problems + <LibreMan> you mean about such that Hurd can provide, right? + <braunr> it's not elegant, but most of the time they're not even aware of + it + <braunr> yes + <LibreMan> that's eaxctly my point ... most people do not care if it's + "elegant" from a programmers POV, they care whether it WORKS + <braunr> well yes + <braunr> what's your point ? + <LibreMan> all I see about Hurd is how "elegant" it is ... but that doesn't + matter if it doesn't provide any practical advantages + <braunr> you want us to expose a killer feature amazing enough to make the + world use our code ? + <LibreMan> well, I want Hurd to succeed and try to identify the resons it + doesn't + <braunr> it does, but not to the point of making people use it + <braunr> unix *is* good enough + <braunr> same reason plan9 "failed" really + <LibreMan> define your idea of Hurd succeeding then, I thought it was to + make it useful to the point that people use it :) + <braunr> there are many other attempts to make better system architectures + <braunr> it is + <braunr> people are still using windows you know, and i really don't see + why, but it does the work for them + <LibreMan> <braunr> you want us to expose a killer feature amazing enough + to make the world use our code ? --- YES ;) + <braunr> other people can think about the same between unix and the hurd + <braunr> LibreMan: well too bad, there is none, because, again, unix isn't + that bad + <braunr> it doesn't prevent us from making a better system that is usable + <LibreMan> to explain my take on this - there are two kind of people, those + who care about philosophy behind software (and its consequences, FSF + etc.) and those who don't + <LibreMan> it's the job of those who do care to make the sw so good that + those who do not care switch to it = victory :) + <LibreMan> as I said the reasons I want Hurd to succeed are more + "political" than technical ... I do not know how many Hurd devs agree + with that kind of sentiment but I'd rather want a GNU project to be in + the forefront than that of a "benevolent dictator" that doesnt' really + care about user freedom + <LibreMan> from thechnical POV I agree that Linux isn't that bad ... it's + quite good, it's the "behind the scenes" stuff I do not like about it + <LibreMan> I'm kind of confused right now ... what exactly is to point of + Hurd then? I thought it was to make it good enough or better than Linux + so users start using it (privatly or corporate) + <LibreMan> is this just a research project that isn't intended to be used + by "general population"? + <braunr> LibreMan: it's an operating system project + <braunr> some people try to make it as good as it can be, but it's not easy + <braunr> it's not a pet or research only system + <LibreMan> braunr: I see what it is ... I'm struggling to see what is the + point of it being an "OS project", what's its intended purpose + <braunr> but it doesn't suit all the needs for a general OS yet + <braunr> LibreMan: a general purpose OS like most free unices + <LibreMan> what are the motivations behind making it as good as it can be + <braunr> for us developers ? + <LibreMan> yes + <braunr> for me, the architecture + <LibreMan> whe you say that linux is goos enough then what's the point? + <braunr> we can do better + <LibreMan> for you it's just a hobby that doesn't have any real goal except + challenging yourself to do it? + <braunr> because of lack of time, you could say that + <LibreMan> so you want Hurd to challenge Linux one day, right? + <braunr> challenging isn't the point + <braunr> i'd like to be able to use it for my needs + <LibreMan> well, that wasn't the right choise of word but to be better than + Linux + <braunr> again, you miss the point + <braunr> i don't care much about hurd vs linux + <LibreMan> your own needs, so you do not want others to use it? + <braunr> i care about the hurd and what i do + <braunr> others would think the same + <braunr> they would want it to work for their needs + <LibreMan> I'm asking about you, do YOU want others to use it? is that one + of your goals? + <braunr> not really + <braunr> i let them do what they want + <LibreMan> ah I see, so it is kind of a hobby project for you - you're + doing to for yourself and your own needs + <LibreMan> and don't care if anyone else uses it or not + <braunr> yes, i don't care much about the politics around such projects tb + <braunr> tbh + <LibreMan> is this kind of sentiment prevalent is the Hurd dev community? + <braunr> i don't work on software to break any benevolent dictator or + anyone in particular + <braunr> i don't know + <braunr> i'd say so, yes + <braunr> but not sure + <braunr> i'm not saying they don't care about freedom, don't get me wrong + <braunr> i'd say we sure prefer free software over open source + <braunr> but i don't think people work on the hurd specifically for these + reasons, rather than the technical ones + <LibreMan> interesting ... from the presentation of the project by + outsiders I got the impression that it is significantly about freedom, + GNU - that those are the main drivers + <braunr> if it really was so, we would have grabbed a bsd variant, + relicenced it with GPLv3, and call it FreeGNU or NetGNU + <LibreMan> and that's how I approached the project ... maybe I was wrong, + I'm kind of disappointed if that's so :) I care about those things a + great deal, in fact that's the only reason I care about Hurd really + + <lcc> the hurd is designed to offer more freedom, in various ways, to the + user. freedom from the admin. + <lcc> right? + <braunr> lcc: that's embedded in the term "extensibility", yes + <braunr> lcc: but there are technical solutions for that on other systems + as well now + + <antrik> as for the Hurd, people who said they are interested in it only + because of freedom aspects *never* contributed anything significant + <antrik> *all* serious contributors are motivated at least equally by the + technical merits; often more + <antrik> (though the fact that it's a GNU project is what has brought many + developers here in the first place...) + <LibreMan> antrik: I would phrase it the other way - why do people who have + contributed significantly not care about freedom that much? or ... how do + you know they don't? + <antrik> most of us *do* care about freedem. but it's not our primary + motivation. the freedom aspects are just not strong enough to motivate + anyone alone + <antrik> as braunr already pointed out, if the sole purpose was creating a + GNU kernel, there would be *much* more promising venues for that + <LibreMan> I do not think so ... if you someone where to just take BSD and + rebrand it as AWSOMEnewGNUkernel it wouldn't be looked upon too favorably + <LibreMan> there is an honor aspect to it, to have something developed by + the community that stands by it + <LibreMan> so I do not think it would work + <antrik> BSD has forked countless times, and several of these forks became + very popular. I don't see why a GNU one shouldn't do well enough + <antrik> bat that's beside the point. writing a new boring monolithic + UNIX-like kernel from scratch is not that hard + <antrik> (as Linus has proven, amonst others...) + <antrik> if the sole purpose would be having a GNU kernel, I'd be strongly + advocating writing a new monolithic kernel from scratch + <LibreMan> antrik: ah, snap! not that hard you say? with all the features + Linux has? sure, it's not hard to make a kernel that barely boots but + that's not the point, is it? :) + <antrik> (yes, even now, with the Hurd being almost usable, I still think + it would be easier to get a new monolithic kernel to production quality) + <LibreMan> antrik: and here is was braunr who was pitching extensibility + and faster developement of Hurd as its advantage - and here you come + saying that it would be easier to write monolithic kernel from scratch + <LibreMan> get your story striaght guys ;) + <antrik> the Hurd makes it easier to develop new features. it's not easier + to get it production-ready in the first place + <LibreMan> antrik: what's the difference of developing a feature that makes + it "production ready" and another one that make it "production ready" for + a different use? + <antrik> features don't make a system production ready + <LibreMan> what makes a system production ready? + <LibreMan> what do you consider a "production"? + <antrik> supporting enough use cases that a non-trivial number of users + have their needs covered; and being stable enough that it's not annoying + to use + <LibreMan> either it is easier to develop or it isn't ... either it is + modular from it's core or it isn't + <antrik> well, not only stable enough, but also performant, secure etc. + <antrik> wrong + <LibreMan> are you saying that the fruits of its modularity will show only + after enough modules have been written? + <antrik> a modular system with strong isolation is inherently more + complicated to get right + <LibreMan> that sure is a weird argument to make ... + <LibreMan> right ... but when you get it right, the further development is + much easier? + <antrik> depends. making fundamental changes to how the system works will + always be tricky. but adding new stuff that doesn't require fundamental + changes, building on the existing foundations, is way easier + <antrik> we believe that once we have the fundamentals mostly right, most + things people will be adding will fall into the latter catogory + <antrik> category + <LibreMan> o what's missing to Hurd before it "got it right" and the fast + pace development kicks in? + <antrik> but so far most of the work is in the former category, meaning + progress is slow + <LibreMan> because from readin the site it seems the core is pretty much + done ... what it needs are all the translators, drivers, user-space tools + to make use of that core - is that impression wrong? + <antrik> you are missing the point. there is no unified "development pace" + measurement. it is easier to add certain things right now. but to get the + system production ready, it still requires considerable work on the hard + parts + <antrik> well, it's not as simple ;-) + <LibreMan> are you sure the work on "the hard parts" is ever going to be + done? :) + <antrik> the core is working, but it is still missing some features, and + it's missing lots of performance optimisation and bug fixing + <LibreMan> it seems more hard parts pop up every time you think it is + almost production ready + <antrik> also, we know today that the core could work much better in some + regards if we make some major changes. not a priority right now, but + something that will have to be addressed in the long run to seriously + compete with other systems + <antrik> well, no software is ever done :-) + <antrik> but I hope we will get to a point where the hard parts work well + enough for most people + <LibreMan> in fact I remember the design of Hurd was specifically chose by + RMS because he thought it would be easier to implement modular system - + that was 20 yeras ago? :) + <antrik> yes, and he admitted later that he was totally wrong on that :-) + <LibreMan> yeah, that was one unlucky choice for GNU ... + <antrik> who knows. it's hard to estimate what would have happened it GNU + chose a different route back then + <LibreMan> so ... Hurd is a hobby project for you too? + <LibreMan> or ... what do you hope to achieve by working on Hurd? + <LibreMan> I'm really interested in the motivations of people behind Hurd + as I'm kind of surprised it's not that much freedom and GNU ... + <antrik> it's a hobby project for everyone -- nobody gets paid for working + on it + <antrik> in the long run, I hope the Hurd to be a good platform for my + higher-level ideas. I have a vision of a desktop environment working + quite differently from what exists today; and I believe the extensible + architecture of the Hurd makes it easier to implement these ideas + <LibreMan> that's not what I meant as you may have guessed from my line of + reasoning so far + <LibreMan> yeah, that's my definition of a hobby project :) not whether one + gets payed to do it or not but whether one does it to satisfy their own + curiosity + <antrik> well, curiosity is clearly too narrow + <LibreMan> as far as I'm concerned I'd have a more "political" goal of + influencing the wider world to move toward more freedom + <antrik> but hackers never work on volunteer projects except to scratch + their own itch, or to work on something they are genuinely interested + in. nobody hacks free software just to save the world + <LibreMan> I find some technical aspects very interesting and fun but if + they wouldn't further the goal of more freedom they'd be without purpose + to me + <antrik> just think of the GNU high priority projects list -- it has zery + effect + <antrik> zero + <LibreMan> yeah ... and I think that is a real shame + <LibreMan> I keep thinking that it's because most hackers do not realize + the importance of freedom and the consequences of not having it + <antrik> it's a shame that some people at the FSF seem to believe they can + tell hackers what to work on :-P + <LibreMan> I do not think anybody at FSF actually believes that + <LibreMan> they believe as I do that we can persuade hackers to work on + things after they themselves recognise the significance of it + <antrik> no. there are many many hackers who genuinely believe in + supporting software freedom (both in the Hurd and in other GNU projects) + -- but there are none who would work on projects they are not personally + interested in because of that + <LibreMan> well, how does one become "personally interested" in a project? + surely it's not something you;re born with ... after recognising a + significance of some project some may become personally interested in it + - and that's the point ;) + <antrik> well, if I you mean nobody realises that software freedom is so + important they should work on it instead of doing things they actually + enjoy... they yes, I guess you are right :-P + <antrik> significance is subjective. just because something may be + important to the general public, doesn't mean I personally care about it + <LibreMan> you keep projecting your own concerns into it + <LibreMan> just because you're not interested in something doesn't mean + someone else isn't + <LibreMan> you approach it from the POV that omebody is telling YOU what + you should do ... + <LibreMan> that is not the case + <antrik> LibreMan: well, but there are obviously things no hackers care + about -- or otherwise there would be no need for the high priority + projects list... it's a list of things that would be important for + software freedom, but nobody is interested in working on. and having a + list of them won't change that fact + <LibreMan> antrik: why do you feel entitled to speak for all hackers? the + projects are high priority exactly because there isn;t enough people + working on them, if they were they wouldn't be high priority :) + <LibreMan> so maybe you have cause and effect mixed up ... + <LibreMan> there is no need to list office suite as hight priority because + there is LibreOffice, if there wasn't I'm sure it would be right there on + the priority list + <antrik> LibreMan: err... how is that different from what I said? + <antrik> these projects are there because there are not enough people + working on them -- i.e. hackers are not interested in them + <LibreMan> you said it in a way the implied that hackers are not interested + in working on projects that are required for providing freedom - but + mostly there are, it's just a few project where aren't - and those are + listed as high priority to bring attention to them + <LibreMan> well, maybe after seeing them on a high priority list some + hackes become interested in them - that is the point :) + <antrik> yes, that's what I implied. the fact that there are projects + hackers aren't working on, although they would be important for software + freedom, proves that this is not sufficient motivation for volunteers + <antrik> if software freedom alone would motivate hackers, there would be + enough people working on important projects + <LibreMan> who ever claimed that freedom alone motivated hackers? :) + <antrik> but there aren't. we have the list, and people are *still* not + working on these projects -- q.e.d. + <LibreMan> I do not get what you're trying to prove + <antrik> the track record so far clearly shows that hackers do *not* become + interested in working on these projects just because they are on the list + <antrik> err... you pretty much claimed that Hurd hackers should be + motivated by freedom alone + <antrik> and expressed great disappointment that we aren't + <braunr> LibreMan: you expected the hurd developers to share the common + goal of freedom mainly, and now you're saying you don't think hackers + would work for freedom alone ? + <LibreMan> freedom mainly == freedom alone? + <braunr> antrik: would you see an objection to using netbsd as a code base + for a mach clone ? + <braunr> LibreMan: you said share the common goal of freedom + <LibreMan> you're twisting my word to suit your own line of reasoning + <braunr> implying we all agree this is the priority + <LibreMan> being a priority doesn't mean it is there "alone", does it? + <braunr> it means it's the only one + <LibreMan> in another words, do you reject the possibility of enjoying + working on a project and doing it for freedom? because it seems you + somehow do not allow for that possibility + <braunr> if we agree on it, we can't have multiple priorities per people + <braunr> yes, that's what we're saying + <braunr> freedom isn't a goal + <braunr> it's a constraint + <braunr> the project *has* to be free + <LibreMan> so if you;re doing something to achieve freedom you can not BY + DEFINITION enjoy it? :D + <braunr> LibreMan: more or less, yes + <braunr> i enjoy the technical aspect, i advocate freedom + <LibreMan> then I've just disproven you :) I do things for freedom and + enjoy them + <braunr> no, not for freedom + <LibreMan> yes, for freedom + <braunr> i'm telling you it's not what motivates me to write code + <LibreMan> if I did not believe in freedom I wouldn't do them + <LibreMan> and I'm not talking about you + <braunr> i believe in freedom, my job consists of developing mostly + proprietary software + <braunr> how can you disprove me if you're not talking about me on this ? + <LibreMan> you said it's not possible IN PRINCIPLE, well antrik did and you + agreed - if you did not follow his line of argument then do not try to + continue where he left off ;) + <braunr> what project have you worked on ? + <LibreMan> my personal ones, nothing big + <braunr> so you're not a hacker, you're excluded from the group considered + <LibreMan> I'll tell you when it cathes on :) + <braunr> (bam) + <LibreMan> so now you decide who is and is not a hacker, well ... :) + <braunr> :) + <LibreMan> but ok, let's not talk about me I concede that I'm a lousy one + if any :) + <LibreMan> what about RMS, do you consider him a hacker? + <braunr> i think he became a hacker for other reasons than freedom + <LibreMan> would you say he is not motivated by freedom (if that can be + even concieved of)? :) + <braunr> and sees freedom as necessary too + <braunr> i can't say, i don't know him + <antrik> braunr: nope. in fact we discussed this in the past. someone even + worked on GSoC project bringing Hurd/Mach features to NetBSD -- but AFAIK + nothing came out of it + <braunr> antrik: ok + <LibreMan> well, he is pretty vocal with plenty of writings ... on the + other hand you seemed to know me well enough to proclaim me a non-hacker + <braunr> i don't know why he worked on emacs and gcc rather than the hurd + :p + <braunr> but something other than freedom must have motivated such choices + <antrik> I'm uncertain though whether NetBSD is a more useful base than + Linux. it would offer advantages on the licensing front, but it would not + offer the advantage that people could just run it on their existing + systems... + <LibreMan> gcc seems pretty significant for Linux lol + <braunr> antrik: true + <LibreMan> or GNU + <braunr> antrik: there are already system call stubs, and the VM is very, + very similar + <braunr> LibreMan: the hurd was too, at the time + <LibreMan> he can not work on everything + <braunr> so he ahd to choose, and based his choice on something else than + freedom (since all these projects are free) + <braunr> i guess he enjoyed emacs more + <antrik> LibreMan: RMS is not much of a practicing hacker anymore + nowadays... + <antrik> braunr: yeah, that's another advantage of using NetBSD as a + base... it might be easier to do + <braunr> LibreMan: what was your original question again ? + <braunr> i've been somewhat ironic since that trademark stuff, i'm serious + again now + <antrik> LibreMan: again, freedom is a factor for many of us; but not the + primary motivation + <antrik> (as braunr put, being free software is mandatory for us; but that + doesn't mean the main reason for working on the Hurd is some indirect + benefit for the free software movement...) + <LibreMan> braunr: the original goal was to understand the strong points of + Hurd to I can help communicate them to other hackers who might be + interested in Hurd + <LibreMan> because I wanted it to succeed to advance freedom more + <antrik> LibreMan: well, practice what you preach ;-) + <LibreMan> but now that I've founf that not even devs themselves are that + much interested in freedom I do not have that desire anymore + <antrik> you will hardly motivate other hackers to work on something you do + not even work on yourself... + <LibreMan> and focus my attention somewhere else + <antrik> [sigh] + <braunr> well, you can now state that the hurd has an elegant architecture + allowing many ugly hacks to disappear, and that it doesn't yet handle + sata drives or usb keys or advandced multicast routing or ... + <antrik> LibreMan: how about you listen to what we are saying? + <LibreMan> antrik: so I should work on everything in the world that + advances freedom or shut up? + <antrik> LibreMan: we *are* interested in freedom. we would work on nothing + else than a free software system. it's just not the primary motivation + for working on the Hurd + <antrik> if you primary motivation is advancing free software, the Hurd is + probably indeed not the right project to work on. other projects are more + important for that + <antrik> and that's got nothing to do with our priorities + <antrik> it's simply a matter of what areas free software is most lacking + in. the kernel is not one of them. + <braunr> antrik: my primary concern with netbsd are drivers + <LibreMan> I naively assumed that people working on a GNU project will + share GNU vlaues, instead I find that some of them poke fun at its high + priority projects + <braunr> i poke fun at you + <braunr> because you think trademark has any real value on the free + software community + <LibreMan> braunr: I see, congratulations ... I hope you enjoy it + <antrik> if there were no suitable free software kernels around, many + people might work on the Hurd mostly to advance free software. but as it + stands, having a GNU kernel is secondary + <braunr> yes, freedom is a primary goal when there are no free alternatives + <antrik> LibreMan: you are accusing us of not sharing GNU values, which is + quite outrageous I must say + <braunr> LibreMan: actually no, i'd prefer converstation with someone who + understands what i'm saying + <braunr> even if he contradicts me, like antrik often does + <braunr> (but he's usually right) + <braunr> LibreMan: you just don't want to accept some (many) of us are here + more for technical reasons than ethical ones + <LibreMan> antrik: well, some of your reasoning and tone would seem to + suggest so ... + <braunr> i didn't see antrik being particularly aggressive, but personally, + i react badly to stupidity + <LibreMan> braunr: WHAT? I've never said anything about what you should or + should not do or believe + <braunr> you clearly expected something when you first arrived + <LibreMan> I said I personally expected more enhusiastic people concerning + GNU and freedom but that was my personal expectaion and my personal + disappointment + <antrik> what makes you think we are not enthusiastic about GNU and + software freedom? + <braunr> more enthusiastic is vague, you expected us to be some sort of + freedom fighters + <antrik> just for the record, I'm part of the German core team of the FSFE + <braunr> i even stated early that we're mostly part of the free software + rather than open source movement, and you still find our point of view + disappointing + <antrik> still, it's not my major motivation for working on the Hurd + <antrik> I don't see any contradiction in that + <LibreMan> I don;t know maybe I misunderstand you, I do not mean any + disrespect + <braunr> me neither + <LibreMan> maybe "hackers" truly do think differently than I expected them + to in general and it's not specific to Hurd + <braunr> well the very word hacker describe someone interested by "hacking" + down something to get to understand it + <braunr> it's strongly technical + <LibreMan> antrik: why are you a core team member of th FSFE? what do you + do there and why? is that not motivated by the desire for more freedom? + <braunr> and we're lucky, many of them aren't deeply concerned with money + and secrecy, and prefer being open about their work + <braunr> you still don't get it ... + <antrik> LibreMan: of course it is + <antrik> and hacking free software in general also is (partly) motivated by + that + <antrik> but hacking on the Hurd specifically not so much + <braunr> 20:23 < antrik> LibreMan: we *are* interested in freedom. we would + work on nothing else than a free software system. it's just not the + primary motivation for working on the Hurd + <braunr> he already answered your question there + <antrik> (as I already said, it *is* in fact part of the motivation in my + case... just not the major part) + <LibreMan> antrik: but if it ever achieved wide success and you would be + asy on a "board" to decide future direction would you choose for exacmple + to prevent TiVO-ization over wider adpotion? + <braunr> we already answered that too + <antrik> LibreMan: that's actually not even for us to decide, as long as we + are an official GNU project + <antrik> but of course we are a GNU project because we *do* believe in + software freedom, and obviously wouldn't accept Tivoisation + <braunr> (and our discussion about using netbsd as a code base is a + relevant example of license concerns) + <LibreMan> I'm really trying to get to the core of "not motivated by + freedom" but being "interested in freedom" ... I really do not get that, + if you are interested in freedom wouldn't you want a project you work on + being used to advance it as much as possible and therefore be also + motivated to do it the best while enjoying it to achieve the goal of more + freedom since you value it that much? + <braunr> LibreMan: except for the GPLv2 vs GPLv3 debate, i don't see where + there can be a conflict between freedom and technical interest + <LibreMan> braunr: the issues around freedom are mainly not technical + ... GPLv2 and GPLv3 is also not about technical interests + <braunr> that's my problem with you, i fail to see where the problem you + think of is + <LibreMan> it tends to be about the possibility to extract money and impose + your will on the users which turns out to be highly profitable and + politicaly desirable in some instances + <LibreMan> of course it's technically the best to open-source but how are + you going to sell a product like that? that is the main question + troubling most corporations + <LibreMan> ok, I'm not going to bore you any more ;) I found out what I + needed to know ... now I'm going to try to forget about Hurd and focus on + something else where my help can be more effective at achieving what I + want ;) good luck with your endavours + <antrik> LibreMan: of course we hope for the Hurd to advance the cause of + freedom, just like any free software we would work on... still, it's not + the primary reason why we work on the Hurd, instead of the myriads of + other free software projects out there + + +# IRC, freenode, #hurd, 2012-04-09 + + <antono> what is the most impressive thing about hurd you wold like to + promote? + <antono> killing feature + <antono> i've created some simple hurd screencasts here + http://shelr.tv/records/search?utf8=%E2%9C%93&q=hurd + <antono> but probably i could share something more interesting :) + <antrik> antono: if we had such an obvious killer feature, we wouldn't have + to struggle ;-) + <antrik> the problem is that the advantages of the Hurd architecture are + too abstract for the vast majority of people to take them seriously + <antrik> IMHO the most interesting part of the Hurd is the fully + decentralised (and thus infinitely extensible) VFS mechanism + <antrik> but even that is very abstract... + <antono> antrik: cand i do somenthing relly fundamental with hurd + translator? + <antono> for example i hate old school unix FHS + <antono> I would like to have only /Users/me and /System/GNU + <antono> and i would like to only see it, but behinde the scenes it should + be Debian with FHS layout + <antono> is it possible? + <antrik> antono: of course. not sure translators offer much advantage over + FUSE in this case though... it doesn't really change the functionality of + the VFS; only rearranges the tree a bit + <antrik> (might even be doable with standard Linux features) + + +# IRC, freenode, #hurd, 2012-07-25 + + <braunr> because it has design problems, because it has implementation + problems, lots of problems, and far too few people to keep up with other + systems that are already dominating + <braunr> also, considering other research projects get much more funding + than we do, they probably have a better chance at being adopted + <rah> you consider the Hurd to be a research project? + <braunr> and as they're more recent, they sometimes overcome some of the + issues we have + <braunr> yes and no + <braunr> yes because it was, at the time of its creation, and it hasn't + changed much, and there aren't many (any?) other systems with such a + design + <braunr> and no because the hurd is actually working, and being released as + part of something like debian + <braunr> which clearly shows it's able to do the stuff it was intended for + <braunr> i consider it a technically very interesting project for + developers who want to know more about microkernel based extensible + systems + <antrik> rah: I don't expect the Hurd to achieve world domination, because + most people consider Linux "good enough" and will stick with it + <antrik> I for my part think though we could do better than Linux (in + certain regards I consider important), which is why I still consider it + interesting and worthwhile + <nowhere_man> I think that in some respect the OS scene may evolve a bit + like the PL one, where everyone progressively adopts ideas from Lisp but + doesn't want to do Lisp: everyone slowly shifts towards what µ-kernels + OSes have done from the start, but they don't want µ-kernels... + <braunr> nowhere_man: that's my opinion too + <braunr> and this is why i think something like the hurd still has valuable + purpose + <nowhere_man> braunr: in honesty, I still ponder the fact that it's my + coping mechanism to accept being a Lisp and Hurd fan ;-) + <braunr> nowhere_man: it can be used that way too + <braunr> functional programming is getting more and more attention + <braunr> so it's fine if you're a lisp fan really diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn new file mode 100644 index 00000000..4946a5a0 --- /dev/null +++ b/open_issues/mmap_crash_etc.mdwn @@ -0,0 +1,95 @@ +[[!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]]."]]"""]] + +Several issues here: + + * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't + crash the process. + + * [[!tag open_issue_documentation]] The memory layout example should be + documented. + + * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be + desirable; see also [[placement_of_virtual_memory_regions]]. + + * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most + probably a bug*. + +IRC, freenode, #hurd, 2011-08-11 + + < zyg> oh, mmap sigsegvs, strange. + < braunr> hwo do you see that ? + < zyg> braunr: I'll try to paste a minimal case + < braunr> zyg: make sure you have a sane memory setup + < braunr> 512 RAM / 1G swap seems good + < braunr> have more swap than RAM + < zyg> I have those. Still it shouldn't sigsegv. + < braunr> gnumach is picky about that + < braunr> and yes, the hurd shouldn't have bugs + < zyg> braunr: ready to crash? #include <stdio.h> #include <sys/mman.h> int + main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON + | MAP_FIXED, -1, 0); return 0; } + < braunr> a fixed mapping at such an address is likely to fail, yes + < braunr> but a crash, hm + < zyg> why should it fail? + < braunr> because the hurd doesn't have a common text data bss heap stack + layout + < braunr> e.g. there are mappings below text, as show by vminfo : + < braunr> $ vminfo $$ + < braunr> 0[0x1000] (prot=0) + < braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105) + < braunr> 0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105) + < braunr> 0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105) + < braunr> 0x24000[0x1000] (prot=0, max_prot=RWX) + < braunr> 0x25000[0xfff000] (prot=RWX, mem_obj=106) + < braunr> 0x1024000[0x1000] (prot=RWX, mem_obj=107) + < braunr> 0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108) + < braunr> 0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108, + offs=0x1000) + < braunr> 0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109) + < braunr> 0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110, + offs=0x1000) + < braunr> 0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111) + < braunr> (sorry for the long paste) + < zyg> oh.. my mmap falls into an occupied range? + < braunr> seems so + < zyg> thanks, that was really useful. + < braunr> MAP_FIXED isn't portable, this is clearly stated in most man + pages + < zyg> yes, implementation specific it says + < braunr> well the behaviour isn't specific, it's well defined, but the + memory layout isn't + < braunr> i personally think vm_map() should be slightly changed to include + a new flag for top-down allocations + < braunr> so that our stack and libraries are at high addresses, below the + kernel + < braunr> zyg: what kind of error do you get ? i don't get sigsegv + < zyg> I get both sigsegv and sigill depending on addr + < braunr> ok + < braunr> i get sigill with your example + < braunr> the error is the same (wrong memory access) but the behaviour + changes because of the special memory configuration + < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an + guard + < braunr> some accesses cause invalid page faults (which are sent as + segmentation faults) while other cause general protection faults (which + are sent as illegal instructions) + < braunr> (this is quite weird since the GP fault is likely because the + access targets something out of the data or code segment eh) + < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way? + < braunr> gnumach + < braunr> on i386 + < braunr> the segmant configuration isn't completely flat + < braunr> segment* + < braunr> hm nice + < braunr> your small program triggers the "task X deallocating an invalid + port Y, most probably a bug." message + < zyg> where do you see that? + < braunr> on the mach console diff --git a/open_issues/mmap_write-only.mdwn b/open_issues/mmap_write-only.mdwn new file mode 100644 index 00000000..467274c5 --- /dev/null +++ b/open_issues/mmap_write-only.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2011, 2012 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-12-14 + + <pinotree> hm, interesting mmap bug + <youpi> ? + <pinotree> youpi: http://paste.debian.net/149252/ + #include <sys/types.h> + #include <sys/mman.h> + #include <fcntl.h> + #include <stdio.h> + #include <errno.h> + #include <stdlib.h> + #include <string.h> + #include <unistd.h> + + void die(int x, const char *s) + { + perror(s); + exit(x); + } + + static const char s_file[] = "foo-mmaptest"; + + int main() + { + int fd; + void *p; + + fd = creat(s_file, 0777); + if (fd < 0) die(1, "creat"); + errno = 0; + p = mmap(NULL, 1, PROT_READ, MAP_SHARED, fd, 0); + printf("> %p vs %p, %d (%s)\n", p, MAP_FAILED, errno, strerror(errno)); + unlink(s_file); + return (p != MAP_FAILED); + } + <pinotree> on linux it returns 0 and fails with EACCESS (as it seems it + should, by reading the mmap posix docs), on hurd it returns 1 and the + mmap succeeds + <pinotree> (taken from llvm's configure) + <youpi> why should it? file size extension ? + <pinotree> creat creates a o_wronly file, while the mmap specifies only + read protection + <youpi> oh, craet is always wo + <youpi> I didn't know that diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn new file mode 100644 index 00000000..562ccd83 --- /dev/null +++ b/open_issues/multiprocessing.mdwn @@ -0,0 +1,82 @@ +[[!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 +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 open_issue_hurd]] + +We would expect that fine-grained, compartmentalized systems, that is, +microkernel-based multi-server systems in particular, would be ideal candidates +for applying multiprocessing. That is, however, only true from a first and +inexperienced point of view: there are many difficulties. + + +IRC, freenode, #hurd, August / September 2010 + + <marcusb> silver_hook: because multi-server systems depend on inter-process + communication, and inter-process communication is many times more + expensive across cpus + <marcusb> silver_hook: so you either force interrelated work on the same + cpu, or suffer heavy penalties. and in a typical fine-grained object + system, all objects are interconnected! + <marcusb> silver_hook: resources in today's systems, even in a single node + with one cpu, but more so in a network, are very non-uniform. scheduling + these resources efficiently is a huge problem. restricting the resource + distribution policies in the way microkernel systems tend to do is posing + serious research challenges + + +IRC, freenode, #hurd, 2011-07-26 + + < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a + multicore architecture than linux ? + < braunr> CTKArcher: short answer: no + < CTKArcher> it's easier to imagine one server pro core than the linux + kernel divided to be executed on multiple cores + < braunr> CTKArcher: this approach is less efficient + < braunr> CTKArcher: threads carry state, both explicit and implicit (like + cache data) + < braunr> CTKArcher: switching to another core means resetting and + refetching this state + < braunr> it's expensive and there is no gain obtained by doing this + < braunr> thread migration (having a thread from a client also run in + servers when making synchronous RPC, even handling its own page faults) + was implemented in mach4 and is imo a very good thing we should have + < braunr> CTKArcher: and concerning linux, it's actually very scalable + < braunr> it's already like if all client threads run in servers (the + kernel is the servers there) + < braunr> rcu is used a lot + < braunr> thread migration already takes into account smt, cores, and numa + < braunr> it's hard to do something better + < braunr> (here, thread migration means being dispatched on another cpu) + < braunr> some systems like dragonflybsd go as far as to pin threads on one + processor for their entire lifetime + < braunr> in order to have rcu-like locking almost everywhere + < braunr> (you could argue it's less efficient since in the worst case + everything runs on the same cpu, but it's very unlikely, and in practice + most patterns are well balanced) + + +debian-hurd list + +On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: +> Georg Lehner writes: +> +> > - One promise of the microkernel architecture is better performance on +> > multiprocessor systems, or multicomputer systems. What is the status +> > of Gnu Mach with respect to these. +> +> This may or may not be true. The Hurd is built around a microkernel +> architecture because of its conceptual elegance and flexibility. +> Other touted advantages may be more illusory than real, at least, they +> aren't something *we* are proclaiming is our motivation. + + +--- + +See also: [[multithreading]]. diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn new file mode 100644 index 00000000..f42601b4 --- /dev/null +++ b/open_issues/multithreading.mdwn @@ -0,0 +1,226 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]] + +Hurd servers / VFS libraries are multithreaded. + + +# Implementation + + * well-known threading libraries + + * [[hurd/libthreads]] + + * [[hurd/libpthread]] + + +# Design + +See [[hurd/libports]]: roughly using one thread per +incoming request. This is not the best approach: it doesn't really make sense +to scale the number of worker threads with the number of incoming requests, but +instead they should be scaled according to the backends' characteristics. + +The [[hurd/Critique]] should have some more on this. + +[*Event-based Concurrency +Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf), +Tom Van Cutsem, 2009. + + +## IRC, freenode, #hurd, 2012-07-08 + + <youpi> braunr: about limiting number of threads, IIRC the problem is that + for some threads, completing their work means triggering some action in + the server itself, and waiting for it (with, unfortunately, some lock + held), which never terminates when we can't create new threads any more + <braunr> youpi: the number of threads should be limited, but not globally + by libports + <braunr> pagers should throttle their writeback requests + <youpi> right + + +## IRC, freenode, #hurd, 2012-07-16 + + <braunr> hm interesting + <braunr> when many threads are creating to handle requests, they + automatically create a pool of worker threads by staying around for some + time + <braunr> this time is given in the libport call + <braunr> but the thread always remain + <braunr> they must be used in turn each time a new requet comes in + <braunr> ah no :(, they're maintained by the periodic sync :( + <braunr> hm, still not that, so weird + <antrik> braunr: yes, that's a known problem: unused threads should go away + after some time, but that doesn't actually happen + <antrik> don't remember though whether it's broken for some reason, or + simply not implemented at all... + <antrik> (this was already a known issue when thread throttling was + discussed around 2005...) + <braunr> antrik: ok + <braunr> hm threads actually do finish .. + <braunr> libthreads retain them in a pool for faster allocations + <braunr> hm, it's worse than i thought + <braunr> i think the hurd does its job well + <braunr> the cthreads code never reaps threads + <braunr> when threads are finished, they just wait until assigned a new + invocation + + <braunr> i don't understand ports_manage_port_operations_multithread :/ + <braunr> i think i get it + <braunr> why do people write things in such a complicated way .. + <braunr> such code is error prone and confuses anyone + + <braunr> i wonder how well nested functions interact with threads when + sharing variables :/ + <braunr> the simple idea of nested functions hurts my head + <braunr> do you see my point ? :) variables on the stack automatically + shared between threads, without the need to explicitely pass them by + address + <antrik> braunr: I don't understand. why would variables on the stack be + shared between threads?... + <braunr> antrik: one function declares two variables, two nested functions, + and use these in separate threads + <braunr> are the local variables still "local" + <braunr> ? + <antrik> braunr: I would think so? why wouldn't they? threads have separate + stacks, right?... + <antrik> I must admit though that I have no idea how accessing local + variables from the parent function works at all... + <braunr> me neither + + <braunr> why don't demuxers get a generic void * like every callback does + :(( + <antrik> ? + <braunr> antrik: they get pointers to the input and output messages only + <antrik> why is this a problem? + <braunr> ports_manage_port_operations_multithread can be called multiple + times in the same process + <braunr> each call must have its own context + <braunr> currently this is done by using nested functions + <braunr> also, why demuxers return booleans while mach_msg_server_timeout + happily ignores them :( + <braunr> callbacks shouldn't return anything anyway + <braunr> but then you have a totally meaningless "return 1" in the middle + of the code + <braunr> i'd advise not using a single nested function + <antrik> I don't understand the remark about nested function + <braunr> they're just horrible extensions + <braunr> the compiler completely hides what happens behind the scenes, and + nasty bugs could come out of that + <braunr> i'll try to rewrite ports_manage_port_operations_multithread + without them and see if it changes anything + <braunr> but it's not easy + <braunr> also, it makes debugging harder :p + <braunr> i suspect gdb hangs are due to that, since threads directly start + on a nested function + <braunr> and if i'm right, they are created on the stack + <braunr> (which is also horrible for security concerns, but that's another + story) + <braunr> (at least the trampolines) + <antrik> I seriously doubt it will change anything... but feel free to + prove me wrong :-) + <braunr> well, i can see really weird things, but it may have nothing to do + with the fact functions are nested + <braunr> (i still strongly believe those shouldn't be used at all) + + +## IRC, freenode, #hurd, 2012-08-31 + + <braunr> and the hurd is all but scalable + <gnu_srs> I thought scalability was built-in already, at least for hurd?? + <braunr> built in ? + <gnu_srs> designed in + <braunr> i guess you think that because you read "aggressively + multithreaded" ? + <braunr> well, a system that is unable to control the amount of threads it + creates for no valid reason and uses global lock about everywhere isn't + really scalable + <braunr> it's not smp nor memory scalable + <gnu_srs> most modern OSes have multi-cpu support. + <braunr> that doesn't mean they scale + <braunr> bsd sucks in this area + <braunr> it got better in recent years but they're way behind linux + <braunr> linux has this magic thing called rcu + <braunr> and i want that in my system, from the beginning + <braunr> and no, the hurd was never designed to scale + <braunr> that's obvious + <braunr> a very common mistake of the early 90s + + +## IRC, freenode, #hurd, 2012-09-06 + + <braunr> mel-: the problem with such a true client/server architecture is + that the scheduling context of clients is not transferred to servers + <braunr> mel-: and the hurd creates threads on demand, so if it's too slow + to process requests, more threads are spawned + <braunr> to prevent hurd servers from creating too many threads, they are + given a higher priority + <braunr> and it causes increased latency for normal user applications + <braunr> a better way, which is what modern synchronous microkernel based + systems do + <braunr> is to transfer the scheduling context of the client to the server + <braunr> the server thread behaves like the client thread from the + scheduler perspective + <gnu_srs> how can creating more threads ease the slowness, is that a design + decision?? + <mel-> what would be needed to implement this? + <braunr> mel-: thread migration + <braunr> gnu_srs: is that what i wrote ? + <mel-> does mach support it? + <braunr> mel-: some versions do yes + <braunr> mel-: not ours + <gnu_srs> 21:49:03) braunr: mel-: and the hurd creates threads on demand, + so if it's too slow to process requests, more threads are spawned + <braunr> of course it's a design decision + <braunr> it doesn't "ease the slowness" + <braunr> it makes servers able to use multiple processors to handle + requests + <braunr> but it's a wrong design decision as the number of threads is + completely unchecked + <gnu_srs> what's the idea of creating more theads then, multiple cpus is + not supported? + <braunr> it's a very old decision taken at a time when systems and machines + were very different + <braunr> mach used to support multiple processors + <braunr> it was expected gnumach would do so too + <braunr> mel-: but getting thread migration would also require us to adjust + our threading library and our servers + <braunr> it's not an easy task at all + <braunr> and it doesn't fix everything + <braunr> thread migration on mach is an optimization + <mel-> interesting + <braunr> async ipc remains available, which means notifications, which are + async by nature, will create messages floods anyway + + +# Alternative approaches: + + * <http://www.concurrencykit.org/> + + * Continuation-passing style + + * [[microkernel/Mach]] internally [[uses + continuations|microkernel/mach/continuation]], too. + + * [[Erlang-style_parallelism]] + + * [[!wikipedia Actor_model]]; also see overlap with + {{$capability#wikipedia_object-capability_model}}. + + * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) + + * <http://monkey.org/~provos/libevent/> + +--- + +See also: [[multiprocessing]]. diff --git a/open_issues/multithreading/erlang-style_parallelism.mdwn b/open_issues/multithreading/erlang-style_parallelism.mdwn new file mode 100644 index 00000000..75539848 --- /dev/null +++ b/open_issues/multithreading/erlang-style_parallelism.mdwn @@ -0,0 +1,201 @@ +[[!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, #hurd, 2010-10-05 + + <sdschulze> antrik: Erlang-style parallelism might actually be interesting + for Hurd translators. + <sdschulze> There are certain similarities between Erlang's message boxes + and Mach ports. + <sdschulze> The problem is that all languages that implement the Erlang + actor model are VM-based. + <antrik> sdschulze: I guess that's because most systems don't offer this + kind of message passing functionality out of the box... perhaps on Hurd + it would be possible to implement an Erlang-like language natively? + <sdschulze> That would be quite attractive -- having the same API for + in-process parallelism and IPC. + <sdschulze> But I don't see why Erlang needs a VM... It could also be + implemented in a library. + [...] + <sdschulze> BTW, Scala doesn't require a VM by design. Its Erlang + implementation is a binary-compatible abstraction to Java. + [...] + <sdschulze> My point was that Erlang employs some ideas that might be + usable in the Hurd libraries. + <sdschulze> concerning multithreading stuff + <sdschulze> Unfortunately, it will not contribute to readability if done in + C. + <antrik> perhaps it's worth a look :-) + <sdschulze> Actually, a Mach port is pretty close to an Erlang actor. + <sdschulze> Currently, your I/O callbacks have to block when they're + waiting for something. + <sdschulze> What they should do is save the Mach port and respond as soon + as they can. + <sdschulze> So there should be a return status for "call me later, when I + tell you to" in the callbacks. + <sdschulze> Then the translator associates the Mach port with the summary + of the request in some data structure. + <sdschulze> As soon as the data is there, it tells the callback function to + appear again and fulfills the request. + <sdschulze> That's -- very roughly -- my idea. + <sdschulze> Actually, this eliminates the need for multithreading + completely. + <antrik> sdschulze: not sure whether you are talking about RPC level or + libc level here... + <sdschulze> It should be transparent to libc. + <sdschulze> If the client does a read() that cannot be answered immediatly, + it blocks. + <sdschulze> The difference is that there is no corresponding blocking + thread in the translator. + <antrik> ah, so you are talking about the server side only + <sdschulze> yes + <antrik> you mean the callback functions provided by the translator + implementation should return ASAP, and then the dispatcher would call + them again somehow + <sdschulze> allowing the server to be single-threaded, if desired + <sdschulze> exactly + <sdschulze> like: call_again (mach_port); + <antrik> but if the functions give up control, how does the dispatcher know + when they are ready to be activated again? or does it just poll? + <sdschulze> The translator knows this. + <sdschulze> hm... + <antrik> well, we are talking about the internal design of the translator, + right? + <antrik> I'm not saying it's impossible... but it's a bit tricky + <antrik> essentially, the callbacks would have to tell the dispatcher, + "call me again when there is an incoming message on this port" + <sdschulze> Say we have a filesystem translator. + <antrik> (or rather, it probably should actually call a *different* + callback when this happens) + <sdschulze> The client does a "read(...)". + <sdschulze> => A callback is called in the translator. + <antrik> let's call it disfs_S_io_read() ;-) + <antrik> err... diskfs + <sdschulze> The callback returns: SPECIAL_CALL_ME_LATER. + <sdschulze> yes, exactly that :) + <sdschulze> But before, it saves the position to be read in its internal + data structure. + <sdschulze> (a sorted tree, whatever) + <sdschulze> The main loop steps through the data structure, doing a read() + on the underlying translator (might be the disk partition). + <sdschulze> "Ah, gotcha, this is what the client with Mach port number 1234 + wanted! Call his callback again!" + <sdschulze> Then we're back in diskfs_S_io_read() and supply the data. + <antrik> so you want to move part of the handling into the main loop? while + I'm not fundamentally opposed to that, I'm not sure whether the + dispatcher/callback approach used by MIG makes much sense at all in this + case... + <antrik> my point is that this probably can be generalised. blocking + operations (I/O or other) usually wait for a reply message on a port -- + in this case the port for the underlying store + <antrik> so the main loop would just need to wait for a reply message on + the port, without really knowing what it means + <sdschulze> on what port? + <antrik> so disfs_S_io_read() would send a request message to the store; + then it would return to the dispatcher, informing it to call + diskfs_S_io_read_finish() or something like that when there is a message + on the reply port + <antrik> main loop would add the reply port to the listening port bucket + <antrik> and as soon as the store provides the reply message, the + dispatcher would then call diskfs_S_io_read_finish() with the reply + message + <sdschulze> yes + <antrik> this might actually be doable without changes to MIG, and with + fairly small changes to libports... though libdiskfs etc. would probably + need major rewrites + <sdschulze> What made me think about it is that Mach port communication + doesn't block per se. + <antrik> all this is however ignoring the problem I mentioned yesterdays: + we need to handle page faults as well... + <sdschulze> It's MIG and POSIX that block. + <sdschulze> What about page faults? + <antrik> when the translator has some data mapped, instead of doing + explicit I/O, blocking can occur on normal memory access + <sdschulze> antrik: Well, I've only been talking about the server side so + far. + <antrik> sdschulze: this *is* the server side + <antrik> sdschulze: a filesystem translator can map the underlying store + for example + <antrik> (in fact that's what the ext2 translator does... which is why we + had this 2G partition limit) + <sdschulze> antrik: Ah, OK, so in other words, there are requests that it + can answer immediatly and others that it can't? + <antrik> that's not the issue. the issue is the the ext2 translator doesn't + issue explicit blocking io_read() operations on the underlying + store. instead, it just copies some of it's own address space from or to + the client; and if the page is not in physical memory, blocking occurs + during the copy + <antrik> so essentially we would need a way to return control to the + dispatcher when a page fault occurs + <sdschulze> antrik: Ah, so MIG will find the translator unresponsive? (and + then do what?) + <antrik> sdschulze: again, this is not really a MIG thing. the main loop is + *not* in MIG -- it's provided by the tranlator, usually through libports + <sdschulze> OK, but as Mach IPC is asynchronous, a temporarily unresponsive + translator won't cause any severe harm? + <sdschulze> antrik: "Easy" solution: use a defined number of worker + threads. + <antrik> sdschulze: well, for most translators it doesn't do any harm if + they block. but if we want to accept that, there is no point in doing + this continuation stuff at all -- we could just use a single-threaded + implementation :-) + <sdschulze> Hard solution: do use explicit I/O and invent a + read_no_pagefault() call. + <antrik> not sure what you mean exactly. what I would consider is something + like an exception handler around the copy code + <antrik> so if an exception occurs during the copy, control is returned to + the dispatcher; and once the pager informs us that the memory is + available, the copy is restarted. but this is not exacly simple... + <sdschulze> antrik: Ah, right. If the read() blocks, you haven't gained + anything over blocking callbacks. + * sdschulze adopted an ML coding style for his C coding... + <sdschulze> antrik: Regarding it on the Mach level, all you want to do is + some communication on some ports. + <sdschulze> antrik: Only Unix's blocking I/O makes you want to use threads. + <sdschulze> Unless you have a multicore CPU, there's no good reason why you + would *ever* want multithreading. + <sdschulze> (except poor software design) + <sdschulze> antrik: Is there a reason why not to use io_read? + <antrik> sdschulze: I totally agree about multithreading... + <antrik> as for not using io_read(): some things are easier and/or more + efficient with mapping + <antrik> the Mach VM is really the most central part of Mach, and it's + greatest innovation... + <sdschulze> antrik: If you used explicit I/O, it would at least shift the + problem somewhere else... + <antrik> sure... but that's a workaround, not a solution + <sdschulze> I'm not sure how to deal with page faults then -- I know too + little about the Hurd's internal design. + <sdschulze> Non-blocking io_read only works if we address the client side, + too, BTW. + <sdschulze> which would be quite ugly in C IMHO + <sdschulze> announce_read (what, to, read, when_ready_callback); + <antrik> sdschulze: POSIX knows non-blocking I/O + <antrik> never checked how it works though + <sdschulze> Yes, but I doubt it does what we want. + <antrik> anyways, it's not too hard to do non-blocking io_read(). the + problem is that then you have to use MIG stubs directly, not the libc + function + <sdschulze> And you somehow need to get the answer. + <sdschulze> resp. get to know when it's ready + <antrik> the Hurd actually comes with a io_request.defs and io_reply.defs + by default. you just need to use them. + <sdschulze> oh, ok + <antrik> (instead of the usual io.defs, which does a blocking send/receive + in one step) + <sdschulze> I'd be interested how this works in Linux... + <antrik> what exactly? + <sdschulze> simultaneous requests on one FS + <antrik> ah, you mean the internal threading model of Linux? no idea + <sdschulze> if it uses threading at all + <antrik> youpi probably knows... and some others might as well + <sdschulze> Callbacks are still ugly... diff --git a/open_issues/neals_hurd-misc_papers.mdwn b/open_issues/neals_hurd-misc_papers.mdwn new file mode 100644 index 00000000..7f4e1e3b --- /dev/null +++ b/open_issues/neals_hurd-misc_papers.mdwn @@ -0,0 +1,16 @@ +[[!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_documentation]] + +<http://walfield.org/pub/people/neal/papers/hurd-misc/> + + <tschwinge> neal: We could put that into the wiki some day, I think. + <neal> sure diff --git a/open_issues/netstat.mdwn b/open_issues/netstat.mdwn new file mode 100644 index 00000000..b575ea7f --- /dev/null +++ b/open_issues/netstat.mdwn @@ -0,0 +1,34 @@ +[[!meta copyright="Copyright © 2012 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_hurd open_issue_porting]] + + +# IRC, freenode, #hurd, 2012-12-06 + + <braunr> we need a netstat command + <pinotree> wouldn't that require rpcs and notifications in pfinet to get + info on the known sockets? + <braunr> depends on the interface + <braunr> netstat currently uses /proc/net/* so that's out of the question + <braunr> but a bsd netstat using ioctls could do the job + <braunr> i'm not sure if it's done that way + <braunr> i don't see why it would require notifications though + <pinotree> if add such rpcs to pfinet, you could show the sockets in procfs + <braunr> yes + <braunr> that's the clean way :p + <braunr> but why notifications ? + <pinotree> to get changes on data of sockets (status change, i/o activity, + etc) + <pinotree> (possibly i'm forgetting some already there features to know + that) + <braunr> the socket state is centralized in pfinet + <braunr> netstat polls it + <braunr> (or asks it once) diff --git a/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn new file mode 100644 index 00000000..de1d63a3 --- /dev/null +++ b/open_issues/network_file_system_by_just_forwarding_rpcs.mdwn @@ -0,0 +1,21 @@ +[[!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, #hurd, August / September 2010 + + <jkoenig> btw, it should be possible to implement a network "filesystem" by + just forwarding RPCs over the network, right? + <jkoenig> (of course auth would be an additional concern) + <jkoenig> that would open all kinds of possibilities, possibly. + <LarstiQ> jkoenig: plan9? + <jkoenig> I don't know much about plan9 yet. I seem to remember some mach + extension for network transparency being mentionned somewhere.. diff --git a/open_issues/nfs_trailing_slash.mdwn b/open_issues/nfs_trailing_slash.mdwn new file mode 100644 index 00000000..90f138e3 --- /dev/null +++ b/open_issues/nfs_trailing_slash.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2012 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_hurd]] + + +# IRC, freenode, #hurd, 2012-05-27 + + <gg0> ok, on nfs "mkdir dir0" succeeds, "mkdir dir0/" fails. RPC struct is bad + + +## IRC, freenode, #hurd, 2012-05-27 + + <gg0> 150->dir_mkdir ("foo1/" 493) = 0x40000048 (RPC struct is bad) + <gg0> task2876->mach_port_deallocate (pn{ 18}) = 0 + <gg0> mkdir: 136->io_write_request ("mkdir: " -1) = 0 7 + <gg0> cannot create directory `/nfsroot/foo1/' 136->io_write_request + ("cannot create directory `/nfsroot/foo1/'" -1) = 0 40 + <gg0> : RPC struct is bad 136->io_write_request (": RPC struct is bad" -1) + = 0 19 + <gg0> 136->io_write_request (" + <gg0> " -1) = 0 1 + <tschwinge> gg0: Yes, I think we knew about this before. Nobody felt like + working on it yet. Might be a nfs, libnetfs, glibc issue. + <tschwinge> gg0: If you want to work on it, please ask here or on bug-hurd + if you need some guidance. + <gg0> yeah found this thread + http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00069.html I don't + think I'll work on it diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn new file mode 100644 index 00000000..a8a08f90 --- /dev/null +++ b/open_issues/nice_changes_priority_of_parent_shell.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 open_issue_glibc]] + + * [[!debbug 44039]] + + * Also see [[nice_vs_mach_thread_priorities]]. diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn new file mode 100644 index 00000000..6a890eca --- /dev/null +++ b/open_issues/nice_vs_mach_thread_priorities.mdwn @@ -0,0 +1,197 @@ +[[!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 open_issue_glibc]] + +This issue has been known for some time, due to coreutils' testsuite choking +when testing *nice*: [[!debbug 190581]]. + +There has been older discussion about this, too, but this is not yet captured +here. + +IRC, #hurd, August 2010 + + <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems + <pochu> antrik said it would be better to reimplement everything instead of fixing the current Mach interfaces, though I'm not sure about that yet + <youpi> uh, so he changed his mind? + <pochu> it seems POSIX doesn't say nice values should be -20..20, but 0..(2*NZERO - 1) + <youpi> he said we could just change the max priority value and be done with it :) + <pochu> so we can probably define NZERO to 16 to match the Mach range of 0..31 + <youpi> s/said/had said previously/ + <antrik> youpi: POSIX is actually fucked up regarding the definition of nice values + <antrik> or at least the version I checked was + <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just set NZERO to 16 AFAICS: http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html + <antrik> it talkes about NZERO and all; making it *look* like this could be defined arbitrarily... but in other places, it's clear that the standard 40 level range is always assumed + <antrik> anyways, I totally see no point in deviating from other systems in this regard. it can only cause problems, and gives us no benefits + <cfhammar> it says NZERO should be at least 20 iirc + <youpi> agreed + <antrik> I don't remember the details; it's been a while since I looked at this + <antrik> youpi: changing the number of levels is only part of the issue. I'm not sure why I didn't mention it initially when we discussed this + <antrik> youpi: I already concluded years ago that it's not possible to implement nice levels correctly with the current Mach interfaces in a sane fashion + <antrik> (it's probably possible, but only with a stupid hack like setting all the thread priorities one by one) + <antrik> youpi: also, last time we discussed this, I checked how the nice stuff works currently on Hurd; and concluded that it's so utterly broken, that there is no point in trying to preserve *any* compatibility. I think we can safely throw away any handling that is alread there, and do it over from scratch in the most straightforward fashion + <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly what you've just said to be a hack (setting all the thread priorities one by one) + <pochu> but there seems to be consensus that that's undesirable... + <pochu> indeed, POSIX says NZERO should be at least 20 + <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the complexity of setting the thread max priorities individually + <pochu> antrik: I don't. would it be too complex? I imagined it would be a simple loop :) + <antrik> pochu: in order to prevent race conditions, you have to stop all other threads before obtaining the list of threads, and continue them after setting the priority for each + <antrik> I don't even know whether it can be done without interfering with other thread handling... in which case it gets really really ugly + <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the priority stuff as appropriate, and will change the tasks code later + <antrik> it seems to me that using a more suitable kernel interface will not only be more elegant, but quite possibly actually easier to implement... + <pochu> antrik: apparently it's not that hard to change the priority for all threads in a task, see task_priority() in gnumach/kern/task.c + <pochu> it looks like the nice test failures are mostly because of the not 1:1 mapping between nice values and Mach priorities + <marcusb> "Set priority of task; used only for newly created threads." + <marcusb> there is a reason I didn't fix nice 8 years ago + <marcusb> ah there is a change_threads option + <pochu> marcusb: I'm not sure that comment is correct. that syscall is used by setpriority() + <marcusb> yeah + <marcusb> I didn't read further, where it explains the change_threads options + <marcusb> I was shooting before asking questions :) + <marcusb> pochu: although there are some bad interactions if max_priorities are set per thread + <antrik> pochu: maybe we are talking past each other. my point was not that it's hard to do in the kernel. I was just saying that it would be painful to do from userspace with the current kernel interface + <pochu> antrik: you could still use that interface in user space, couldn't you? or maybe I'm misunderstanding... + <pochu> cfhammar, antrik: current patch: http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what to do with high-priority threads. are there cases where there should be a thread with a high priority but the task's priority shouldn't be high? e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c + <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a higher priority, but then either we raise the task's max_priority if we need a high-prio thread, or we treat them specially (e.g. new field in struct thread), or maybe it's a non-issue because in such cases, all the task is high-prio? + <pochu> also I wonder whether I can kill the processor set's max_priority. It seems totally unused (I've checked gnumach, hurd and glibc) + <pochu> (that would simplify the priority handling) + <cfhammar> pochu: btw what does your patch do? i can't remember what was decided + <pochu> cfhammar: it moves the max_priority from the thread to the task, so raising/lowering it has effect on all of its threads + <pochu> it also increases the number of run queues (and thus that of priority levels) from 32 to 40 so we can have a 1:1 mapping with nice values + <pochu> cfhammar: btw don't do a full review yet, just a quick look would be fine for now + <neal> why not do priorities from 0 to 159 + <neal> then both ranges can be scaled + <neal> without loss of precision + <pochu> neal: there would be from Mach to nice priorities, e.g. a task with a priority of 2 another with 3 would have the same niceness, though their priority isn't really the same + <neal> pochu: sure + <neal> pochu: but any posix priority would map to a current mach priority and back + <neal> sorry, that's not true + <neal> a posix priority would map to a new mach priority and bach + <neal> and a current mach priority would map to a new mach priority and back + <neal> which is I think more desirable than changing to 40 priority levels + <pochu> neal> and a current mach priority would map to a new mach priority and back <- why should we care about this? + <neal> to be compatible with existing mach code + <neal> why gratutiously break existing interfaces? + <pochu> they would break anyway, wouldn't them? i.e. if you do task_set_priority(..., 20), you can't know if the caller is assuming old or new priorities (to leave it as 20 or as 100) + <neal> you add a new interface + <neal> you should avoid changing the semantics of existing interfaces as much as possible + <pochu> ok, and deprecate the old ones I guess + <neal> following that rule, priorities only break if someone does task_set_priority_new(..., X) and task_get_priority () + <neal> there are other users of Mach + <neal> I'd add a configure check for the new interface + <neal> alternatively, you can check at run time + <pochu> well if you _set_priority_new(), you should _get_priority_new() :) + <neal> it's not always possible + <pochu> other users of GNU Mach? + <neal> you are assuming you have complete control of all the code + <neal> this is usually not the case + <neal> no, other users of Mach + <neal> even apple didn't gratuitously break Mach + <neal> in fact, it may make sense to see how apple handles this problem + <pochu> hmm, I hadn't thought about that + <pochu> the other thing I don't understand is: "I'd add a configure check for the new interface". a configure check where? in Mach's configure? that doesn't make sense to me + <neal> any users of the interface + <pochu> ok so in clients, e.g. glibc & hurd + <neal> yes. + <antrik> neal: I'm not sure we are winning anything by keeping compatibility with other users of Mach... + <antrik> neal: we *know* that to make Hurd work really well, we have to do major changes sooner or later. we can just as well start now IMHO + <antrik> keeping compatibility just seems like extra effort without any benefit for us + <guillem> just OOC have all other Mach forks, preserved full compatibility? + <neal> guillem: Darwin is pretty compatible, as I understand it + <antrik> pochu: the fundamental approach of changing the task_priority interface to serve as a max priority, and to drop the notion of max priorities from threads, looks fine + <antrik> pochu: I'm not sure about the thread priority handling + <antrik> I don't know how thread priorities are supposed to work in chreads and/or pthread + <antrik> I can only *guess* that they assume a two-stage scheduling process, where the kernel first decides what process to run; and only later which thread in a process... + <antrik> if that's indeed the case, I don't think it's even possible to implement with the current Mach scheduler + <antrik> I guess we could work with relative thread priorities if we really want: always have the highest-priority thread run with the task's max priority, and lower the priorities of the other threads accordingly + <antrik> however, before engaging into this, I think you should better check whether any of the code in Hurd or glibc actually uses thread priorities at all. my guess is that it doesn't + <antrik> I think we could get away with stubbing out thread priority handling alltogether for now, and just use the task priority for all threads + <antrik> I agree BTW that it would be useful to check how Darwin handles this + <pochu> btw do you know where to download the OS X kernel source? I found something called xnu, but I?m not sure that's it + <antrik> pochu: yeah, that's it + <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel... + <pochu> hmm, so they have both a task.priority and a task.max_priority + <neal> pochu: thoughts? + <pochu> neal: they have a priority and a max_priority in the task and in the threads, new threads inherit it from its parent task + <pochu> then they have a task_priority(task, priority, max_priority) that can change a task's priorities, and it also changes it for all its threads + <neal> how does the global run queue work? + <pochu> and they have 128 run queues, no idea if there's a special reason for that number + <pochu> neal: sorry, what do you mean? + <neal> I don't understand the point of the max_priority parameter + <pochu> neal: and I don't understand the point of the (base) priority ;) + <pochu> the max_priority is just that, the maximum priority of a thread, which can be lowered, but can't exceed the max one + <pochu> the (base) priority, I don't understand what it does, though I haven't looked too hard. maybe it's the one a thread starts at, and must be <= max_priority + <antrik> pochu: it's clearly documented in the manual, as well as in the code your initial patch changes... + <antrik> or do you mean the meaning is different in Darwin?... + <pochu> I was speaking of Darwin, though maybe it's the same as you say + <antrik> I would assume it's the same. I don't think there would be any point in having the base vs. max priority distinction at all, except to stay in line with standard Mach... + <antrik> at least I can't see a point in the base priority semantics for use in POSIX systems... + <pochu> right, it would make sense to always have priority == max_priority ... + <pochu> neal: so max_priority is that maximum priority, and priority is the one used to calculate the scheduled priority, and can be raised and lowered by the user without giving special permissions as long as he doesn't raise it above max_priority + <pochu> well this would allow a user to lower a process' priority, and raise it again later, though that may not be allowed by POSIX, so then we would want to have max_priority == priority (or get rid of one of them if possible and backwards compatible) + <antrik> pochu: right, that's what I think too + <antrik> BTW, did I bring up handling of thread priorities? I know that I meant to, but I don't remember whether I actually did... + <pochu> antrik: you told me it'd be ok to just get rid of them for now + <pochu> so I'm more thinking of fixing max_priority and (base) priority and leaving thread's scheduling priority as it currently is + <pochu> s/so/though/ + <antrik> pochu: well, my fear is that keeping the thread priority handling as ist while changing task priority handling would complicate the changes, while giving us no real benefit... + <antrik> though looking at what Darwin did there should give you an idea what it involves exactly... + <pochu> antrik: what would you propose, keeping sched_priority == max_priority ? + <pochu> s/keeping/making/ + <antrik> yes, if that means what I think it does ;-) + <antrik> and keeping the priority of all threads equal to the task priority for now + <antrik> of course this only makes sense if changing it like this is actually simpler than extending the current handling... + <antrik> again, I can't judge this without actually knowing the code in question. looking at Darwin should give you an idea... + <pochu> I think leaving it as is, making it work with the task's max_priority changes would be easier + <antrik> perhaps I'm totally overestimating the amount of changes required to do what Darwin does + <antrik> OTOH, carrying around dead code isn't exactly helping the maintainability and efficiency of gnumach... + <antrik> so I'm a bit ambivalent on this + <antrik> should we go for minimal changes here, or use this occasion to simplify things?... + <antrik> I guess it would be good to bring this up on the ML + <cfhammar> in the context of gsoc i'd say minimal changes + <pochu> there's also neal's point on keeping backwards compatibility as much as possible + <neal> my point was not backwards compatibility at all costs + <antrik> I'm still not convinced this is a valid point :-) + <neal> but to not gratutiously break things + <antrik> neal: well, I never suggested breaking things just because we can... I only suggested breaking things to make the code and interface simpler :-) + <antrik> I do not insist on it though + <neal> at that time, we did not know how Mac did it + <antrik> I only think it would be good to get into a habit that Mach interfaces are not sacred... + <neal> and, I also had a proposal, which I think is not difficult to implement given the existing patch + <antrik> but as I said, I do not feel strongly about this. if people feel more confident about a minimal change, I'm fine with that :-) + <antrik> neal: err... IIRC your proposal was only about the number of nice levels? we are discussing the interface change necessary to implement POSIX semantics properly + <antrik> or am I misremembering? + <pochu> antrik: he argues that with that number of nice levels, we could keep backwards compatibility for the 0..31 levels, and for 0..39 for POSIX compatibility + <antrik> pochu: yes, I remember that part + <neal> antrik : My suggestion was: raise the number of nice levels to 160 and introduce a new interface which uses those. Adjust the old interface to space by 160/32 + <antrik> neal: I think I said it before: the problem is not *only* in the number of priority levels. the semantics are also wrong. which is why Darwin added a max_priority for tasks + <neal> what do you mean the semantics are wrong? + <neal> I apologize if you already explained this. + <antrik> hm... I explained it at some point, but I guess you were not present at that conversation + <neal> I got disconnected recently so I likely don't have it in backlog. + <antrik> in POSIX, any process can lower its priority; while only privileged processes can raise it + <antrik> Mach distinguishes between "current" and "max" priority for threads: "max" behaves like POSIX; while "current" can be raised or lowered at will, as long as it stays below "max" + <antrik> for tasks, there is only a "current" priority + <antrik> (which applies to newly created threads, and optionally can be set for all current threads while changing the task priority) + <antrik> glibc currently uses the existing task priorities, which leads to *completely* broken semantics + <antrik> instead, we need something like a max task priority -- which is exactly what Darwin added + <neal> yes + <antrik> (the "current" task priority is useless for POSIX semantics as far as I can tell; and regarding thread priorities, I doubt we actually use them at all?...) + <cfhammar> where does a new thread get its initial max_priority from? + <antrik> cfhammar: from the creator thread IIRC + <pochu> yes + +2010-08-12 + + <pochu> my plan is to change the number of priority levels and the threads/tasks priority handling, then add new RPCs to play with them and make the old ones stay compatible, then make glibc use the new RPCs + +--- + +Another nice issue: [[nice_changes_priority_of_parent_shell]]. diff --git a/open_issues/nightly_builds.mdwn b/open_issues/nightly_builds.mdwn new file mode 100644 index 00000000..167e7375 --- /dev/null +++ b/open_issues/nightly_builds.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]]."]]"""]] + +We'd like to have nightly builds for the whole [[toolchain]], and then do some +automatic [[unit_testing]] on them. + +Resources: + + * [[hurd/running/Nix]] + + * [[toolchain/cross-gnu]] + + * [[Debian_Cross_Toolchain]] + + * As reported in the [[news/2010-05-31]] news, there's Hydra doing nightly + builds / Nix packages. + + * <http://hudson-ci.org/>, <http://jenkins-ci.org/> + + * <http://buildbot.net/> + +--- + +See also [[nightly_builds_deb_packages]]. diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn new file mode 100644 index 00000000..11fc4c79 --- /dev/null +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -0,0 +1,31 @@ +[[!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 +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]]."]]"""]] + +I'd be quite helpful to have nightly builds in form of Debian `.deb` +packages. + + * <http://noone.org/talks/vcs-buildd/> (german) + + * Need to have an automation to get from Hurd upstream Git branches to + a branch usable in Debian. + +--- + +There is infrastructure available to test whole OS installations. + + * <http://www.os-autoinst.org/> + +--- + +[[Debian_Cross_Toolchain]] for cross-building? + +--- + +See also [[nightly_builds]]. diff --git a/open_issues/notmuch_n_gmane.mdwn b/open_issues/notmuch_n_gmane.mdwn new file mode 100644 index 00000000..664c9876 --- /dev/null +++ b/open_issues/notmuch_n_gmane.mdwn @@ -0,0 +1,18 @@ +[[!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="Notmuch'n'Gmane"]] + +[[!taglink open_issue_documentation]]; [[ikiwiki]] issue. + +In `\[[!message-id +"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]`, underscores +are replaced with spaces in the rendered output: [[!message-id +"AANLkTinY1Cd4_qO_9euYJN8zev4hdr7_ANpjNG+yGRMn@mail.gmail.com"]]. diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..9ff5fb51 --- /dev/null +++ b/open_issues/nptl.mdwn @@ -0,0 +1,37 @@ +[[!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 open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else? + <youpi> actually NPTL doesn't _require_ futexes + <youpi> it just requires low-level locks + <youpi> Mmm, it seems to be so only in principle + <youpi> I can see futex names here and there in the generic code + <youpi> looks like Drepper isn't disciplined enough in that area either + <tschwinge> (well, why would he...) + <youpi> I'm not sure we really want to port NPTL + <tschwinge> OK. + <youpi> Drepper will keep finding things to add + <youpi> while the interface between glibc and libpthread isn't increasing _so_ much + <tschwinge> ... and even less so the interfavce that actual applications are using. + <tschwinge> We'd need to evaluate which benefits NPTL would bring. + +--- + +# Resources + + * <http://www.akkadia.org/drepper/nptl-design.pdf> + + * <http://nptltracetool.sourceforge.net/> + + * <http://posixtest.sourceforge.net/> diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn new file mode 100644 index 00000000..3f77a0f2 --- /dev/null +++ b/open_issues/o_exec.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2012 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="O_EXEC"]] + +[[!tag open_issue_glibc open_issue_hurd]] + + +# IRC, freenode, #hurd, 2012-04-24 + + <pinotree> interesting, glibc on every OS except hurd (so including linux + too) does not define O_EXEC + <pinotree> can somebody please help me understand a POSIX behaviour? + <pinotree> it's about fexecve: + http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html + <pinotree> basically, it seems to me (reading the "errors" and "application + usage" sections) that O_EXEC for open() the fd is not mandatory, and if + not used fexecve will check for file permission at call time? + <pinotree> because currently libdiskfs and libnetfs require the fd to be + open with O_EXEC + <braunr> "Since execute permission is checked by fexecve(), the file + description fd need not have been opened with the O_EXEC flag" + <braunr> this one makes it clear checking for O_EXEC is wrong + <braunr> it looks like O_EXEC is only needed when you want to have files + for which only the execution permission is set + <braunr> but not the read one + <braunr> (i don't understand the "and write" part though) + <braunr> "exec will fail if the mode of the file associated with fd does + not grant execute permission to the calling process at the time fexecve() + is called." + <braunr> this one strengthens the impression you have, that fexecve indeed + checks file permissions at the time it's called + <braunr> pinotree: hope it helps + <pinotree> so it implies the following: + <pinotree> O_RDONLY → exec works if the file is readable + <braunr> exec works if the file is readable and/or executable (although + without read permissions you can't check it) + <braunr> (well, fexecve) + <pinotree> O_EXEC → exec requires that the permission of the file at + fexecve() time have +x + <braunr> i'd say ye so far + <braunr> yes + <pinotree> so we need to fix lib{disk,net}fs then + <braunr> seems so + <pinotree> enlighting, merci braunr + <braunr> de rien + <pinotree> :) diff --git a/open_issues/ogi.mdwn b/open_issues/ogi.mdwn new file mode 100644 index 00000000..e4372dc0 --- /dev/null +++ b/open_issues/ogi.mdwn @@ -0,0 +1,25 @@ +[[!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]]."]]"""]] + +Go through Ognyan Kulev's (ogi) pages, and archive / hunt down what's still +interesting. + + * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/links/> + + * <http://debian.fmi.uni-sofia.bg/~ogi/hurd/ext3fs/> + + * SVN ext2fs (ext2fs / large stores doc) + + done + + * ext3fs et al. + + checking copyright situation, also for thesis / w.r.t. university + project diff --git a/open_issues/open_posix_test_suite.mdwn b/open_issues/open_posix_test_suite.mdwn new file mode 100644 index 00000000..089ea1b1 --- /dev/null +++ b/open_issues/open_posix_test_suite.mdwn @@ -0,0 +1,2715 @@ +[[!meta copyright="Copyright © 2009 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="Open POSIX Test Suite"]] + +Here's a log of a [Open POSIX Test Suite](http://posixtest.sourceforge.net/) +run (get sources, `make`, inspect `logfile`); this is from 2009-07-27 HEAD +sources on a 2009-07-27 Debian GNU/Hurd system. + +The `logfile` has been post-processed with: + + $ sed ↩ + -e '/build: PASS$/d' ↩ + -e '/link: PASS$/d' ↩ + -e '/link: SKIP$/d' ↩ + -e '/execution: PASS$/d' + +The tests that failed as *INTERRUPTED* were hanging and have manually been +interrupted using `kill [PID]`. + + conformance/definitions/signal_h/16-1: build: FAILED: Compiler output: + conformance/definitions/signal_h/16-1.c:14: error: ‘SA_SIGINFO’ undeclared here (not in a function) + conformance/definitions/signal_h/16-1.c:15: error: ‘SA_NOCLDWAIT’ undeclared here (not in a function) + conformance/definitions/signal_h/26-1: build: FAILED: Compiler output: + conformance/definitions/signal_h/26-1.c:9: error: expected ‘)’ before ‘int’ + conformance/definitions/signal_h/26-1.c: In function ‘dummyfcn’: + conformance/definitions/signal_h/26-1.c:13: error: ‘pthread_kill_test’ undeclared (first use in this function) + conformance/definitions/signal_h/26-1.c:13: error: (Each undeclared identifier is reported only once + conformance/definitions/signal_h/26-1.c:13: error: for each function it appears in.) + conformance/definitions/signal_h/26-1.c:13: error: expected ‘;’ before ‘dummyvar’ + conformance/definitions/signal_h/26-1.c:14: error: ‘dummyvar’ undeclared (first use in this function) + conformance/definitions/signal_h/26-1.c:14: error: ‘pthread_kill’ undeclared (first use in this function) + conformance/interfaces/aio_cancel/3-1: build: FAILED: Compiler output: + conformance/interfaces/aio_cancel/3-1.c: In function ‘main’: + conformance/interfaces/aio_cancel/3-1.c:96: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_cancel/3-1.c:96: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_cancel/3-1.c:96: error: for each function it appears in.) + conformance/interfaces/aio_cancel/3-1.c:97: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_fsync/1-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/1-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/1-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/1-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/10-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/10-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/10-1.c:33: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/10-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/11-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/11-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/11-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/11-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/13-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/13-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/13-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/6-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/6-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/6-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/6-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_fsync/7-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_fsync/7-1.c: In function ‘main’: + conformance/interfaces/aio_fsync/7-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_fsync/7-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/12-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/12-1.c: In function ‘main’: + conformance/interfaces/aio_read/12-1.c:34: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/12-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/13-1.c: In function ‘main’: + conformance/interfaces/aio_read/13-1.c:33: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/13-1.c:33: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/14-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/14-1.c: In function ‘main’: + conformance/interfaces/aio_read/14-1.c:34: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/14-1.c:34: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/15-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/15-1.c: In function ‘main’: + conformance/interfaces/aio_read/15-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/15-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_read/6-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_read/6-1.c: In function ‘main’: + conformance/interfaces/aio_read/6-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_read/6-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_suspend/1-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/1-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/1-1.c:120: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/1-1.c:120: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/1-1.c:120: error: for each function it appears in.) + conformance/interfaces/aio_suspend/1-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/2-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_suspend/2-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/2-1.c:31: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_suspend/2-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_suspend/6-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/6-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/6-1.c:116: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/6-1.c:116: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/6-1.c:116: error: for each function it appears in.) + conformance/interfaces/aio_suspend/6-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/7-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/7-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/7-1.c:118: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/7-1.c:118: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/7-1.c:118: error: for each function it appears in.) + conformance/interfaces/aio_suspend/7-1.c:124: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/8-1: build: FAILED: Compiler output: + conformance/interfaces/aio_suspend/8-1.c: In function ‘main’: + conformance/interfaces/aio_suspend/8-1.c:121: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/aio_suspend/8-1.c:121: error: (Each undeclared identifier is reported only once + conformance/interfaces/aio_suspend/8-1.c:121: error: for each function it appears in.) + conformance/interfaces/aio_suspend/8-1.c:127: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/aio_write/10-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/10-1.c: In function ‘main’: + conformance/interfaces/aio_write/10-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/10-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/11-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/11-1.c: In function ‘main’: + conformance/interfaces/aio_write/11-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/11-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/12-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/12-1.c: In function ‘main’: + conformance/interfaces/aio_write/12-1.c:31: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/12-1.c:31: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/13-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/13-1.c: In function ‘main’: + conformance/interfaces/aio_write/13-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/13-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/aio_write/4-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/aio_write/4-1.c: In function ‘main’: + conformance/interfaces/aio_write/4-1.c:30: error: implicit declaration of function ‘exit’ + conformance/interfaces/aio_write/4-1.c:30: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/fork/2-1: build: FAILED: Compiler output: + conformance/interfaces/fork/2-1.c: In function ‘main’: + conformance/interfaces/fork/2-1.c:240: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/fork/2-1.c:240: error: (Each undeclared identifier is reported only once + conformance/interfaces/fork/2-1.c:240: error: for each function it appears in.) + conformance/interfaces/fork/2-1.c:241: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function) + conformance/interfaces/lio_listio/1-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/1-1.c: In function ‘main’: + conformance/interfaces/lio_listio/1-1.c:110: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/1-1.c:110: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/1-1.c:110: error: for each function it appears in.) + conformance/interfaces/lio_listio/1-1.c:122: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/10-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/10-1.c: In function ‘main’: + conformance/interfaces/lio_listio/10-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/10-1.c:107: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/10-1.c:107: error: for each function it appears in.) + conformance/interfaces/lio_listio/10-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/11-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/11-1.c: In function ‘main’: + conformance/interfaces/lio_listio/11-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/11-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/11-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/11-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/14-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/14-1.c: In function ‘main’: + conformance/interfaces/lio_listio/14-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/14-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/14-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/14-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/15-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/15-1.c: In function ‘main’: + conformance/interfaces/lio_listio/15-1.c:111: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/15-1.c:111: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/15-1.c:111: error: for each function it appears in.) + conformance/interfaces/lio_listio/15-1.c:123: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/16-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/16-1.c: In function ‘main’: + conformance/interfaces/lio_listio/16-1.c:32: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/16-1.c:32: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/17-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/17-1.c: In function ‘main’: + conformance/interfaces/lio_listio/17-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/17-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/19-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/19-1.c: In function ‘main’: + conformance/interfaces/lio_listio/19-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/19-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/2-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/2-1.c: In function ‘main’: + conformance/interfaces/lio_listio/2-1.c:106: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/2-1.c:106: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/2-1.c:106: error: for each function it appears in.) + conformance/interfaces/lio_listio/2-1.c:118: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/20-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/20-1.c: In function ‘main’: + conformance/interfaces/lio_listio/20-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/20-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/21-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/21-1.c: In function ‘main’: + conformance/interfaces/lio_listio/21-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/21-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/22-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/22-1.c: In function ‘main’: + conformance/interfaces/lio_listio/22-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/22-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/23-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/23-1.c: In function ‘main’: + conformance/interfaces/lio_listio/23-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/23-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/24-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/24-1.c: In function ‘main’: + conformance/interfaces/lio_listio/24-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/24-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/25-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/lio_listio/25-1.c: In function ‘main’: + conformance/interfaces/lio_listio/25-1.c:19: error: implicit declaration of function ‘exit’ + conformance/interfaces/lio_listio/25-1.c:19: error: incompatible implicit declaration of built-in function ‘exit’ + conformance/interfaces/lio_listio/3-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/3-1.c: In function ‘main’: + conformance/interfaces/lio_listio/3-1.c:107: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/3-1.c:107: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/3-1.c:107: error: for each function it appears in.) + conformance/interfaces/lio_listio/3-1.c:119: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/4-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/4-1.c: In function ‘main’: + conformance/interfaces/lio_listio/4-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/4-1.c:114: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/4-1.c:114: error: for each function it appears in.) + conformance/interfaces/lio_listio/4-1.c:126: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/lio_listio/7-1: build: FAILED: Compiler output: + conformance/interfaces/lio_listio/7-1.c: In function ‘main’: + conformance/interfaces/lio_listio/7-1.c:113: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/lio_listio/7-1.c:113: error: (Each undeclared identifier is reported only once + conformance/interfaces/lio_listio/7-1.c:113: error: for each function it appears in.) + conformance/interfaces/lio_listio/7-1.c:125: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/mq_open/27-1: build: FAILED: Compiler output: + conformance/interfaces/mq_open/27-1.c: In function ‘main’: + conformance/interfaces/mq_open/27-1.c:27: error: ‘PATH_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_open/27-1.c:27: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_open/27-1.c:27: error: for each function it appears in.) + cc1: warnings being treated as errors + conformance/interfaces/mq_open/27-1.c:27: error: unused variable ‘qname’ + conformance/interfaces/mq_send/13-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/13-1.c:30: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function) + conformance/interfaces/mq_send/4-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-1.c: In function ‘main’: + conformance/interfaces/mq_send/4-1.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-1.c:41: error: for each function it appears in.) + conformance/interfaces/mq_send/4-2: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-2.c: In function ‘main’: + conformance/interfaces/mq_send/4-2.c:41: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-2.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-2.c:41: error: for each function it appears in.) + conformance/interfaces/mq_send/4-3: build: FAILED: Compiler output: + conformance/interfaces/mq_send/4-3.c: In function ‘main’: + conformance/interfaces/mq_send/4-3.c:51: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/4-3.c:51: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/4-3.c:51: error: for each function it appears in.) + conformance/interfaces/mq_send/7-1: build: FAILED: Compiler output: + conformance/interfaces/mq_send/7-1.c: In function ‘main’: + conformance/interfaces/mq_send/7-1.c:60: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_send/7-1.c:60: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_send/7-1.c:60: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/13-1: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/13-1.c:31: error: ‘MQ_PRIO_MAX’ undeclared here (not in a function) + conformance/interfaces/mq_timedsend/4-1: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-1.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-1.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-1.c:45: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/4-2: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-2.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-2.c:45: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-2.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-2.c:45: error: for each function it appears in.) + conformance/interfaces/mq_timedsend/4-3: build: FAILED: Compiler output: + conformance/interfaces/mq_timedsend/4-3.c: In function ‘main’: + conformance/interfaces/mq_timedsend/4-3.c:55: error: ‘MQ_PRIO_MAX’ undeclared (first use in this function) + conformance/interfaces/mq_timedsend/4-3.c:55: error: (Each undeclared identifier is reported only once + conformance/interfaces/mq_timedsend/4-3.c:55: error: for each function it appears in.) + conformance/interfaces/pthread_attr_getstack/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_getstack/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_getstack/1-1.c:54: error: for each function it appears in.) + conformance/interfaces/pthread_attr_getstacksize/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_getstacksize/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_getstacksize/1-1.c:53: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/1-1.c:63: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/2-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/2-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/2-1.c:90: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/4-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/4-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/4-1.c:73: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/6-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/6-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/6-1.c:59: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstack/7-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstack/7-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstack/7-1.c:60: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/1-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/1-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/1-1.c:41: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/2-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/2-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/2-1.c:79: error: for each function it appears in.) + conformance/interfaces/pthread_attr_setstacksize/4-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_attr_setstacksize/4-1.c: In function ‘main’: + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: ‘PTHREAD_STACK_MIN’ undeclared (first use in this function) + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: (Each undeclared identifier is reported only once + conformance/interfaces/pthread_attr_setstacksize/4-1.c:50: error: for each function it appears in.) + conformance/interfaces/pthread_key_create/speculative/5-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_key_create/speculative/5-1.c:37: error: ‘PTHREAD_KEYS_MAX’ undeclared here (not in a function) + conformance/interfaces/pthread_once/3-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_once/3-1.c: In function ‘main’: + conformance/interfaces/pthread_once/3-1.c:71: error: expected expression before ‘{’ token + conformance/interfaces/pthread_once/6-1: build: FAILED: Compiler output: + conformance/interfaces/pthread_once/6-1.c: In function ‘test’: + conformance/interfaces/pthread_once/6-1.c:199: error: expected expression before ‘{’ token + conformance/interfaces/sched_yield/1-1: build: FAILED: Compiler output: + cc1: warnings being treated as errors + conformance/interfaces/sched_yield/1-1.c: In function ‘set_process_affinity’: + conformance/interfaces/sched_yield/1-1.c:87: error: implicit declaration of function ‘__CPU_ZERO_S’ + conformance/interfaces/sched_yield/1-1.c:89: error: implicit declaration of function ‘__CPU_SET_S’ + conformance/interfaces/sched_yield/1-1.c: In function ‘set_thread_affinity’: + conformance/interfaces/sched_yield/1-1.c:119: error: implicit declaration of function ‘pthread_setaffinity_np’ + conformance/interfaces/sched_yield/1-1.c: In function ‘runner’: + conformance/interfaces/sched_yield/1-1.c:136: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’ + conformance/interfaces/sched_yield/1-1.c: In function ‘busy_thread’: + conformance/interfaces/sched_yield/1-1.c:159: error: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘pthread_t’ + conformance/interfaces/sem_init/6-1: build: FAILED: Compiler output: + conformance/interfaces/sem_init/6-1.c: In function ‘main’: + conformance/interfaces/sem_init/6-1.c:29: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function) + conformance/interfaces/sem_init/6-1.c:29: error: (Each undeclared identifier is reported only once + conformance/interfaces/sem_init/6-1.c:29: error: for each function it appears in.) + conformance/interfaces/sem_open/5-1: build: FAILED: Compiler output: + conformance/interfaces/sem_open/5-1.c: In function ‘main’: + conformance/interfaces/sem_open/5-1.c:32: error: ‘SEM_VALUE_MAX’ undeclared (first use in this function) + conformance/interfaces/sem_open/5-1.c:32: error: (Each undeclared identifier is reported only once + conformance/interfaces/sem_open/5-1.c:32: error: for each function it appears in.) + conformance/interfaces/sigaction/10-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/10-1.c: In function ‘main’: + conformance/interfaces/sigaction/10-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/10-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/10-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigaction/11-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/11-1.c: In function ‘main’: + conformance/interfaces/sigaction/11-1.c:50: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/11-1.c:50: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/11-1.c:50: error: for each function it appears in.) + conformance/interfaces/sigaction/19-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-1.c: In function ‘main’: + conformance/interfaces/sigaction/19-1.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-1.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-1.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-10: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-10.c: In function ‘main’: + conformance/interfaces/sigaction/19-10.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-10.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-10.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-11: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-11.c: In function ‘main’: + conformance/interfaces/sigaction/19-11.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-11.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-11.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-12: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-12.c: In function ‘main’: + conformance/interfaces/sigaction/19-12.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-12.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-12.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-13: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-13.c: In function ‘main’: + conformance/interfaces/sigaction/19-13.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-13.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-13.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-14: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-14.c: In function ‘main’: + conformance/interfaces/sigaction/19-14.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-14.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-14.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-15: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-15.c: In function ‘main’: + conformance/interfaces/sigaction/19-15.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-15.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-15.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-16: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-16.c: In function ‘main’: + conformance/interfaces/sigaction/19-16.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-16.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-16.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-17: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-17.c: In function ‘main’: + conformance/interfaces/sigaction/19-17.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-17.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-17.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-18: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-18.c: In function ‘main’: + conformance/interfaces/sigaction/19-18.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-18.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-18.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-19: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-19.c: In function ‘main’: + conformance/interfaces/sigaction/19-19.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-19.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-19.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-2: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-2.c: In function ‘main’: + conformance/interfaces/sigaction/19-2.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-2.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-2.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-20: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-20.c: In function ‘main’: + conformance/interfaces/sigaction/19-20.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-20.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-20.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-21: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-21.c: In function ‘main’: + conformance/interfaces/sigaction/19-21.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-21.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-21.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-22: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-22.c: In function ‘main’: + conformance/interfaces/sigaction/19-22.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-22.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-22.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-23: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-23.c: In function ‘main’: + conformance/interfaces/sigaction/19-23.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-23.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-23.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-24: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-24.c: In function ‘main’: + conformance/interfaces/sigaction/19-24.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-24.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-24.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-25: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-25.c: In function ‘main’: + conformance/interfaces/sigaction/19-25.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-25.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-25.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-26: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-26.c: In function ‘main’: + conformance/interfaces/sigaction/19-26.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-26.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-26.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-3: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-3.c: In function ‘main’: + conformance/interfaces/sigaction/19-3.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-3.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-3.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-4: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-4.c: In function ‘main’: + conformance/interfaces/sigaction/19-4.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-4.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-4.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-5: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-5.c: In function ‘main’: + conformance/interfaces/sigaction/19-5.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-5.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-5.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-6: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-6.c: In function ‘main’: + conformance/interfaces/sigaction/19-6.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-6.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-6.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-7: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-7.c: In function ‘main’: + conformance/interfaces/sigaction/19-7.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-7.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-7.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-8: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-8.c: In function ‘main’: + conformance/interfaces/sigaction/19-8.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-8.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-8.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/19-9: build: FAILED: Compiler output: + conformance/interfaces/sigaction/19-9.c: In function ‘main’: + conformance/interfaces/sigaction/19-9.c:117: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/19-9.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/19-9.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/21-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/21-1.c: In function ‘main’: + conformance/interfaces/sigaction/21-1.c:36: error: ‘SA_NOCLDWAIT’ undeclared (first use in this function) + conformance/interfaces/sigaction/21-1.c:36: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/21-1.c:36: error: for each function it appears in.) + conformance/interfaces/sigaction/29-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/29-1.c: In function ‘handler’: + conformance/interfaces/sigaction/29-1.c:95: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/29-1.c:95: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/29-1.c:95: error: for each function it appears in.) + conformance/interfaces/sigaction/29-1.c: In function ‘main’: + conformance/interfaces/sigaction/29-1.c:133: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/29-1.c:145: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/30-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/30-1.c: In function ‘main’: + conformance/interfaces/sigaction/30-1.c:117: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigaction/30-1.c:117: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/30-1.c:117: error: for each function it appears in.) + conformance/interfaces/sigaction/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-1.c: In function ‘main’: + conformance/interfaces/sigaction/6-1.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-1.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-1.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-10: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-10.c: In function ‘main’: + conformance/interfaces/sigaction/6-10.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-10.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-10.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-11: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-11.c: In function ‘main’: + conformance/interfaces/sigaction/6-11.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-11.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-11.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-12: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-12.c: In function ‘main’: + conformance/interfaces/sigaction/6-12.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-12.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-12.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-13: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-13.c: In function ‘main’: + conformance/interfaces/sigaction/6-13.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-13.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-13.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-14: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-14.c: In function ‘main’: + conformance/interfaces/sigaction/6-14.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-14.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-14.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-15: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-15.c: In function ‘main’: + conformance/interfaces/sigaction/6-15.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-15.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-15.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-16: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-16.c: In function ‘main’: + conformance/interfaces/sigaction/6-16.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-16.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-16.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-17: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-17.c: In function ‘main’: + conformance/interfaces/sigaction/6-17.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-17.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-17.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-18: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-18.c: In function ‘main’: + conformance/interfaces/sigaction/6-18.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-18.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-18.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-19: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-19.c: In function ‘main’: + conformance/interfaces/sigaction/6-19.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-19.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-19.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-2: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-2.c: In function ‘main’: + conformance/interfaces/sigaction/6-2.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-2.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-2.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-20: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-20.c: In function ‘main’: + conformance/interfaces/sigaction/6-20.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-20.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-20.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-21: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-21.c: In function ‘main’: + conformance/interfaces/sigaction/6-21.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-21.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-21.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-22: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-22.c: In function ‘main’: + conformance/interfaces/sigaction/6-22.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-22.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-22.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-23: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-23.c: In function ‘main’: + conformance/interfaces/sigaction/6-23.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-23.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-23.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-24: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-24.c: In function ‘main’: + conformance/interfaces/sigaction/6-24.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-24.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-24.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-25: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-25.c: In function ‘main’: + conformance/interfaces/sigaction/6-25.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-25.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-25.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-26: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-26.c: In function ‘main’: + conformance/interfaces/sigaction/6-26.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-26.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-26.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-3: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-3.c: In function ‘main’: + conformance/interfaces/sigaction/6-3.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-3.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-3.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-4: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-4.c: In function ‘main’: + conformance/interfaces/sigaction/6-4.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-4.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-4.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-5: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-5.c: In function ‘main’: + conformance/interfaces/sigaction/6-5.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-5.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-5.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-6: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-6.c: In function ‘main’: + conformance/interfaces/sigaction/6-6.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-6.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-6.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-7: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-7.c: In function ‘main’: + conformance/interfaces/sigaction/6-7.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-7.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-7.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-8: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-8.c: In function ‘main’: + conformance/interfaces/sigaction/6-8.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-8.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-8.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/6-9: build: FAILED: Compiler output: + conformance/interfaces/sigaction/6-9.c: In function ‘main’: + conformance/interfaces/sigaction/6-9.c:34: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/6-9.c:34: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/6-9.c:34: error: for each function it appears in.) + conformance/interfaces/sigaction/9-1: build: FAILED: Compiler output: + conformance/interfaces/sigaction/9-1.c: In function ‘main’: + conformance/interfaces/sigaction/9-1.c:49: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigaction/9-1.c:49: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigaction/9-1.c:49: error: for each function it appears in.) + conformance/interfaces/sigqueue/1-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/1-1.c: In function ‘myhandler’: + conformance/interfaces/sigqueue/1-1.c:33: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/1-1.c:33: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/1-1.c:33: error: for each function it appears in.) + conformance/interfaces/sigqueue/1-1.c: In function ‘main’: + conformance/interfaces/sigqueue/1-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/1-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/4-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/4-1.c: In function ‘main’: + conformance/interfaces/sigqueue/4-1.c:45: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/4-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/4-1.c:45: error: for each function it appears in.) + conformance/interfaces/sigqueue/4-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/5-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/5-1.c: In function ‘main’: + conformance/interfaces/sigqueue/5-1.c:48: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/5-1.c:48: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/5-1.c:48: error: for each function it appears in.) + conformance/interfaces/sigqueue/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/6-1.c: In function ‘main’: + conformance/interfaces/sigqueue/6-1.c:55: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/6-1.c:55: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/6-1.c:55: error: for each function it appears in.) + conformance/interfaces/sigqueue/6-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/7-1.c: In function ‘main’: + conformance/interfaces/sigqueue/7-1.c:52: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1.c:52: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/7-1.c:52: error: for each function it appears in.) + conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigqueue/7-1.c:58: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/8-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/8-1.c: In function ‘main’: + conformance/interfaces/sigqueue/8-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/8-1.c:46: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/8-1.c:46: error: for each function it appears in.) + conformance/interfaces/sigqueue/8-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigqueue/9-1: build: FAILED: Compiler output: + conformance/interfaces/sigqueue/9-1.c: In function ‘main’: + conformance/interfaces/sigqueue/9-1.c:46: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigqueue/9-1.c:46: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigqueue/9-1.c:46: error: for each function it appears in.) + conformance/interfaces/sigqueue/9-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/2-1: build: FAILED: Compiler output: + conformance/interfaces/sigwait/2-1.c: In function ‘main’: + conformance/interfaces/sigwait/2-1.c:45: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/2-1.c:45: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwait/2-1.c:45: error: for each function it appears in.) + conformance/interfaces/sigwait/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigwait/7-1.c: In function ‘main’: + conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwait/7-1.c:114: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwait/7-1.c:114: error: for each function it appears in.) + conformance/interfaces/sigwait/7-1.c:114: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/2-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/2-1.c:44: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1.c:44: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/2-1.c:44: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMAX’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/2-1.c:49: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/5-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/5-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/5-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/5-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/5-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/6-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/6-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/6-1.c:41: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/6-1.c:41: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/6-1.c:41: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/7-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/7-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/7-1.c:48: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/7-1.c:48: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/7-1.c:48: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/7-1.c:51: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/8-1: build: FAILED: Compiler output: + conformance/interfaces/sigwaitinfo/8-1.c: In function ‘main’: + conformance/interfaces/sigwaitinfo/8-1.c:47: error: ‘SA_SIGINFO’ undeclared (first use in this function) + conformance/interfaces/sigwaitinfo/8-1.c:47: error: (Each undeclared identifier is reported only once + conformance/interfaces/sigwaitinfo/8-1.c:47: error: for each function it appears in.) + conformance/interfaces/sigwaitinfo/8-1.c:50: error: ‘SIGRTMIN’ undeclared (first use in this function) + conformance/definitions/mqueue_h/1-1: execution: UNTESTED: Output: + Not Implemented! + conformance/definitions/mqueue_h/10-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/11-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/2-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/3-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/4-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/5-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/6-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/7-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/8-1: execution: UNTESTED: Output: + Test not implemented! + conformance/definitions/mqueue_h/9-1: execution: UNTESTED: Output: + Test not implemented! + conformance/interfaces/aio_cancel/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/10-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/2-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_cancel/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_error/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/12-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/14-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/4-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-3: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/8-4: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_fsync/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/10-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/11-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/11-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/3-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_read/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/3-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_return/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/4-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_suspend/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/1-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/1-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/2-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/3-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/7-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/8-2: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/aio_write/9-2: execution: UNSUPPORTED: Output: + conformance/interfaces/clock_getcpuclockid/1-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_getcpuclockid/2-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_getres/3-1: execution: FAILED: Output: + clock_getres() failed + Test FAILED + conformance/interfaces/clock_getres/7-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME not supported + conformance/interfaces/clock_getres/8-1: execution: UNSUPPORTED: Output: + _POSIX_THREAD_CPUTIME not supported + conformance/interfaces/clock_gettime/3-1: execution: UNSUPPORTED: Output: + CLOCK_MONOTONIC unsupported + conformance/interfaces/clock_gettime/4-1: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/clock_nanosleep/10-1: execution: FAILED: Output: + In handler + errno != EINTR + Test FAILED + conformance/interfaces/clock_nanosleep/9-1: execution: FAILED: Output: + In handler + clock_nanosleep() did not return EINTR + Child did not exit normally. + Test FAILED + conformance/interfaces/clock_settime/1-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/19-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/4-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/4-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/clock_settime/5-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/5-2: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/7-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/7-2: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/8-1: execution: UNTESTED: Output: + Run this test as ROOT, not as a Regular User + conformance/interfaces/clock_settime/speculative/4-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/clock_settime/speculative/4-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/fork/1-1: execution: UNRESOLVED: Output: + [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore) + [02:46:23]Test conformance/interfaces/fork/1-1.c unresolved: got 1073741869 (Operation not supported) on line 115 (Failed to open the semaphore) + conformance/interfaces/fork/11-1: execution: INTERRUPTED: Output: + conformance/interfaces/fork/12-1: execution: FAILED: Output: + [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork + [09:57:13]SIGUSR1 and SIGUSR2 are blocked in child + [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: The new process was created with SIGUSR1 pending + [09:57:13]SIGUSR1 and SIGUSR2 are pending, we can fork + [09:57:13]Test conformance/interfaces/fork/12-1.c FAILED: Child exited abnormally + conformance/interfaces/fork/13-1: execution: UNRESOLVED: Output: + [09:57:14]Test conformance/interfaces/fork/13-1.c unresolved: got 1073741902 (Function not implemented) on line 117 (Failed to set interval timer for ITIMER_VIRTUAL) + conformance/interfaces/fork/14-1: execution: UNRESOLVED: Output: + [09:57:14]Test conformance/interfaces/fork/14-1.c unresolved: got 1073741869 (Operation not supported) on line 100 (Failed to create the named semaphore) + conformance/interfaces/fork/17-1: execution: UNRESOLVED: Output: + [09:57:15]Test conformance/interfaces/fork/17-1.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value) + conformance/interfaces/fork/17-2: execution: UNRESOLVED: Output: + [09:57:15]Test conformance/interfaces/fork/17-2.c unresolved: got 1073741902 (Function not implemented) on line 103 (Failed to get max priority value) + conformance/interfaces/fork/18-1: execution: UNRESOLVED: Output: + [09:57:16]Test conformance/interfaces/fork/18-1.c unresolved: got 1073741902 (Function not implemented) on line 128 (Failed to create a timer) + conformance/interfaces/fork/19-1: execution: UNRESOLVED: Output: + [09:57:16]Test conformance/interfaces/fork/19-1.c unresolved: got 1073741902 (Function not implemented) on line 114 (Failed to create the message queue descriptor) + conformance/interfaces/fork/21-1: execution: UNRESOLVED: Output: + [09:57:17]Test conformance/interfaces/fork/21-1.c unresolved: got 1073741869 (Operation not supported) on line 128 (Failed to open the semaphore) + conformance/interfaces/fork/22-1: execution: UNTESTED: Output: + [09:57:17]File conformance/interfaces/fork/22-1.c cannot test: The testcase needs CPUTIME or THREAD_CPUTIME support + conformance/interfaces/fork/8-1: execution: FAILED: Output: + [09:57:20]Test conformance/interfaces/fork/8-1.c FAILED: The process is created with non-zero tms_cutime or tms_cstime + conformance/interfaces/fsync/7-1: execution: FAILED: Output: + fsync/7-1.c Test Fail: Expect EINVAL, get: (ipc/mig) bad request message ID + conformance/interfaces/lio_listio/12-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/13-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/18-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/5-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/6-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/8-1: execution: UNSUPPORTED: Output: + conformance/interfaces/lio_listio/9-1: execution: UNSUPPORTED: Output: + conformance/interfaces/mlock/10-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlock/5-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlock/8-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/mlockall/13-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/13-2: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/3-6: execution: UNRESOLVED: Output: + An error occurs when calling mlockall(): Function not implemented + conformance/interfaces/mlockall/3-7: execution: UNRESOLVED: Output: + An error occurs when calling mlockall(): Function not implemented + conformance/interfaces/mlockall/8-1: execution: UNRESOLVED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mlockall/speculative/15-1: execution: UNRESOLVED: Output: + Unexpected error: Function not implemented + conformance/interfaces/mmap/11-4: execution: FAILED: Output: + pa: 0x28000 + pa_2: 0x29000 + Test Fail: mmap/11-4.c Modification of the partial page at the end of an object is written out + conformance/interfaces/mmap/11-5: execution: FAILED: Output: + Test Fail: mmap/11-5.c Modification of the partial page at the end of an object is written out + conformance/interfaces/mmap/13-1: execution: FAILED: Output: + Time before write(): 1248767904 + Time before mmap(): 1248767905 + Time before munmap(): 1248767906 + atime1: 1248767904, atime2: 1248767904, atime3: 1248767904 + Test Fail mmap/13-1.c st_atime did not update properly + conformance/interfaces/mmap/14-1: execution: FAILED: Output: + Time before write(): 1248767907 + Time before mmap(): 1248767908 + Time before write reference: 1248767909 + Time before msync(): 1248767910 + ctime1: 1248767909, ctime2: 1248767909 + mtime1: 1248767909, mtime2: 1248767909 + Test Fail mmap/14-1.c st_ctime and st_mtime were not updated properly + conformance/interfaces/mmap/18-1: execution: UNRESOLVED: Output: + mmap/18-1.c Error at mlockall(): Function not implemented + conformance/interfaces/mmap/21-1: execution: FAILED: Output: + Test FAIL + +Kernel panic [[!tag open_issue_gnumach]] (at conformance/interfaces/mmap/24-1): + + Assertion `(object == VM_OBJECT_NULL) || (object->ref_count > 0) || ((object->paging_in_progress != 0) && internal)' failed in file "../gnumach-1-branch-Xen-branch/vm/vm_object.c", line 2087 + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006abc1,20067354,2006708c,827,2e4e5514) + 0x20020ace(20067354,2006708c,827,2001c900,2e3b54f4) + 0x20035ef2(2e4e5514,1000,0,200194c0,2e3b54f4) + 0x2003929f(2e3b4d64,2fc6ff9c,400,0,1) + 0x200577ea(1,15ff998,400,0,1) + 0x20006838(1,15ff998,400,0,1) + >>>>> user space <<<<< + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x20035ef2 0x2003929f 0x200577ea 0x20006838 + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + Assert + ??:0 + vm_object_enter + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_object.c:2109 + vm_map + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/vm/vm_user.c:326 + syscall_vm_map + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_mig.c:657 + mach_call_call + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083 + +Disable the panic-causing test (conformance/interfaces/mmap/24-1) and restart: + + [...] + conformance/interfaces/mmap/24-2: execution: INTERRUPTED: Output: + conformance/interfaces/mmap/27-1: execution: UNTESTED: Output: + Test Untested: MAP_FIXED defined + conformance/interfaces/mmap/28-1: execution: FAILED: Output: + Test Fail: mmap/28-1.c Got no error at mmap() + conformance/interfaces/mmap/31-1: execution: FAILED: Output: + Test FAIL: expect EOVERFLOW but get other error: Cannot allocate memory + off: fffff000, len: fffff000 + conformance/interfaces/mmap/6-4: execution: FAILED: Output: + Test Fail: Did not get EACCES as expected + conformance/interfaces/mmap/6-6: execution: FAILED: Output: + Test Fail: Did not get EACCES as expected + conformance/interfaces/mmap/7-1: execution: UNRESOLVED: Output: + mmap/7-1.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/mmap/7-2: execution: UNRESOLVED: Output: + mmap/7-2.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/mq_close/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_close/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 2-1: mq_open: Function not implemented + unexpected error: mq_close 2-1: read: EOF + conformance/interfaces/mq_close/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 3-1: mq_open: Function not implemented + conformance/interfaces/mq_close/3-2: execution: FAILED: Output: + errno != EBADF on invalid descriptor + Test FAILED + conformance/interfaces/mq_close/3-3: execution: FAILED: Output: + errno != EBADF on invalid descriptor + Test FAILED + conformance/interfaces/mq_close/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_close 4-1: mq_open: Function not implemented + conformance/interfaces/mq_close/5-1: execution: UNTESTED: Output: + Functionality of using mqdes after mq_close() and before + mq_open() will not be tested as POSIX says this is undefined. + conformance/interfaces/mq_getattr/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 2-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/2-2: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 2-2: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 3-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 4-1: mq_open(): Function not implemented + conformance/interfaces/mq_getattr/speculative/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_getattr 7-1: mq_open(): Function not implemented + conformance/interfaces/mq_notify/1-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 1-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 2-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/3-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 3-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/4-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 4-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/5-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 5-1: mq_open: Function not implemented + conformance/interfaces/mq_notify/8-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 8-1: mq_open(): Function not implemented + conformance/interfaces/mq_notify/9-1: execution: UNRESOLVED: Output: + unexpected error: mq_notify 9-1: mq_open: Function not implemented + conformance/interfaces/mq_open/1-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/10-1: execution: UNTESTED: Output: + Will not test the user ID and group ID of a created + message queue as we would need multiple users and + groups on the system to test. + Will not test the file permissions as testing would + be implementation defined. + conformance/interfaces/mq_open/11-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/12-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/13-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/14-1: execution: UNTESTED: Output: + Will not test calling process privileges on name + as POSIX does not define when this error occurs. + conformance/interfaces/mq_open/15-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/16-1: execution: FAILED: Output: + Test FAILED - mq_open() never succeeded + conformance/interfaces/mq_open/17-1: execution: UNTESTED: Output: + Will not test setting O_EXCL without O_CREAT because + results are undefined. + conformance/interfaces/mq_open/18-1: execution: FAILED: Output: + mq_open() did not return success w/O_NONBLOCK set: Function not implemented + Test FAILED + conformance/interfaces/mq_open/19-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/20-1: execution: FAILED: Output: + mq_open() did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/22-1: execution: UNTESTED: Output: + Will not test returning EACCESS when privileges are denied + as POSIX does not define when this error occurs. + conformance/interfaces/mq_open/23-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/24-1: execution: UNTESTED: Output: + Will not test mq_open() being interrupted as it is + not possible to predictably interrupt an mq_open(). + conformance/interfaces/mq_open/25-1: execution: UNTESTED: Output: + Will not test mq_open() failing with EINVAL if mq_open() + is not supported for the name parameter as + unsupported names are implementation defined. + conformance/interfaces/mq_open/25-2: execution: FAILED: Output: + errno != EINVAL for mq_maxmsg 0 + errno != EINVAL for mq_maxmsg -1 + errno != EINVAL for mq_maxmsg -2147483648 + errno != EINVAL for mq_msgsize 0 + errno != EINVAL for mq_msgsize -1 + errno != EINVAL for mq_msgsize -2147483648 + Test FAILED + conformance/interfaces/mq_open/27-2: execution: FAILED: Output: + errno != ENAMETOOLONG + Test FAILED + conformance/interfaces/mq_open/28-1: execution: UNTESTED: Output: + Will not test returning with ENFILE if the system has + too many message queues as this is beyond this + test's domain. + conformance/interfaces/mq_open/29-1: execution: FAILED: Output: + errno != ENOENT + Test FAILED + conformance/interfaces/mq_open/30-1: execution: UNTESTED: Output: + Will not test mq_open() failing with ENOSPC when there + is not enough space to create the message queue + as system space cannot be controlled from this test. + conformance/interfaces/mq_open/4-1: execution: UNTESTED: Output: + Will not test that {OPEN_MAX} file and message queues can + be opened as we cannot determine at run-time if a given + implementation is implemented with a file descriptor. + conformance/interfaces/mq_open/7-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/7-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/7-3: execution: FAILED: Output: + mq_open() for read-only queue did not return success: Function not implemented + Test FAILED + conformance/interfaces/mq_open/8-1: execution: UNRESOLVED: Output: + mq_open() for write-only queue did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/8-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success on read-write queue: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/9-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_open/speculative/26-1: execution: FAILED: Output: + mq_open() failed before expected + errno != EMFILE on > _POSIX_OPEN_MAX or _POSIX_MQ_OPEN_MAX queues + Test FAILED + conformance/interfaces/mq_receive/1-1: execution: FAILED: Output: + unexpected error: mq_receive 1-1: mq_open: Function not implemented + unexpected error: mq_receive 1-1: mq_send: Function not implemented + unexpected error: mq_receive 1-1: mq_send: Function not implemented + unexpected error: mq_receive 1-1: mq_receive: Function not implemented + unexpected error: mq_receive 1-1: mq_receive: Function not implemented + unexpected error: mq_receive 1-1: mq_close: Function not implemented + unexpected error: mq_receive 1-1: mq_unlink: Function not implemented + FAIL: mq_receive didn't receive the highest priority message + FAIL: receive priority 134520252 != send priority 2 + FAIL: mq_receive didn't receive the correct message + FAIL: receive priority 134520252 != send priority 1 + Test FAILED + conformance/interfaces/mq_receive/10-1: execution: FAILED: Output: + unexpected error: mq_receive 10-1: mq_open: Function not implemented + unexpected error: mq_receive 10-1: mq_close: Function not implemented + unexpected error: mq_receive 10-1: mq_unlink: Function not implemented + errno != EAGAIN + Test FAILED + conformance/interfaces/mq_receive/11-1: execution: FAILED: Output: + unexpected error: mq_receive 11-1: mq_open(): Function not implemented + unexpected error: mq_receive 11-1: mq_close(): Function not implemented + unexpected error: mq_receive 11-1: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_receive/11-2: execution: FAILED: Output: + unexpected error: mq_receive 11-2: mq_open(): Function not implemented + unexpected error: mq_receive 11-2: mq_close: Function not implemented + unexpected error: mq_receive 11-2: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_receive/12-1: execution: FAILED: Output: + unexpected error: mq_receive 12-1: mq_open: Function not implemented + unexpected error: mq_receive 12-1: mq_send: Function not implemented + unexpected error: mq_receive 12-1: mq_close: Function not implemented + unexpected error: mq_receive 12-1: mq_unlink: Function not implemented + errno != EMSGSIZE + Test FAILED + conformance/interfaces/mq_receive/13-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 13-1: mq_open: Function not implemented + mq_close() did not return success: Function not implemented + mq_unlink() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 2-1: mq_open: Function not implemented + unexpected error: mq_receive 2-1: mq_send: Function not implemented + unexpected error: mq_receive 2-1: mq_close: Function not implemented + unexpected error: mq_receive 2-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/5-1: execution: FAILED: Output: + unexpected error: mq_receive 5-1: mq_open: Function not implemented + unexpected error: mq_receive 5-1: mq_send: Function not implemented + unexpected error: mq_receive 5-1: mq_receive: Function not implemented + unexpected error: mq_receive 5-1: mq_close: Function not implemented + unexpected error: mq_receive 5-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_receive/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_receive 7-1: mq_open: Function not implemented + unexpected error: mq_receive 7-1: mq_close: Function not implemented + unexpected error: mq_receive 7-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_receive/8-1: execution: FAILED: Output: + unexpected error: mq_receive 8-1: mq_open: Function not implemented + unexpected error: mq_receive 8-1: mq_send: Function not implemented + unexpected error: mq_receive 8-1: mq_send: Function not implemented + unexpected error: mq_receive 8-1: mq_close: Function not implemented + unexpected error: mq_receive 8-1: mq_unlink: Function not implemented + FAIL: mq_receive didn't return the selected message size correctly + FAIL: mq_receive didn't return the selected message size correctly + Test FAILED + conformance/interfaces/mq_send/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/10-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/11-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/11-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/12-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/14-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/3-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/3-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/5-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/5-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/6-1: execution: UNTESTED: Output: + Priority Scheduling needed to make a reliable test case + for this instance. Will not be tested. + conformance/interfaces/mq_send/8-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_send/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/1-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_setattr/5-1: execution: UNRESOLVED: Output: + unexpected error: mq_setattr 5-1: mq_open(): Function not implemented + conformance/interfaces/mq_timedreceive/1-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 1-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 1-1: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't receive the highest priority message + FAIL: receive priority 134520424 != send priority 2 + FAIL: mq_timedreceive didn't receive the correct message + FAIL: receive priority 134520424 != send priority 1 + Test FAILED + conformance/interfaces/mq_timedreceive/10-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented + FAIL: mq_receive fails unexpectly + : Function not implemented + unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_timedreceive/10-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 10-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_send: Function not implemented + Unexpected error at mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-1: mq_unlink: Function not implemented + Test FAILED + conformance/interfaces/mq_timedreceive/11-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 11-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 11-1: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't return the selected message size correctly + FAIL: mq_timedreceive didn't return the selected message size correctly + Test FAILED + conformance/interfaces/mq_timedreceive/13-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 13-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 13-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 13-1: mq_unlink: Function not implemented + errno != EAGAIN + Test FAILED + conformance/interfaces/mq_timedreceive/14-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 14-1: mq_open(): Function not implemented + unexpected error: mq_timedreceive 14-1: mq_close(): Function not implemented + unexpected error: mq_timedreceive 14-1: mq_unlink(): Function not implemented + errno != EBADF + Test FAILED + conformance/interfaces/mq_timedreceive/15-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 15-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 15-1: mq_unlink: Function not implemented + errno != EMSGSIZE + Test FAILED + conformance/interfaces/mq_timedreceive/17-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-1: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/17-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-2: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/17-3: execution: FAILED: Output: + unexpected error: mq_timedreceive 17-3: mq_open: Function not implemented + unexpected error: mq_timedreceive 17-3: mq_close: Function not implemented + unexpected error: mq_timedreceive 17-3: mq_unlink: Function not implemented + errno != EINVAL + Test FAILED + conformance/interfaces/mq_timedreceive/18-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 18-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 18-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 18-1: mq_unlink: Function not implemented + errno != ETIMEDOUT + Test FAILED + conformance/interfaces/mq_timedreceive/18-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 18-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 18-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 18-2: mq_unlink: Function not implemented + errno != ETIMEDOUT + Test FAILED + conformance/interfaces/mq_timedreceive/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 2-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 2-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/5-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 5-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_send: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_timedreceive: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 5-1: mq_unlink: Function not implemented + mq_timedreceive didn't block on waiting + Test FAILED + conformance/interfaces/mq_timedreceive/5-2: execution: FAILED: Output: + unexpected error: mq_timedreceive 5-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 5-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 5-2: mq_unlink: Function not implemented + FAIL: mq_timedreceive didn't block until timout expires + Test FAILED + conformance/interfaces/mq_timedreceive/5-3: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 5-3: mq_open: Function not implemented + mq_close() did not return success: Function not implemented + mq_unlink() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/7-1: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 7-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 7-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 7-1: mq_unlink: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedreceive/8-1: execution: FAILED: Output: + unexpected error: mq_timedreceive 8-1: mq_open: Function not implemented + unexpected error: mq_timedreceive 8-1: mq_close: Function not implemented + unexpected error: mq_timedreceive 8-1: mq_unlink: Function not implemented + Using CLOCK_REALTIME + FAIL: mq_timedreceive didn't block until timout expires + Test FAILED + conformance/interfaces/mq_timedreceive/speculative/10-2: execution: UNRESOLVED: Output: + unexpected error: mq_timedreceive 10-2: mq_open: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_send: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_close: Function not implemented + unexpected error: mq_timedreceive 10-2: mq_unlink: Function not implemented + mq_timedreceive() did fail on invalid abs_time + Test UNRESOLVED + conformance/interfaces/mq_timedsend/1-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/10-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/11-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/11-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/12-1: execution: INTERRUPTED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/14-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/15-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/16-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/17-1: execution: UNTESTED: Output: + Will not test timeout resolution. + conformance/interfaces/mq_timedsend/18-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/19-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/2-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/20-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_timedsend/3-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/3-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/5-3: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/6-1: execution: UNTESTED: Output: + Priority Scheduling needed to make a reliable test case + for this instance. Will not be tested. + conformance/interfaces/mq_timedsend/7-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/8-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/9-1: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + conformance/interfaces/mq_timedsend/speculative/18-2: execution: UNRESOLVED: Output: + mq_open() did not return success: Function not implemented + Test UNRESOLVED + conformance/interfaces/mq_unlink/1-1: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 1-1: mq_open: Function not implemented + conformance/interfaces/mq_unlink/2-1: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 2-1: mq_open: Function not implemented + unexpected error: mq_unlink 2-1: read: EOF + conformance/interfaces/mq_unlink/2-2: execution: UNRESOLVED: Output: + unexpected error: mq_unlink 2-2: mq_open: Function not implemented + unexpected error: mq_unlink 2-2: read: EOF + conformance/interfaces/mq_unlink/2-3: execution: UNTESTED: Output: + Difficult to detect whether mq_unlink will block until all the reference have been closed + for this instance. Will not be tested. + conformance/interfaces/mq_unlink/7-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/mq_unlink/speculative/7-2: execution: FAILED: Output: + Test FAILED, error is Function not implemented + conformance/interfaces/munlock/10-1: execution: UNRESOLVED: Output: + Unexpected error: Operation not permitted + conformance/interfaces/munlock/11-1: execution: UNRESOLVED: Output: + Unexpected error: Operation not permitted + conformance/interfaces/munlock/7-1: execution: UNRESOLVED: Output: + You don't have permission to lock your address space. + Try to rerun this test as root. + conformance/interfaces/munmap/3-1: execution: FAILED: Output: + Test FAILED: munmap/3-1.c munmap returns: No such file or directory + conformance/interfaces/munmap/4-1: execution: UNRESOLVED: Output: + munmap/4-1.c Error at msync(): Error in unknown error system: FFFFFFFF + conformance/interfaces/munmap/8-1: execution: FAILED: Output: + Test FAILED: Expect EINVAL but get: (os/kern) successful + conformance/interfaces/munmap/9-1: execution: FAILED: Output: + Test Fail: Expect EINVAL while get No such file or directory + conformance/interfaces/nanosleep/10000-1: execution: INTERRUPTED: Output: + conformance/interfaces/nanosleep/5-1: execution: FAILED: Output: + nanosleep() did not return -1 on failure + conformance/interfaces/nanosleep/5-2: execution: FAILED: Output: + In handler + Child did not exit normally. + Test FAILED + conformance/interfaces/nanosleep/6-1: execution: UNRESOLVED: Output: + sleep -1 + nanosleep() did not return -1 on failure + conformance/interfaces/nanosleep/7-1: execution: FAILED: Output: + In handler + nanosleep did not return -1 + Child did not exit normally. + Test FAILED + conformance/interfaces/nanosleep/7-2: execution: FAILED: Output: + In handler + nanosleep() was not interrupted + Child did not exit normally. + Test FAILED + conformance/interfaces/pthread_atfork/1-1: execution: UNRESOLVED: Output: + Error in pthread_atfork + conformance/interfaces/pthread_atfork/1-2: execution: UNRESOLVED: Output: + [11:58:02]Test conformance/interfaces/pthread_atfork/1-2.c unresolved: got 1073741902 (Function not implemented) on line 216 (Failed to register the atfork handlers) + conformance/interfaces/pthread_atfork/2-1: execution: FAILED: Output: + Test FAILED: Expected return value success, instead received 1073741902 + conformance/interfaces/pthread_atfork/2-2: execution: UNRESOLVED: Output: + [11:58:03]Test conformance/interfaces/pthread_atfork/2-2.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers(N,N,N)) + conformance/interfaces/pthread_atfork/3-2: execution: UNRESOLVED: Output: + [11:58:03]Test conformance/interfaces/pthread_atfork/3-2.c unresolved: got 1073741902 (Function not implemented) on line 213 (Failed to register the atfork handlers) + conformance/interfaces/pthread_atfork/3-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_atfork/4-1: execution: UNRESOLVED: Output: + [12:10:53]Test conformance/interfaces/pthread_atfork/4-1.c unresolved: got 1073741902 (Function not implemented) on line 244 (Failed to register the atfork handlers) + conformance/interfaces/pthread_attr_getschedparam/1-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_getschedparam 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_getschedpolicy/2-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_getschedpolicy 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setinheritsched/2-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setinheritsched 2-1: pthread_attr_setschedpolicy: (os/kern) successful + conformance/interfaces/pthread_attr_setinheritsched/2-2: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setinheritsched 2-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setinheritsched/2-3: execution: UNRESOLVED: Output: + unexpected error: scheduler 4-1: pthread_setschedparam + conformance/interfaces/pthread_attr_setinheritsched/2-4: execution: UNRESOLVED: Output: + unexpected error: scheduler 4-2: pthread_setschedparam + conformance/interfaces/pthread_attr_setschedparam/1-1: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 1-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-2: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 1-2: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-3: execution: UNRESOLVED: Output: + unexpected error: scheduler 3-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/1-4: execution: UNRESOLVED: Output: + unexpected error: scheduler 3-2: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/speculative/3-1: execution: FAILED: Output: + unexpected error: pthread_attr_setschedparam 3-1: pthread_attr_setschedpolicy + conformance/interfaces/pthread_attr_setschedparam/speculative/3-2: execution: FAILED: Output: + unexpected error: pthread_attr_setschedpaarm 3-2: pthread_attr_setschedpolicyconformance/interfaces/pthread_attr_setschedpolicy/1-1: execution: FAILED: Output: + Error on pthread_attr_setschedpolicy() rc=1073741942 + conformance/interfaces/pthread_attr_setschedpolicy/speculative/5-1: execution: UNRESOLVED: Output: + unexpected error: pthread_attr_setschedpolicy 5-1: pthread_attr_setinheritsched + conformance/interfaces/pthread_attr_setscope/5-1: execution: UNTESTED: Output: + Untested for now, cannot find a unsupported inheritsched value + conformance/interfaces/pthread_barrierattr_getpshared/2-1: execution: UNRESOLVED: Output: + Error at pthread_barrierattr_setpshared() + conformance/interfaces/pthread_barrierattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Error at pthread_barrierattr_setpshared() + conformance/interfaces/pthread_cancel/3-1: execution: UNRESOLVED: Output: + unexpected error: pthread_cancel 3-1: pthread_setschedparam + conformance/interfaces/pthread_cancel/5-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_broadcast/1-2: execution: UNRESOLVED: Output: + [12:42:33]Test starting + [12:42:33]System abilities: + [12:42:33] TPS : -1 + [12:42:33] CS : 200112 + [12:42:33] MON : -1 + [12:42:33] MF : 200112 + [12:42:33]Process-shared attributes won't be tested + [12:42:33]Alternative clock won't be tested + [12:42:33]Test conformance/interfaces/pthread_cond_broadcast/1-2.c unresolved: got 1073741846 (Invalid argument) on line 393 ([parent] Failed to set thread stack size) + conformance/interfaces/pthread_cond_broadcast/2-3: execution: UNRESOLVED: Output: + [12:42:36]Test starting + [12:42:36]System abilities: + [12:42:36] TPS : -1 + [12:42:36] CS : 200112 + [12:42:36] MON : -1 + [12:42:36] MF : 200112 + [12:42:36]Process-shared attributes won't be tested + [12:42:36]Alternative clock won't be tested + [12:42:36]Test conformance/interfaces/pthread_cond_broadcast/2-3.c unresolved: got 1073741846 (Invalid argument) on line 384 ([parent] Failed to set thread stack size) + conformance/interfaces/pthread_cond_broadcast/4-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_destroy/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_init/1-2: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/1-2.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/1-3: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/1-3.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/2-2: execution: UNTESTED: Output: + File conformance/interfaces/pthread_cond_init/2-2.c cannot test: This test requires unsupported features + conformance/interfaces/pthread_cond_init/4-1: execution: UNRESOLVED: Output: + Test conformance/interfaces/pthread_cond_init/4-1.c unresolved: got 1073741942 (Not supported) on line 145 (Cond attribute PSHARED failed) + conformance/interfaces/pthread_cond_init/4-2: execution: INTERRUPTED: Output: + Test conformance/interfaces/pthread_cond_init/4-2.c unresolved: got 1073741942 (Not supported) on line 171 (Cond attribute PSHARED failed) + conformance/interfaces/pthread_cond_signal/1-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_signal/4-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_timedwait/4-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_cond_wait/4-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_condattr_getpshared/1-2: execution: UNRESOLVED: Output: + Error in pthread_condattr_setpshared(), error: 1073741942 + conformance/interfaces/pthread_condattr_setclock/1-2: execution: UNSUPPORTED: Output: + UNSUPPORTED: CLOCK_MONOTONIC is unsupported + conformance/interfaces/pthread_condattr_setclock/1-3: execution: UNSUPPORTED: Output: + _POSIX_CPUTIME unsupported + conformance/interfaces/pthread_condattr_setpshared/1-2: execution: FAILED: Output: + Test FAILED: Could not set pshared to PTHREAD_PROCESS_SHARED, error: 1073741942 + conformance/interfaces/pthread_create/1-4: execution: UNTESTED: Output: + [13:44:56]System abilities: + [13:44:56] TSA: -1 + [13:44:56] TSS: -1 + [13:44:56] TPS: -1 + [13:44:56] pagesize: 4096 + [13:44:56] min stack size: -1 + [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/1-5: execution: UNTESTED: Output: + [13:44:56]System abilities: + [13:44:56] TSA: -1 + [13:44:56] TSS: -1 + [13:44:56] TPS: -1 + [13:44:56] pagesize: 4096 + [13:44:56] min stack size: -1 + [13:44:56]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/1-6: execution: UNTESTED: Output: + [13:44:57]System abilities: + [13:44:57] TSA: -1 + [13:44:57] TSS: -1 + [13:44:57] TPS: -1 + [13:44:57] pagesize: 4096 + [13:44:57] min stack size: -1 + [13:44:57]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/11-1: execution: UNSUPPORTED: Output: + _POSIX_THREAD_CPUTIME not supported + conformance/interfaces/pthread_create/14-1: execution: UNTESTED: Output: + [13:45:08]System abilities: + [13:45:08] TSA: -1 + [13:45:08] TSS: -1 + [13:45:08] TPS: -1 + [13:45:08] pagesize: 4096 + [13:45:08] min stack size: -1 + [13:45:08]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/15-1: execution: UNTESTED: Output: + [13:45:09]System abilities: + [13:45:09] TSA: -1 + [13:45:09] TSS: -1 + [13:45:09] TPS: -1 + [13:45:09] pagesize: 4096 + [13:45:09] min stack size: -1 + [13:45:09]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/3-2: execution: UNTESTED: Output: + [13:45:11]Growing down stack started upon 0x19fffa0 and we are currently down to 0x19fff60 + [13:45:11]Test starting + Stack tests will be executed. + Sched tests won't be executed. + [13:45:11]System abilities: + [13:45:11] TSA: -1 + [13:45:11] TSS: -1 + [13:45:11] TPS: -1 + [13:45:11] pagesize: 4096 + [13:45:11] min stack size: -1 + [13:45:11]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_create/8-2: execution: UNTESTED: Output: + [13:45:13]System abilities: + [13:45:13] TSA: -1 + [13:45:13] TSS: -1 + [13:45:13] TPS: -1 + [13:45:13] pagesize: 4096 + [13:45:13] min stack size: -1 + [13:45:13]File conformance/interfaces/pthread_create/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/1-2: execution: UNTESTED: Output: + [13:45:13]System abilities: + [13:45:13] TSA: -1 + [13:45:13] TSS: -1 + [13:45:13] TPS: -1 + [13:45:13] pagesize: 4096 + [13:45:13] min stack size: -1 + [13:45:13]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/2-2: execution: UNTESTED: Output: + [13:45:14]System abilities: + [13:45:14] TSA: -1 + [13:45:14] TSS: -1 + [13:45:14] TPS: -1 + [13:45:14] pagesize: 4096 + [13:45:14] min stack size: -1 + [13:45:14]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_detach/4-3: execution: UNTESTED: Output: + [13:45:15]System abilities: + [13:45:16] TSA: -1 + [13:45:16] TSS: -1 + [13:45:16] TPS: -1 + [13:45:16] pagesize: 4096 + [13:45:16] min stack size: -1 + [13:45:16]File conformance/interfaces/pthread_detach/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_equal/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_exit/1-2: execution: UNTESTED: Output: + [15:01:43]System abilities: + [15:01:43] TSA: -1 + [15:01:43] TSS: -1 + [15:01:43] TPS: -1 + [15:01:43] pagesize: 4096 + [15:01:43] min stack size: -1 + [15:01:43]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/2-2: execution: UNTESTED: Output: + [15:01:44]System abilities: + [15:01:44] TSA: -1 + [15:01:44] TSS: -1 + [15:01:44] TPS: -1 + [15:01:44] pagesize: 4096 + [15:01:44] min stack size: -1 + [15:01:44]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/3-2: execution: UNTESTED: Output: + [15:01:45]System abilities: + [15:01:45] TSA: -1 + [15:01:45] TSS: -1 + [15:01:45] TPS: -1 + [15:01:45] pagesize: 4096 + [15:01:45] min stack size: -1 + [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/4-1: execution: UNTESTED: Output: + [15:01:45]System abilities: + [15:01:45] TSA: -1 + [15:01:45] TSS: -1 + [15:01:45] TPS: -1 + [15:01:45] pagesize: 4096 + [15:01:45] min stack size: -1 + [15:01:45]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/5-1: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/6-1: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_exit/6-2: execution: UNTESTED: Output: + [15:01:46]System abilities: + [15:01:46] TSA: -1 + [15:01:46] TSS: -1 + [15:01:46] TPS: -1 + [15:01:46] pagesize: 4096 + [15:01:46] min stack size: -1 + [15:01:46]File conformance/interfaces/pthread_exit/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_getschedparam/1-1: execution: FAILED: Output: + Error at pthread_getschedparam: rc=1073741902 + conformance/interfaces/pthread_getschedparam/1-2: execution: UNRESOLVED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_getschedparam/1-3: execution: UNRESOLVED: Output: + [15:01:49]Test conformance/interfaces/pthread_getschedparam/1-3.c unresolved: got 1073741902 (Function not implemented) on line 223 (Failed to get min priority) + conformance/interfaces/pthread_getschedparam/4-1: execution: UNRESOLVED: Output: + [15:01:49]Test conformance/interfaces/pthread_getschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 200 (Unexpected error returned) + conformance/interfaces/pthread_join/1-2: execution: UNTESTED: Output: + [15:01:54]System abilities: + [15:01:54] TSA: -1 + [15:01:54] TSS: -1 + [15:01:54] TPS: -1 + [15:01:54] pagesize: 4096 + [15:01:54] min stack size: -1 + [15:01:54]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_join/3-1: execution: UNRESOLVED: Output: + Error in pthread_testcancel(). Cancel request timed out. + : (os/kern) successful + conformance/interfaces/pthread_join/4-1: execution: UNTESTED: Output: + [15:02:06]System abilities: + [15:02:06] TSA: -1 + [15:02:06] TSS: -1 + [15:02:06] TPS: -1 + [15:02:06] pagesize: 4096 + [15:02:06] min stack size: -1 + [15:02:06]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_join/6-3: execution: UNTESTED: Output: + [15:02:07]System abilities: + [15:02:07] TSA: -1 + [15:02:07] TSS: -1 + [15:02:07] TPS: -1 + [15:02:07] pagesize: 4096 + [15:02:07] min stack size: -1 + [15:02:07]File conformance/interfaces/pthread_join/threads_scenarii.c cannot test: The min stack size is not a multiple of the page size + conformance/interfaces/pthread_key_create/2-1: execution: INTERRUPTED: Output: + 2-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/hurd/pt-getspecific.c:30: pthread_getspecific: Assertion `key < __pthread_key_count' failed. + conformance/interfaces/pthread_kill/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/7-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_kill/8-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_getprioceiling/1-1: execution: FAILED: Output: + Test FAILED: Error obtaining the priority ceiling + +Another system crash, due to conformance/interfaces/pthread_mutex_init/5-1: + + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + (default pager): dropping data_request because of previous paging errors + +Disable the panic-causing test (conformance/interfaces/pthread_mutex_init/5-1) +and restart: + + conformance/interfaces/pthread_mutex_init/speculative/5-2: execution: UNTESTED: Output: + Implementation is: + GNU + 0.3 + GNU-Mach 1.3.99/Hurd-0.3 + This implementation is not tested yet + conformance/interfaces/pthread_mutex_timedlock/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_timedlock/5-2: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutex_trylock/4-3: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_mutexattr_getprioceiling/1-1: execution: UNRESOLVED: Output: + Error obtaining the attribute process-shared + conformance/interfaces/pthread_mutexattr_getprioceiling/1-2: execution: UNRESOLVED: Output: + Error setting prioceiling to -1 + conformance/interfaces/pthread_mutexattr_getprioceiling/3-1: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_getprotocol/1-2: execution: UNRESOLVED: Output: + Error setting protocol to 1 + conformance/interfaces/pthread_mutexattr_getpshared/1-2: execution: UNRESOLVED: Output: + Error in pthread_mutexattr_setpshared(), error: 1073741942 + conformance/interfaces/pthread_mutexattr_gettype/speculative/3-1: execution: FAILED: Output: + Test FAILED: Incorrect return code. Expected EINVAL, but got: 0 + conformance/interfaces/pthread_mutexattr_setprioceiling/1-1: execution: FAILED: Output: + Test FAILED: Error setting prioceiling to -1 + conformance/interfaces/pthread_mutexattr_setprioceiling/3-1: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_setprioceiling/3-2: execution: FAILED: Output: + Test FAILED: Invalid return code 1073741902. Expected EINVAL or 0. + conformance/interfaces/pthread_mutexattr_setprotocol/1-1: execution: UNRESOLVED: Output: + Error setting protocol to 1 + conformance/interfaces/pthread_mutexattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Cannot set pshared attribute to PTHREAD_PROCESS_SHARED. Error code: 1073741942 + conformance/interfaces/pthread_mutexattr_setpshared/2-2: execution: FAILED: Output: + Test FAILED: Expected return code 0, got: 1073741942 + conformance/interfaces/pthread_rwlock_rdlock/2-1: execution: FAILED: Output: + main: has priority: 1 + main: attempt read lock + main: acquired read lock + main: create wr_thread, with priority: 0 + wr_thread: attempt write lock + main: create rd_thread, with priority: -1 + rd_thread: attempt read lock + rd_thread: acquired read lock + rd_thread: unlock read lock + Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and a higher priority writer is waiting for the lock + conformance/interfaces/pthread_rwlock_rdlock/2-2: execution: FAILED: Output: + main: attempt read lock + main: acquired read lock + main: create wr_thread, with priority: 0 + wr_thread: attempt write lock + main: create rd_thread, with priority: 0 + rd_thread: attempt read lock + rd_thread: acquired read lock + rd_thread: unlock read lock + Test FAILED: rd_thread did not block on read lock, when a reader owns the lock, and an equal priority writer is waiting for the lock + conformance/interfaces/pthread_rwlock_unlock/3-1: execution: FAILED: Output: + main: write lock + main: create writer1, with priority: 1 + writer1: attempt write lock + main: create reader, with priority: 1 + reader: attempt read lock + main: create writer2, with priority: -1 + writer2: attempt write lock + main: release write lock + writer2: acquired writer lock + Test fail: writer did not get write lock, when main release the lock + conformance/interfaces/pthread_rwlock_unlock/4-1: execution: INTERRUPTED: Output: + 4-1.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed. + conformance/interfaces/pthread_rwlock_unlock/4-2: execution: INTERRUPTED: Output: + 4-2.test: /var/tmp/hurd-20090404/./libpthread/sysdeps/generic/pt-rwlock-unlock.c:34: pthread_rwlock_unlock: Assertion `__pthread_spin_trylock (&rwlock->__held) == ((0x10 << 26) | ((16) & 0x3fff))' failed. + main: attempt read lock + main: acquired read lock + main: create un_thread + un_thread: unlock read lock + conformance/interfaces/pthread_rwlock_wrlock/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_rwlockattr_getpshared/2-1: execution: UNRESOLVED: Output: + Error at pthread_rwlockattr_setpshared() + conformance/interfaces/pthread_rwlockattr_setpshared/1-1: execution: FAILED: Output: + Test FAILED: Error at pthread_rwlockattr_setpshared(), return error: 1073741942 + conformance/interfaces/pthread_setschedparam/1-1: execution: FAILED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_setschedparam/1-2: execution: UNTESTED: Output: + [08:51:19]File conformance/interfaces/pthread_setschedparam/1-2.c cannot test: Failed to get min SCHED_RR range + conformance/interfaces/pthread_setschedparam/4-1: execution: UNRESOLVED: Output: + [08:51:20]Test conformance/interfaces/pthread_setschedparam/4-1.c unresolved: got 1073741902 (Function not implemented) on line 132 (Failed to set thread policy -- need to be root?) + conformance/interfaces/pthread_setschedparam/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_setschedprio/1-1: execution: UNRESOLVED: Output: + Error at pthread_setschedparam: rc=1073741902 + conformance/interfaces/pthread_sigmask/10-1: execution: FAILED: Output: + FAIL: SIGKILL was added to the signal mask + Test FAILED + conformance/interfaces/pthread_sigmask/18-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/4-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/5-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_sigmask/6-1: execution: HUNG: Output: + conformance/interfaces/pthread_sigmask/9-1: execution: INTERRUPTED: Output: + conformance/interfaces/pthread_spin_lock/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/sched_get_priority_max/1-1: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/1-2: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/1-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_get_priority_max/1-4: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_max/2-1: execution: FAILED: Output: + error is not EINVAL: Function not implemented + conformance/interfaces/sched_get_priority_min/1-1: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/1-2: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/1-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_get_priority_min/1-4: execution: FAILED: Output: + An error occurs: Function not implemented + conformance/interfaces/sched_get_priority_min/2-1: execution: FAILED: Output: + error is not EINVAL: Function not implemented + conformance/interfaces/sched_getparam/1-1: execution: FAILED: Output: + Return code is not zero. + conformance/interfaces/sched_getparam/2-1: execution: FAILED: Output: + Different results between pid == 0 and pid == getpid(). + conformance/interfaces/sched_getparam/3-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getparam/4-1: execution: FAILED: Output: + errno is not ESRCH: Function not implemented + conformance/interfaces/sched_getparam/6-1: execution: UNRESOLVED: Output: + errno is not EPERM: The system allows a non-rootuser to use sched_getparam(): Function not implemented + conformance/interfaces/sched_getparam/speculative/7-1: execution: UNRESOLVED: Output: + sched_getparam() return -1 and sets errno == 1073741902. + conformance/interfaces/sched_getscheduler/1-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getscheduler/2-1: execution: UNTESTED: Output: + Will not test the behavior of sched_getscheduler() when pid is negative + because it is unspecified. + conformance/interfaces/sched_getscheduler/3-1: execution: FAILED: Output: + Returned code is -1. + conformance/interfaces/sched_getscheduler/4-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_getscheduler/7-1: execution: FAILED: Output: + errno is not EPERM: Function not implemented + conformance/interfaces/sched_rr_get_interval/1-1: execution: FAILED: Output: + Unexpected error: Function not implemented + conformance/interfaces/sched_rr_get_interval/2-1: execution: FAILED: Output: + interval.tv_sec not updated. + conformance/interfaces/sched_rr_get_interval/3-1: execution: FAILED: Output: + Returned error is not ESRCH: Function not implemented + conformance/interfaces/sched_rr_get_interval/speculative/5-1: execution: UNRESOLVED: Output: + sched_rr_get_interval() return -1 and sets errno == 1073741902. + conformance/interfaces/sched_setparam/1-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/10-1: execution: UNRESOLVED: Output: + An error occurs when calling shmget(): Invalid argument + conformance/interfaces/sched_setparam/12-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/13-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/14-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setparam/15-1: execution: UNTESTED: Output: + Will not test the effects of the sched_ss_low_priority, + sched_ss_repl_period, and sched_ss_init_budget members when the scheduling + policy of the target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. + It is implementation-defined. + conformance/interfaces/sched_setparam/16-1: execution: UNTESTED: Output: + Will not test the result of sched_setparam when the scheduling policy of the + target process is not SCHED_FIFO, SCHED_RR, or SCHED_SPORADIC. + It is implementation-defined. + conformance/interfaces/sched_setparam/17-1: execution: UNTESTED: Output: + Will not test that sched_setparam have no effect on the scheduling of threads + with system scheduling contention scope. + conformance/interfaces/sched_setparam/18-1: execution: UNTESTED: Output: + Will not test that the threads scheduling policy and associated parameters + are not affected. + conformance/interfaces/sched_setparam/19-1: execution: UNTESTED: Output: + Will not test that the underlying kernel-scheduled entities for the system + contention scope threads are not be affected by this sched_setparam(). + conformance/interfaces/sched_setparam/2-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_setscheduler(): Function not implemented + conformance/interfaces/sched_setparam/2-2: execution: UNRESOLVED: Output: + An error occurs when calling sched_setscheduler(): Function not implemented + conformance/interfaces/sched_setparam/22-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-5: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/23-6: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/23-7: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/25-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getscheduler(): Function not implemented + conformance/interfaces/sched_setparam/25-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setparam/26-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/27-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/3-1: execution: UNTESTED: Output: + Will not test the behavior of sched_setparam() when pid is negative because + it is unspecified. + conformance/interfaces/sched_setparam/5-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setparam/6-1: execution: UNTESTED: Output: + Will not test the conditions under which one process has permission to + change the scheduling parameters of another process, because they are + implementation-defined. + conformance/interfaces/sched_setparam/7-1: execution: UNTESTED: Output: + Will not test that implementations may require the requesting process to + have the appropriate privilege to set its own scheduling parameters or those + of another process. + conformance/interfaces/sched_setparam/8-1: execution: UNTESTED: Output: + Will not test that the target process is moved to the tail of the thread + list for its priority when it is running. + conformance/interfaces/sched_setparam/9-1: execution: UNRESOLVED: Output: + An error occurs when calling shmget(): Invalid argument + conformance/interfaces/sched_setscheduler/1-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + Error calling sched_setscheduler() for SCHED_FIFO policy + Policy: SCHED_RR + Error calling sched_setscheduler() for SCHED_RR policy + Policy: SCHED_OTHER + Error calling sched_setscheduler() for SCHED_OTHER policy + conformance/interfaces/sched_setscheduler/10-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setscheduler/11-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sched_setscheduler/12-1: execution: UNTESTED: Output: + Will not test that sched_setscheduler have no effect on the scheduling of + threads with system scheduling contention scope. + conformance/interfaces/sched_setscheduler/13-1: execution: UNTESTED: Output: + Will not test that the threads scheduling policy and associated parameters + are not affected. + conformance/interfaces/sched_setscheduler/14-1: execution: UNTESTED: Output: + Will not test that the underlying kernel-scheduled entities for the system + contention scope threads are not be affected by sched_setscheduler(). + conformance/interfaces/sched_setscheduler/15-1: execution: UNSUPPORTED: Output: + Process contention scope threads are not supported. + conformance/interfaces/sched_setscheduler/16-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getscheduler(): Function not implemented + conformance/interfaces/sched_setscheduler/17-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/17-5: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-6: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/17-7: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/19-1: execution: UNRESOLVED: Output: + Policy: SCHED_FIFO + An error occurs when calling sched_get_priority_max(): Function not implemented + conformance/interfaces/sched_setscheduler/19-2: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-3: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-4: execution: UNSUPPORTED: Output: + Does not support SS (SPORADIC SERVER) + conformance/interfaces/sched_setscheduler/19-5: execution: FAILED: Output: + Unknow error: Function not implemented + conformance/interfaces/sched_setscheduler/2-1: execution: UNTESTED: Output: + Will not test the behavior of sched_setscheduler() when pid is negative + because it is unspecified. + conformance/interfaces/sched_setscheduler/20-1: execution: FAILED: Output: + errno is not EPERM: Function not implemented + conformance/interfaces/sched_setscheduler/21-1: execution: FAILED: Output: + errno is not ESRCH: Function not implemented + conformance/interfaces/sched_setscheduler/4-1: execution: UNRESOLVED: Output: + An error occurs when calling sched_getparam(): Function not implemented + conformance/interfaces/sched_setscheduler/5-1: execution: UNTESTED: Output: + Will not test the condition under which one process has the appropriate + privilege to change the scheduling parameters of another process because + they are implementation-defined. + conformance/interfaces/sched_setscheduler/6-1: execution: UNTESTED: Output: + Will not test that implementations may require that the requesting process + have permission to set its own scheduling parameters or those of another + process. + conformance/interfaces/sched_setscheduler/7-1: execution: UNTESTED: Output: + Will not test if implementation-defined restrictions apply as to the + appropriate privileges required to set a process' own scheduling policy, or + another process' scheduling policy, to a particular value. + conformance/interfaces/sched_setscheduler/9-1: execution: UNTESTED: Output: + Not yet tested. + conformance/interfaces/sem_close/1-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 1-1: sem_open: Operation not supported + conformance/interfaces/sem_close/2-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 2-1: sem_open: Operation not supported + conformance/interfaces/sem_close/3-1: execution: INTERRUPTED: Output: + unexpected error: sem_close 3-1: sem_open: Operation not supported + conformance/interfaces/sem_close/3-2: execution: UNRESOLVED: Output: + [08:56:54]Test conformance/interfaces/sem_close/3-2.c unresolved: got 1073741869 (Operation not supported) on line 113 (Failed to create the semaphore) + conformance/interfaces/sem_getvalue/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 1-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 2-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/4-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 4-1: sem_open: Operation not supported + conformance/interfaces/sem_getvalue/5-1: execution: UNRESOLVED: Output: + unexpected error: sem_getvalue 5-1: sem_open: Operation not supported + conformance/interfaces/sem_init/3-2: execution: UNRESOLVED: Output: + [08:56:59]Test conformance/interfaces/sem_init/3-2.c unresolved: got 1073741869 (Operation not supported) on line 135 (Failed to init the semaphore) + conformance/interfaces/sem_init/3-3: execution: UNRESOLVED: Output: + [08:57:00]Test conformance/interfaces/sem_init/3-3.c unresolved: got 1073741869 (Operation not supported) on line 134 (Failed to init the semaphore) + conformance/interfaces/sem_init/7-1: execution: UNTESTED: Output: + [08:57:01]sysconf( _SC_SEM_NSEMS_MAX ) = -1 + [08:57:01]File conformance/interfaces/sem_init/7-1.c cannot test: There is no constraint on SEM_NSEMS_MAX + conformance/interfaces/sem_open/1-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/1-3: execution: UNRESOLVED: Output: + unexpected error: sem_open 1-3: sem_open: Operation not supported + conformance/interfaces/sem_open/1-4: execution: UNRESOLVED: Output: + unexpected error: sem_open 1-4: sem_open: Operation not supported + conformance/interfaces/sem_open/10-1: execution: UNRESOLVED: Output: + unexpected error: sem_open 10-1: sem_open: Operation not supported + conformance/interfaces/sem_open/15-1: execution: UNRESOLVED: Output: + [08:57:03]Test conformance/interfaces/sem_open/15-1.c unresolved: got 1073741869 (Operation not supported) on line 106 (Failed to sem_open) + conformance/interfaces/sem_open/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_open 2-1: sem_open: Operation not supported + conformance/interfaces/sem_open/2-2: execution: UNRESOLVED: Output: + unexpected error: sem_open 2-2: sem_open: Operation not supported + conformance/interfaces/sem_open/3-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/4-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_open/6-1: execution: FAILED: Output: + TEST FAILED + conformance/interfaces/sem_post/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 1-1: sem_open: Operation not supported + conformance/interfaces/sem_post/1-2: execution: UNRESOLVED: Output: + unexpected error: sem_post 1-2: sem_open: Operation not supported + conformance/interfaces/sem_post/2-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 2-1: sem_open: Operation not supported + conformance/interfaces/sem_post/4-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 4-1: sem_open: Operation not supported + conformance/interfaces/sem_post/5-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 5-1: sem_open: Operation not supported + conformance/interfaces/sem_post/6-1: execution: UNRESOLVED: Output: + unexpected error: sem_post 6-1: sem_open: Operation not supported + conformance/interfaces/sem_post/8-1: execution: UNTESTED: Output: + _POSIX_PRIORITY_SCHEDULING not defined + conformance/interfaces/sem_timedwait/9-1: execution: FAILED: Output: + In handler + TEST FAILED: errno != EINTR + conformance/interfaces/sem_unlink/1-1: execution: INTERRUPTED: Output: + unexpected error: sem_unlink 1-1: sem_open: Operation not supported + conformance/interfaces/sem_unlink/2-1: execution: INTERRUPTED: Output: + unexpected error: sem_unlink 2-1: sem_open: Operation not supported + conformance/interfaces/sem_unlink/2-2: execution: UNRESOLVED: Output: + [08:57:23]Test conformance/interfaces/sem_unlink/2-2.c unresolved: got 1073741869 (Operation not supported) on line 158 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/3-1: execution: UNRESOLVED: Output: + [08:57:23]Test conformance/interfaces/sem_unlink/3-1.c unresolved: got 1073741869 (Operation not supported) on line 156 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/4-1: execution: FAILED: Output: + TEST FAILED: semaphore does exist + conformance/interfaces/sem_unlink/4-2: execution: FAILED: Output: + [08:57:24]Error 1073741869: Operation not supported + [08:57:24]Test conformance/interfaces/sem_unlink/4-2.c FAILED: The error was not ENOENT + conformance/interfaces/sem_unlink/6-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/6-1.c unresolved: got 1073741869 (Operation not supported) on line 107 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/7-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/7-1.c unresolved: got 1073741869 (Operation not supported) on line 126 (Failed to create the semaphore) + conformance/interfaces/sem_unlink/9-1: execution: UNRESOLVED: Output: + [08:57:25]Test conformance/interfaces/sem_unlink/9-1.c unresolved: got 1073741869 (Operation not supported) on line 133 (Failed to create the semaphore) + conformance/interfaces/sem_wait/1-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 1-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/1-2: execution: UNRESOLVED: Output: + unexpected error: sem_wait 2-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/11-1: execution: UNRESOLVED: Output: + unexpected error: sem_trywait 11-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/12-1: execution: INTERRUPTED: Output: + unexpected error: sem_trywait 12-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/3-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 3-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/5-1: execution: INTERRUPTED: Output: + unexpected errno: sem_trywait 5-1: sem_open: Operation not supported + conformance/interfaces/sem_wait/7-1: execution: UNRESOLVED: Output: + unexpected error: sem_wait 7-1: sem_open: Operation not supported + conformance/interfaces/shm_open/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/10-1: execution: UNTESTED: Output: + Will not test whether the file offset is set because it is unspecified. + conformance/interfaces/shm_open/12-1: execution: UNTESTED: Output: + Will not test the behavior of implementation when an application does not + specify exactly one of two values: O_RDONLY and O_RDWR. + conformance/interfaces/shm_open/14-2: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/19-1: execution: UNTESTED: Output: + Will not test the effect of calling shm_open() when the shared memory object + does not exists, the O_CREAT flags is set, and bits in mode other than the + file permission bits are set. It is unspecified. + conformance/interfaces/shm_open/2-1: execution: UNTESTED: Output: + Will not test that the shm_open() function create an open file description + that refers to the shared memory object and a file descriptor that refers to + conformance/interfaces/shm_open/23-1: execution: UNRESOLVED: Output: + error at sem_open: Operation not supported + conformance/interfaces/shm_open/24-1: execution: UNTESTED: Output: + Will not test the result of shm_open() when O_EXCL is set and O_CREAT is not + set because it is undefined. + conformance/interfaces/shm_open/26-2: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/shm_open/27-1: execution: UNTESTED: Output: + Will not test the result of shm_open() when using O_TRUNC with O_RDONLY. + It is undefined. + conformance/interfaces/shm_open/28-1: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/28-3: execution: INTERRUPTED: Output: + conformance/interfaces/shm_open/29-1: execution: UNTESTED: Output: + Will not test whether the name and shared memory object state remain valid + after a system reboot. It is unspecified. + conformance/interfaces/shm_open/3-1: execution: UNTESTED: Output: + Will not test whether the name appears in the file system and is visible to + other functions that take pathnames as arguments because it is unspecified. + conformance/interfaces/shm_open/36-1: execution: UNTESTED: Output: + It is very difficult to test that the shm_open() function sets errno = EINTR + when it is interrupted by a signal. + conformance/interfaces/shm_open/37-1: execution: FAILED: Output: + Name: '[GARBAGE]' + OK: open with success. + Name: '[GARBAGE]' + OK: open with success. + Name: '..' + Unexpected error: Is a directory + Name: '/' + OK: errno == EINVAL + Name: '//' + OK: errno == EINVAL + Name: '/abc' + OK: open with success. + Test FAILED + conformance/interfaces/shm_open/39-2: execution: UNRESOLVED: Output: + An error occurs when calling pathconf(): Invalid argument + conformance/interfaces/shm_open/42-1: execution: UNTESTED: Output: + Will not test that the shm_open() function sets errno to ENOSPC if there is + insufficient space for the creation of the new shared memory object. + conformance/interfaces/shm_open/5-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/shm_open/6-1: execution: UNTESTED: Output: + Will not test the effect of a name which does not begin with the slash + character because it is implementation-defined. + conformance/interfaces/shm_open/7-1: execution: UNTESTED: Output: + Will not test the interpretation of slash characters other than the leading + slash character in name because it is implementation-defined. + conformance/interfaces/shm_open/9-1: execution: UNTESTED: Output: + Will not test that the open file description is new. + conformance/interfaces/shm_unlink/10-2: execution: UNRESOLVED: Output: + An error occurs when calling pathconf(): Invalid argument + conformance/interfaces/shm_unlink/8-1: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/shm_unlink/9-1: execution: UNRESOLVED: Output: + You don't have permission to change your UID. + Try to rerun this test as root. + conformance/interfaces/sigaction/4-37: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-23: execution: FAILED: Output: + Caught SIGURG + Test FAILED + conformance/interfaces/sigaction/12-41: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-4: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-28: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-26: execution: FAILED: Output: + Caught SIGXFSZ + Test FAILED + conformance/interfaces/sigaction/12-49: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-8: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-45: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-18: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-42: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-15: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-25: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-7: execution: FAILED: Output: + Caught SIGHUP + Test FAILED + conformance/interfaces/sigaction/4-48: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-23: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-34: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-24: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-43: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-22: execution: FAILED: Output: + Caught SIGTRAP + Test FAILED + conformance/interfaces/sigaction/12-31: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-35: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-46: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-7: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-34: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-3: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-52: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-30: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-51: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-13: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-36: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-21: execution: FAILED: Output: + Caught SIGSYS + Test FAILED + conformance/interfaces/sigaction/17-11: execution: FAILED: Output: + Caught SIGQUIT + Test FAILED + conformance/interfaces/sigaction/4-38: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-47: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-30: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-44: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-50: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-27: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-20: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-40: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-19: execution: FAILED: Output: + Caught SIGPOLL + Test FAILED + conformance/interfaces/sigaction/12-16: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-51: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-21: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-1: execution: FAILED: Output: + Caught SIGABRT + Test FAILED + conformance/interfaces/sigaction/4-32: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-12: execution: FAILED: Output: + Caught SIGSEGV + Test FAILED + conformance/interfaces/sigaction/12-52: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-10: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-36: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-9: execution: FAILED: Output: + Caught SIGINT + Test FAILED + conformance/interfaces/sigaction/4-47: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-11: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-10: execution: FAILED: Output: + Caught SIGPIPE + Test FAILED + conformance/interfaces/sigaction/12-5: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-48: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-19: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-46: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-17: execution: FAILED: Output: + Caught SIGUSR1 + Test FAILED + conformance/interfaces/sigaction/12-14: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-14: execution: FAILED: Output: + Caught SIGTSTP + Test FAILED + conformance/interfaces/sigaction/17-18: execution: FAILED: Output: + Caught SIGUSR2 + Test FAILED + conformance/interfaces/sigaction/4-41: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-43: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-28: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-6: execution: FAILED: Output: + Caught SIGFPE + Test FAILED + conformance/interfaces/sigaction/4-45: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-35: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-6: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-29: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-16: execution: FAILED: Output: + Caught SIGTTOU + Test FAILED + conformance/interfaces/sigaction/4-39: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-29: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-9: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-25: execution: FAILED: Output: + Caught SIGXCPU + Test FAILED + conformance/interfaces/sigaction/17-4: execution: FAILED: Output: + Caught SIGCHLD + Test FAILED + conformance/interfaces/sigaction/12-22: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-13: execution: FAILED: Output: + Caught SIGTERM + Test FAILED + conformance/interfaces/sigaction/4-31: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-38: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-12: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-44: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/4-49: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-40: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-42: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-15: execution: FAILED: Output: + Caught SIGTTIN + Test FAILED + conformance/interfaces/sigaction/17-3: execution: FAILED: Output: + Caught SIGBUS + Test FAILED + conformance/interfaces/sigaction/12-2: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-5: execution: FAILED: Output: + Caught SIGCONT + Test FAILED + conformance/interfaces/sigaction/12-33: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-17: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-2: execution: FAILED: Output: + Caught SIGALRM + Test FAILED + conformance/interfaces/sigaction/12-37: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/17-20: execution: FAILED: Output: + Caught SIGPROF + Test FAILED + conformance/interfaces/sigaction/17-8: execution: FAILED: Output: + Caught SIGILL + Test FAILED + conformance/interfaces/sigaction/4-33: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/12-39: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-50: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/12-32: execution: INTERRUPTED: Output: + conformance/interfaces/sigaction/4-27: execution: FAILED: Output: + About to stop child + Child has continued + Test FAILED + conformance/interfaces/sigaction/17-24: execution: FAILED: Output: + Caught SIGVTALRM + Test FAILED + conformance/interfaces/sigaction/12-26: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/1-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/11-1: execution: FAILED: Output: + Test FAILED: Expected return value of -1. + conformance/interfaces/sigaltstack/12-1: execution: FAILED: Output: + Test FAILED: Expected return value of -1. + conformance/interfaces/sigaltstack/2-1: execution: FAILED: Output: + Test FAILED: ss_sp of the handler's stack changed even though SS_DISABLE was set + conformance/interfaces/sigaltstack/3-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/6-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigaltstack/7-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigpause/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/sigpending/1-2: execution: INTERRUPTED: Output: + Not all pending signals found + conformance/interfaces/sigpending/1-3: execution: INTERRUPTED: Output: + Error with send signals + Test FAILED + conformance/interfaces/sigqueue/10-1: execution: FAILED: Output: + sigqueue() failed on EINVAL but errno not set correctly + conformance/interfaces/sigqueue/11-1: execution: FAILED: Output: + sigqueue() failed on ESRCH but errno not set correctly + conformance/interfaces/sigqueue/12-1: execution: FAILED: Output: + sigqueue() failed but errno not set correctly + conformance/interfaces/sigqueue/2-1: execution: FAILED: Output: + Could not call sigqueue with sig = 0 + conformance/interfaces/sigqueue/2-2: execution: FAILED: Output: + sigqueue() failed on ESRCH but errno not set correctly + At least one test FAILED -- see output for status + conformance/interfaces/sigqueue/3-1: execution: FAILED: Output: + Test FAILED: EPERM error not received + conformance/interfaces/sigset/6-1: execution: UNRESOLVED: Output: + Unexpected error while using sigset(): (os/kern) successful + conformance/interfaces/sigset/7-1: execution: UNRESOLVED: Output: + Unexpected error while using sigset(): (os/kern) successful + conformance/interfaces/sigset/8-1: execution: FAILED: Output: + Test FAILED: sigset() didn't return SIG_HOLD + conformance/interfaces/sigsuspend/1-1: execution: UNRESOLVED: Output: + suspending child + SIGUSR2 called. Inside handler + parent sending child a SIGUSR2 signal + parent sending child a SIGUSR1 signal + Exit status from child is 1 + Test UNRESOLVED: Either sigsuspend did not successfully block SIGUSR2, OR sigsuspend returned before handling the signal SIGUSR1 + conformance/interfaces/sigtimedwait/1-1: execution: FAILED: Output: + Test FAILED: sigtimedwait() did not return in the required time + conformance/interfaces/sigtimedwait/4-1: execution: FAILED: Output: + Call to sigtimedwait() failed + : Function not implemented + conformance/interfaces/sigtimedwait/6-1: execution: FAILED: Output: + Test FAILED: sigtimedwait() did set errno to EAGAIN + conformance/interfaces/sigwait/1-1: execution: FAILED: Output: + Signal SIGALRM is not pending! + conformance/interfaces/sigwait/3-1: execution: FAILED: Output: + Test FAILED + conformance/interfaces/sigwait/6-1: execution: FAILED: Output: + [09:04:10]0 threads were awaken + [09:04:10]Test conformance/interfaces/sigwait/6-1.c FAILED: Unexpected number of threads awaken + conformance/interfaces/sigwaitinfo/1-1: execution: UNRESOLVED: Output: + Call to sigwaitinfo() failed + : Function not implemented + conformance/interfaces/sigwaitinfo/3-1: execution: FAILED: Output: + Call to sigwaitinfo() failed + : Function not implemented + Child calling sigwaitinfo() + parent sending child a SIGUSR1 signal + Exit status from child is 2 + Test FAILED + conformance/interfaces/sigwaitinfo/9-1: execution: FAILED: Output: + Call to sigwaitinfo() failed + : Function not implemented + conformance/interfaces/strftime/2-1: execution: INTERRUPTED: Output: + conformance/interfaces/timer_create/1-1: execution: FAILED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/10-1: execution: UNRESOLVED: Output: + sysconf(_SC_CPUTIME) returns: -1 + conformance/interfaces/timer_create/11-1: execution: UNSUPPORTED: Output: + rc = -1 + _POSIX_THREAD_CPUTIME unsupported + conformance/interfaces/timer_create/16-1: execution: FAILED: Output: + errno != EINVAL + Test FAILED + conformance/interfaces/timer_create/3-1: execution: FAILED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/7-1: execution: UNSUPPORTED: Output: + CLOCK_MONOTONIC unsupported + conformance/interfaces/timer_create/8-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/9-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/speculative/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_create/speculative/5-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_delete/speculative/5-1: execution: FAILED: Output: + timer_delete() returned -1, but didn't set errno!=EINVAL + conformance/interfaces/timer_delete/speculative/5-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/2-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/3-1: execution: UNTESTED: Output: + Cannot be tested as DELAYTIMER_MAX is too large. + DELAYTIMER_MAX is ffffffff + conformance/interfaces/timer_getoverrun/speculative/6-1: execution: FAILED: Output: + fcn returned -1, but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_getoverrun/speculative/6-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_getoverrun/speculative/6-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/1-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/2-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/3-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/speculative/6-1: execution: FAILED: Output: + fcn returned -1 but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_gettime/speculative/6-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_gettime/speculative/6-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/1-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/1-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/13-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/2-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/3-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/5-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/6-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/8-4: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/9-1: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/9-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/speculative/12-1: execution: FAILED: Output: + fcn returned -1, but errno!=EINVAL + Test FAILED + conformance/interfaces/timer_settime/speculative/12-2: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + conformance/interfaces/timer_settime/speculative/12-3: execution: UNRESOLVED: Output: + timer_create() did not return success + : Function not implemented + functional/threads/schedule/1-1: execution: UNRESOLVED: Output: + unexpected error: scheduler 5-4: pthread_attr_setschedpolicy + functional/threads/schedule/1-2: execution: UNRESOLVED: Output: + unexpected error: scheduler 5-5: pthread_setschedparam diff --git a/open_issues/open_symlink.mdwn b/open_issues/open_symlink.mdwn new file mode 100644 index 00000000..20e4a4fe --- /dev/null +++ b/open_issues/open_symlink.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2012 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, 2012-01-02 + + <pinotree> hm, is it a known issue that open("somesymlink", O_RDONLY | + O_NOFOLLOW) does not fail with ELOOP? + <youpi> pinotree: iirc there is code for it, maybe not the same behavior as + on linux diff --git a/open_issues/osf_mach.mdwn b/open_issues/osf_mach.mdwn new file mode 100644 index 00000000..d689bfcb --- /dev/null +++ b/open_issues/osf_mach.mdwn @@ -0,0 +1,237 @@ +[[!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_gnumach open_issue_hurd]] + +IRC, freenode, #hurd, 2011-09-07 + + <slpz> tschwinge: do you think that should be possible/convenient to + maintain hurd and glibc versions for OSF Mach as branches in the offical + git repo? + <tschwinge> Is OSF Mach the MkLinux one? + <slpz> Yes, it is + <tschwinge> slpz: If there's a suitable license, then yes, of course! + <tschwinge> Unless there is a proper upstream, of course. + <tschwinge> But I don't assume there is? + <tschwinge> slpz: What is interesting for us about OSF Mach? + <slpz> tschwinge: Peter Bruin and Jose Marchesi did a gnuified version some + time ago (gnu-osfmach), so I suppose the license is not a problem. But + I'm going to check it, though + <slpz> OSF Mach has a number of interesting features + <slpz> like migrating threads, advisory pageout, clustered pageout, kernel + loaded tasks, short circuited RPC... + <tschwinge> Oh! + <tschwinge> Good. + <slpz> right now I'm testing if it's really worth the effort + <tschwinge> Yes. + <tschwinge> But if the core codebase is the same (is it?) it may be + possible to merge some things? + <tschwinge> If the changes can be identified reasonably... + <slpz> comparing performance of the specialized RPC of OSF Mach with + generic IPC + <slpz> That was my first intention, but I think that porting all those + features will be much more work than porting Hurd/glibc to it + <braunr> slpz: ipc performance currently matters less than clustered + pageouts + <braunr> slpz: i'm really not sure .. + <braunr> i'd personnally adapt the kernel + <slpz> braunr: well, clustered pageouts is one of the changes that can be + easily ported + <slpz> braunr: We can consider OSF Mach code as reasonably stable, and + porting its features to GNU Mach will take us to the point of having to + debug all that code again + <slpz> probably, the hardest feature to be ported is migrating threads + <braunr> isn't that what was tried for gnu mach 2 ? or was it only about + oskit ? + <slpz> IIRC only oskit + <tschwinge> slpz: But there have been some advancements in GNU Mach, too. + For example the Xen port. + <tschwinge> But wen can experiment with it, of course. + <slpz> tschwinge: I find easier to move the Xen support from GNU Mach to + OSF Mach, than porting MT in the other direction + <tschwinge> slpz: And I think MkLinux is a single-server, so I don't this + they used IPC as much as we did? + <tschwinge> slpz: OK, I see. + <braunr> slpz: MT aren't as needed as clustered pageouts :p + <braunr> gnumach already has ipc handoff, so MT would just consume less + stack space, and only slightly improve raw ipc performance + <tschwinge> slpz: But we will surely accept patches that get the Hurd/glibc + ported to OSF Mach, no question. + <braunr> (it's required for other issues we discussed already, but not a + priority imo) + <slpz> tschwinge: MkLinux makes heavy use of IPC, but it tries to + "short-circuit" it when running as a kernel loaded task + <tschwinge> And it's obviously best to keep it in one place. Luckily it's + not CVS branches anymore... :-) + <slpz> braunr: well, I'm a bit obsessed with IPC peformance, if the RPC on + OSF Mach really makes a difference, I want it for Hurd right now + <slpz> braunr: clustered pages can be implemented at any time :-) + <slpz> tschwinge: great! + <tschwinge> slpz: In fact, haven'T there already been some Savannah + repositories created, several (five?) years ago? + <braunr> slpz: the biggest performance issue on the hurd is I/O + <braunr> and the easiest way to improve that is better VM transfers + <slpz> tschwinge: yes, the HARD project, but I think it wasn't too well + received... + <tschwinge> slpz: Quite some things changed since then, I'd say. + <slpz> braunr: I agree, but IPC is the hardest part to optimize + <slpz> braunr: If we have a fast IPC, the rest of improvements are way + easier + <braunr> slpz: i don't see how faster IPC makes I/O faster :( + <braunr> slpz: read + http://www.sceen.net/~rbraun/the_increasing_irrelevance_of_ipc_performance_for_microkernel_based_operating_systems.pdf + again :) + <slpz> braunr: IPC puts the upper limit of how fast I/O could be + <braunr> the abstract for my thesis on x15 mach was that the ipc code was + the most focused part of the kernel + <braunr> so my approach was to optimize everything *else* + <braunr> the improvements in UVM (and most notably clustered page + transfers) show global system improvements up to 30% in netbsd + <braunr> we should really focus on the VM first (which btw, is a pain in + the ass with the crappy panicking swap code in place) + <braunr> and then complete the I/O system + <slpz> braunr: If a system can't transfer data between translators faster + than 100 MB/s, faster devices doesn't make much sense + <guillem> has anyone considered switching the syscalls to use + sysenter/syscall instead of soft interrupts? + <slpz> braunr: but I agree on the VM part + <braunr> guillem: it's in my thesis .. but only there :) + <braunr> slpz: let's reach 100 MiB/s first, then improve IPC + <slpz> guillem: that's a must do, also moving to 64 bits :-) + <braunr> guillem: there are many tiny observations in it, like the use of + global page table entries, which was added by youpi around that time + <guillem> slpz: I wanted to fix all warnings first before sending my first + batch of 64 bit fixes, but I think I'll just send them after checking + they don't introduce regressions on i386 + <guillem> braunr: interesting I think I might have skimmed over your + thesis, maybe I should read it properly some time :) + <slpz> braunr: I see exactly as the opposite. First push IPC to its limit, + then improve devices/VM + <slpz> guillem: that's great :-) + <braunr> slpz: improving ipc now will bring *nothing*, whereas improving + vm/io now will make the system considerably more useable + <guillem> but then fixing 64-bit issues in the Linux code is pretty + annoying given that the latest code from upstream has that already fixed, + and we are “supposed” to drop the linux code from gnumach at some point + :) + <braunr> slpz: that's a basic principle in profiling, improve what brings + the best gains + <slpz> braunr: I'm not thinking about today, I'm thinking about how fast + Hurd could be when running on Mach. And, as I said, IPC is the absolute + upper limit. + <braunr> i'm really not convinced + <braunr> there are that many tasks making extensive use of IPCs + <braunr> most are cpu/IO bound + <slpz> but I have to acknowledge that this concern has been really + aliviated by the EPT improvement discovery + <braunr> there aren't* that many tasks + <slpz> braunr: create a ramdisk an write some files on it + <slpz> braunr: there's no I/O in that case, an performance it's really low + too + <braunr> well, ramdisks don't even work correctly iirc + <slpz> I must say that I consider improvements in OOL data moving as if it + were in IPC itself + <slpz> braunr: you can simulate one with storeio + <braunr> slpz: then measure what's slow + <braunr> slpz: it couldn't simply be the vm layer + <slpz> braunr: + http://www.gnu.org/s/hurd/hurd/libstore/examples/ramdisk.html + <braunr> ok, it's not a true ramdisk + <braunr> it's a stack of a ramdisk and extfs servers + <braunr> ext2fs* + <braunr> i was thinking about tmpfs + <slpz> True, but one of Hurd main advantages is the ability of doing that + kind of things + <slpz> so they must work with a reasonable performance + <braunr> other systems can too .. + <braunr> anyway + <braunr> i get your point, you want faster IPCs, like everyone does + <slpz> braunr: yes, and I also want to know how fast could be, to have a + reference when profiling complex services + <antrik> slpz: really improving IPC performance probably requires changing + the semantics... but we don't know which semantics we want until we have + actually tried fixing the existing bottlenecks + <antrik> well, not only bottlenecks... also other issues such as resource + management + <slpz> antrik: I think fixing bottlenecks would probably require changes in + some Mach interfaces, not in the IPC subsystem + <slpz> antrik: I mean, IPC semantics just provide the basis for messaging, + I don't think we will need to change them further + <antrik> slpz: right, but only once we have addressed the bottlenecks (and + other major shortcomings), we will know how the IPC mechanisms needs to + change to get further improvements... + <antrik> of course improving Mach IPC performance is interesting too -- if + nothing else, then to see how much of a difference it really makes... I + just don't think it should be considered an overriding priority :-) + <youpi> slpz: I agree with braunr, I don't think improving IPC will bring + much on the short term + <youpi> the buildds are slow mostly because of bad VM + <youpi> like lack of read-ahead, the randomness of object cache pageout, + etc. + <youpi> that doesn't mean IPC shouldn't be improved of course + <youpi> but we have a big margin for iow + <youpi> s/iow/now + <slpz> youpi: I agree with you and with braunr in that regard. I'm not + looking for an inmediate improvement, I just want to see how fast the IPC + (specially, OOL data transfers) could be. + <slpz> also, migrating threads will help to fix some problems related with + resource management + <antrik> slpz: BTW, what about Apple's Mach? isn't it essentialy OSF Mach + with some further improvements?... + <slpz> antrik: IPC is an area with very little room for improvement, so I + don't we will fix that bottlenecks by applying some changes there + <antrik> well, for large OOL transfers, the limiting facter is certainly + also VM rather than the thread model?... + <slpz> antrik: yes, but I think is encumbered with the APPLv2 license + <antrik> ugh + <slpz> antrik: for OOL transfers, VM plays a big role, but IPC also has + great deal of responsibility + <antrik> as for resource management, migrating threads do not really help + much IMHO, as they only affect CPU scheduling. memory usage is a much + more pressing issue + <antrik> BTW, I have thought about passive objects in the past, but didn't + reach any conclusion... so I'm a bit ambivalent about migrating threads + :-) + <slpz> As an example, in Hurd on GNU Mach, an io_read can't take advantage + from copy-on-write, as buffers from the translator always arrive outside + user's buffer + <slpz> antrik: well, I think cpu scheduling is a big deal ;-) + <slpz> antrik: and for memory management, until a better design is + implemented, some fixes could be applied to get us to the same level as a + monolithic kernel + <antrik> to get even close to monolithic systems, we need either a way to + account server resources used on client's behalf, or to make servers use + client-provided resources. both require changes in the IPC mechanism I + think... + <antrik> (though *if* we go for the latter option, the CPU scheduling + changes of migrating threads would of course be necessary, in addition to + any changes regarding memory management...) + <antrik> slpz: BTW, I didn't get the point about io_read and COW... + <slpz> antrik: AFAIK, the FS cache (which is our primary concern) in most + monolithic system is agnostic with respect the users, and only deals with + absolute numbers. In our case we can do almost the same by combining Mach + and pagers knowledege. + <antrik> slpz: my primary concern is that anything program having a hiccup + crashes the system... and I'm not sure this can be properly fixed without + working memory accounting + <antrik> (I guess in can be worked around to some extent by introducing + various static limits on processes... but I'm not sure how well) + <antrik> it can + <slpz> antrik: monolithic system also suffer that problem (remember fork + bombs) and it's "solved" by imposing static limits to user processes + (ulimit). + <slpz> antrik: we do have more problems due to port management, but I think + some degree of control can be archieved with a reasonably amount of + changes. + <antrik> slpz: in a client-server architecture static limits are much less + effective... that problem exists on traditional systems too, but only in + some specific cases (such as X server); while on a microkernel system + it's ubiquitous... that's why we need a *better* solution to this problem + to get anywhere close to monolithic systems diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..18f124b4 --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,212 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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 open_issue_glibc]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you + think about that? + <youpi> in the long term, that can't work with glibc + <youpi> because of the thread stub stuff + +[[libpthread_dlopen]], for example. + + <youpi> it's not really possible to keep synchronized + <youpi> because you have to decide which package you unpack first + <youpi> (when upgrading) + <tschwinge> Hmm, how is that different if two shared libraries are in one + package vs. two packages? It isn't atomic either way? Aren't sonames / + versioned library packages solving that? + <tschwinge> ... for incompatible forward changes? + <youpi> that'd be a mess to maintain + <youpi> Drepper doesn't have this constraint and thus adds members of + private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the + Hurd package? + <youpi> I'm not saying it's better to have libpthread in the Hurd package + <tschwinge> OK. + <youpi> I'm saying it's useless to package it separately when Drepper makes + everything to have us put it along glibc + <tschwinge> Then, to goal is to have it in glibc? + <tschwinge> OK. :-) + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to + switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least + for Debian purposese? + <youpi> for any port purpose + <tschwinge> Ack. + <youpi> provided you're using glibc, you're deemed to ship libpthread with + it + <youpi> because of the strong relations Drepper puts between them + <youpi> (just to remind: we already have bugs just because our current + libpthread isn't bound enough to glibc: dlopen()ing a library depending + on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread + isn't used + <pinotree> (would be nice to not have those issues anymore...) + <tschwinge> So -- what do we need to put it into glibc? We can make + libpthread a Git submodule (or move the code; but it's shared also for + Neal's viengoos, so perhaps the submodule is better?), plus some glibc + make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something + fundamental? + <youpi> I actually don't know what a git submodule permits :) + <youpi> looks like a good thing for this, yes + <tschwinge> Unfortunately I can't allocate much time at the moment to work + on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to + package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as + submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is + the responsibility of the libpthread: it gives a couple of .c files to be + shipped in libc.so) + + +# IRC, freenode, #hurd, 2012-04-21 + + <youpi> had you tried to build libpthread as a glibc addon? + <tschwinge> youpi: No, I only know about libpthread in Hurd build system, + and libpthread stand-alone (with the Auto* stuff that I added), but not + yet as a glibc add-on. + <youpi> k + <youpi> I'm trying it atm + <tschwinge> Oh, OK. + <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as + the pthread_threads assertion errors in threaded plugins + <youpi> (once I add forward.c, but that part should not be hard) + <pinotree> that means also less use of pthread-stubs^ + <pinotree> ? + <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used + by anybody? + <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and + come in the way when building in glibc + <youpi> pinotree: rid of pthread-stubs yes + <pinotree> \o/ + <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h? No idea + about that one, sorry. + <youpi> I'm talking about libpthread + <youpi> not glibc + <tschwinge> Oh. + <tschwinge> sysdeps/i386/bits/spin-lock.h:# define + __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0) + <tschwinge> Anyway, no idea about that either. + <youpi> that one is meant to be used with the spin-lock.h just below + <youpi> +-inline + <youpi> also, I guess signal/ was for the l4 port? + <tschwinge> youpi: I guess so. + <youpi> tschwinge: I have an issue with sysdeps pt files: + sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into + sysdeps/mach/hurd/pt-getspecific.c works + <youpi> we don't have a non-mach sysdeps directory? + <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only + "hurd", does sysdeps/hurd work? + <youpi> ah, right + <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or + in libpthread/sysdeps/mach/hurd?) + <youpi> pinotree: it worked, it was for libpthread + <youpi> good: I got libpthread built and forward working + + +## IRC, freenode, #hurd, 2012-04-23 + + <youpi> phew + <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils + no-add-needed issue + + +## IRC, freenode, #hurd, 2012-08-07 + + <tschwinge> Also, the Savannah hurd/glibc.git one does not/not yet include + libpthread. + <tschwinge> But that could easily be added as a Git submodule. + <tschwinge> youpi: To put libpthread into glibc it is literally enough to + make Savannah hurd/libpthread.git appear at [glibc]/libpthread? + <youpi> tschwinge: there are some patches needed in the rest of the tree + <youpi> see in debian, libpthread_clean.diff, tg-libpthread_depends.diff, + unsubmitted-pthread.diff, unsubmitted-pthread_posix_options.diff + <tschwinge> The libpthread in Debian glibc is + hurd/libpthread.git:b428baaa85c0adca9ef4884c637f289a0ab5e2d6 but with + 25260994c812050a5d7addf125cdc90c911ca5c1 »Store self in __thread variable + instead of threadvar« reverted (why?), [...] + +..., and 549aba4335946c26f2701c2b43be0e6148d27c09 »Fix libpthread.so symlink« +cherry-picked. + + <braunr> tschwinge: is there any plan to merge libpthread.git in glibc.git + upstream ? + <tschwinge> braunr, youpi: Has not yet been discussed with Roland, as far + as I know. + <youpi> has not + <youpi> libpthread.diff is supposed to be a verbatim copy of the repository + <youpi> and then there are a couple patches which don't (yet) make sense + upstream + + +# IRC, freenode, #hurd, 2012-11-16 + + <pinotree> *** $(common-objpfx)resolv/gai_suspend.o: uses + /usr/include/i386-gnu/bits/pthread.h + <pinotree> so the ones in the libpthread addon are not used... + <tschwinge> pinotree: The latter at leash should be useful information. + <pinotree> tschwinge: i'm afraid i didn't get you :) what are you referring + to? + <tschwinge> pinotree: s%leash%least -- what I mean was the it's actually a + real bug that not the in-tree libpthread addon include files are being + used. + <pinotree> tschwinge: ah sure -- basically, the stuff in + libpthread/sysdeps/generic are not used at all + <pinotree> (glibc only uses generic for glibc/sysdeps/generic) + <pinotree> tschwinge: i might have an idea how to fix it: moving the + contents from libpthread/sysdeps/generic to libpthread/sysdeps/pthread, + and that would depend on one of the latest libpthread patches i sent + + +# libihash + +## IRC, freenode, #hurd, 2012-11-16 + + <pinotree> also, libpthread uses hurd's ihash + <tschwinge> Yes, I already thought a little bit about the ihash thing. I + besically see two options: move ihash into glibc ((probably?) not as a + public interface, though), or have libpthread use of of the hash + implementations that surely are already present in glibc. + <tschwinge> My notes say: + <tschwinge> * include/inline-hashtab.h + <tschwinge> * locale/programs/simple-hash.h + <tschwinge> * misc/hsearch_r.c + <tschwinge> * NNS; cf. f46f0abfee5a2b34451708f2462a1c3b1701facd + <tschwinge> No idea whether they're equivalent/usable. + <pinotree> interesting + <tschwinge> And no immediate recollection what NNS is; + f46f0abfee5a2b34451708f2462a1c3b1701facd is not a glibc commit after all. + ;-) + <tschwinge> Oh, and: libiberty: `hashtab.c` + <pinotree> hmm, but then you would need to properly ifdef the libpthread + hash usage (iirc only for pthread keys) depending on whether it's in + glibc or standalone + <pinotree> but that shouldn't be an ussue, i guess + <pinotree> *issue + <tschwinge> No that'd be fine. + <tschwinge> My understanding is that the long-term goal (well, no so + long-term, actually) is to completely move libpthread into glibc. + <pinotree> ie have it buildable only ad glibc addon? + <tschwinge> Yes. + <tschwinge> No need for more than one mechanism for building it, I think. + <tschwinge> Hmm, this doesn't bring us any further: + https://www.google.com/search?q=f46f0abfee5a2b34451708f2462a1c3b1701facd + <pinotree> yay for acronyms ;) + <tschwinge> So, if someone figures out what NNS and this commit it are: one + beer. ;-) diff --git a/open_issues/page_cache.mdwn b/open_issues/page_cache.mdwn new file mode 100644 index 00000000..fd503fdc --- /dev/null +++ b/open_issues/page_cache.mdwn @@ -0,0 +1,79 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-11-28 + + <braunr> youpi: would you find it reasonable to completely disable the page + cache in gnumach ? + <braunr> i'm wondering if it wouldn't help make the system more stable + under memory pressure + <youpi> assuming cache=writeback in gnumach? + <youpi> because disabling the page cache will horribly hit performance + <braunr> no, it doesn't have anything to do with the host + <braunr> i'm not so sure + <braunr> while observing the slab allocator, i noticed our page cache is + not used that often + <youpi> eeh? + <youpi> apart from the damn 4000 limitation, I've seen it used + <youpi> (and I don't why it wouldn't be used) + <youpi> (e.g. for all parts of libc) + <youpi> ah, no, libc would be kept open by ext2fs + <braunr> taht's precisely because of the 4k limit + <youpi> but e.g. .o file emitted during make + <braunr> well, no + <youpi> well, see the summary I had posted some time ago, the 4k limit + makes it completely randomized + <youpi> and thus you lose locality + <braunr> yes + <youpi> but dropping the limit would just fix it + <braunr> that's my point + <youpi> which I had tried to do, and there were issues, you mentioned why + <youpi> and (as usual), I haven't had anyu time to have a look at the issue + again + <braunr> i'm just trying to figure out the pros and cons for having teh + current page cache implementation + <braunr> but are you saying you tried with a strict limit of 0 ? + <youpi> non, I'm saying I tried with no limit + <youpi> but then memory fills up + <braunr> yes + <youpi> so trying to garbage collect + <braunr> i tried that too, the system became unstable very quickly + <youpi> but refs don't falldown to 0, you said + <braunr> did i ? + <youpi> or maybe somebody else + <youpi> see the list archives + <braunr> that's possible + <braunr> i'd imagine someone like sergio lopez + <youpi> possibly + <youpi> somebody that knows memory stuff way better than me in any case + <braunr> youpi: i'm just wondering how much we'd loose by disabling the + page cache, and if we actually gain more stability (and ofc, if it's + worth it) + <youpi> no idea, measures will tell + <youpi> fixing the page cache shouldn't be too hard I believe, however + <youpi> you just need to know what you are doing, which I don't + <youpi> I do believe the cache is still at least a bit useful + <youpi> even if dumb because of randomness + <youpi> e.g. running make lib in the glibc tree gets faster on second time + <youpi> because the cache wouldbe filled at least randomly with glibc tree + stuff + <braunr> yes, i agree on that + <youpi> braunr: btw, the current stability is fine for the buildds + <youpi> restarting them every few days is ok + <youpi> so I'd rather keep the performance :) + <braunr> ok + + +# [[gnumach_page_cache_policy]] diff --git a/open_issues/pci_arbiter.mdwn b/open_issues/pci_arbiter.mdwn new file mode 100644 index 00000000..7730cee0 --- /dev/null +++ b/open_issues/pci_arbiter.mdwn @@ -0,0 +1,256 @@ +[[!meta copyright="Copyright © 2012 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]] + +For [[DDE]]/X.org/... + + +# IRC, freenode, #hurd, 2012-02-19 + + <youpi> antrik: we should probably add a gsoc idea on pci bus arbitration + <youpi> DDE is still experimental for now so it's ok that you have to + configure it by hand, but it should be automatic at some ponit + + +## IRC, freenode, #hurd, 2012-02-21 + + <braunr> i'm not familiar with the new gnumach interface for userspace + drivers, but can this pci enumerator be written with it as it is ? + <braunr> (i'm not asking for a precise answer, just yes - even probably - + or no) + <braunr> (idk or utsl will do as well) + <youpi> I'd say yes + <youpi> since all drivers need is interrupts, io ports and iomem + <youpi> the latter was already available through /dev/mem + <youpi> io ports through the i386 rpcs + <youpi> the changes provide both interrupts, and physical-contiguous + allocation + <youpi> it should be way enough + <braunr> youpi: ok + <braunr> youpi: thanks for the details :) + <antrik> braunr: this was mentioned in the context of the interrupt + forwarding interface... the original one implemented by zhengda isn't + suitable for a PCI server; but the ones proposed by youpi and tschwinge + would work + <antrik> same for the physical memory interface: the current implementation + doesn't allow delegation; but I already said that it's wrong + + +# IRC, freenode, #hurd, 2012-07-15 + + <bddebian> youpi: Oh, BTW, I keep meaning to ask you. Could sound be done + with dde or would there still need to be some kernel work? + <youpi> bddebian: we'd need a PCI arbitrer for that + <youpi> for now just one userland poking with PCI is fine + <youpi> but two can produce bonks + <bddebian> They can't use the same? + <youpi> that's precisely the matter + <youpi> they have to use the same + <youpi> and not poke with it themselves + <braunr> that's what an arbiter is for + <bddebian> OK, so if we don't have a PCI arbiter now, how do things like + netdde and video not collide currently? + <bddebian> s/netdde/network/ + <bddebian> or disk for that matter + <braunr> bddebian: ah currently, well currently, the network is the only + thing using the pci bus + <bddebian> How is that possible when I have a PCI video card and disk + controller? + <braunr> they are accessed through compatible means + <bddebian> I suppose one of the hardest parts is prioritization? + <braunr> i don't think it matters much, no + <youpi> bddebian: netdde and Xorg don't collide essentially because they + are not started at the same time (hopefully) + <bddebian> braunr: What do you mean it doesn't matter? + <braunr> bddebian: well the point is rather serializing access, we don't + need more + <braunr> do other systems actually schedule access to the pci bus ? + <bddebian> From what I am reading, yes + <braunr> ok + + +# IRC, freenode, #hurd, 2012-07-16 + + <antrik> youpi: the lack of a PCI arbiter is a problem, but I wounldn't + consider it a precondition for adding another userspace driver + class... it's up to the user to make sure he has only one class active, + or take the risk of not doing so... + <antrik> (plus, I suspect writing the arbiter is a smaller task than + implementing another DDE class anyways...) + <bddebian> Where would the arbiter need to reside, in gnumach? + <antrik> bddebian: kernel would be one possible place (with the advantage + of running both userspace and kernel drivers without the potential for + conflicts) + <antrik> but I think I would prefer a userspace server + <youpi> antrik: we'd rather have PCI devices automatically set up + <youpi> just like /dev/netdde is already set up for the user + <youpi> so you can't count on the user + <youpi> for the arbitrer, it could as well be userland, while still + interacting with the kernel for some devices + <youpi> we however "just" need to get disk drivers in userland to drop PCI + drivers from kernel, actually + + +# IRC, freenode, #hurd, 2012-07-17 + + <bddebian> youpi: So this PCI arbiter should be a hurd server? + <youpi> that'd be better + <bddebian> youpi: Is there anything existing to look at as a basis? + <youpi> no idea off-hand + <bddebian> I mean you couldn't take what netdde does and generalize it? + <youpi> netdde doesn't do any arbitration + + +# IRC, OFTC, #debian-hurd, 2012-07-19 + + <bdefreese> youpi: Well at some point if you ever have time I'd like to + understand better how you see the PCI architecture working in Hurd. + I.E. would you expect the server to do enumeration and arbitration? + <youpi> I'd expect both, yes, but that's probably to be discussed rather + with antrik, he's the one who took some time to think about it + <bdefreese> netdde uses libpciaccess currently, right? + <youpi> yes + <youpi> libpciaccess would have to be fixed into using the arbitrer + <youpi> (that'd fix xorg as well) + <bdefreese> Man, I am still a bit unclear on how this all interacting + currently.. :( + <youpi> currently it's not + <youpi> and it's just by luck that it doesn't break + <bdefreese> Long term xxxdde would use the new server, correct? + <youpi> (well, we are also sure that the gnumach enumeration comes always + before the netdde enumeration, and xorg is currently not started + automatically, so its enumeration is also always after that) + <youpi> yes + <youpi> the server would essentially provide an interface equivalent to + libpciaccess + <bdefreese> Right + <bdefreese> In general, where does the pci map get "stored"? In GNU/Linux, + is it all /proc based? + <youpi> what do you mean by "pci map" ? + <bdefreese> Once I have enumerated all of the buses and devices, does it + stay stored or is it just redone for every call to a pci device? + <youpi> in linux it's stored in the kernel + <youpi> the abritrator would store it itself + + +# IRC, freenode, #hurd, 2012-07-20 + + <bddebian> antrik: BTW, youpi says you are the one to talk to for design of + a PCI server :) + <antrik> oh, am I? + * antrik feels honoured :-) + <antrik> I guess it's true though: I *did* spent a little thought on + it... even mentioned something in my thesis IIRC + <antrik> there is one tricky aspect to it though, which I'm not sure how to + handle best: we need two different instances of libpciaccess + <bddebian> Why two instances of libpciaccess? + <antrik> one used by the PCI server to access the hardware directly (using + the existing port poking backend), and one using a new backend to access + our PCI server... + <braunr> bddebian: hum, both i guess ? + <bddebian> antrik: Why wouldn't the server access the hardware directly? I + thought libpciaccess was supposed to be generic on purpose? + <antrik> hm... guess I wasn't clear + <antrik> the point is that the PCI server should use the direct hardware + access backend of libpciaccess + <antrik> however, *clients* should use the PCI server backend of + libpciaccess + <antrik> I'm not sure backends can be selected at runtime... + <antrik> which might mean that we actually have to compile two different + versions of the library. erk. + <bddebian> So you are saying the pci server should itself use libpci access + rather than having it's own? + <antrik> admittedly, that's not the most fundamental design decision to + make ;-) + <antrik> bddebian: yes. no need to rewrite (or copy) this code... + <bddebian> Hmm + <antrik> actually that was the plan all along when I first suggested + implementing the register poking backend for libpciaccess + <bddebian> Hmm, not sure I like it but I am certainly in no position to + question it right now :) + <braunr> why don't you like it ? + <bddebian> I shouldn't need an Xorg specific library to access PCI on my OS + :) + <braunr> oh + <bddebian> Though I don't disagree that reinventing the wheel is a bit + tedious. :) + <antrik> bddebian: although it originates from X.Org, I don't think there + is anything about the library technically making it X-specific... + <braunr> yes that's my opinion too + <antrik> (well, there are some X-specific functions IIRC, but these do not + hurt the other functionality) + <bddebian> But what is there is api/abi breakage? :) + <bddebian> s/is/if/ + <antrik> BTW according to rdepends there appear to be a number of non-X + things using the library now + <pinotree> like, uhm, hurd + <antrik> yeah, that too... we are already using it for DDE + <pinotree> if you have deb-src lines in your sources.list, use the + grep-dctrl power: + <pinotree> grep-dctrl -sPackage -FBuild-Depends libpciaccess-dev + /var/lib/apt/lists/*_source_Sources | sort -u + <bddebian> I know we are using it for netdde. + <antrik> nice thing about it is that once we have the PCI server and an + appropriate backend for libpciaccess, the same netdde and X binaries + should work either with or without the PCI server + <bddebian> Then why have the server at all? + <braunr> it's the arbiter + <braunr> you can use the library directly only if you're the only user + <braunr> and what antrik means is that the interface should be the same for + both modes + <bddebian> Ugh, that is where I am getting confused + <bddebian> In that case shouldn't everything use libpciaccess and the PCI + server has to arbitrate the requests? + <braunr> bd ? + <braunr> bddebian: yes + <braunr> bddebian: but they use the indirect version of the library + <braunr> whereas the server uses the raw version + <bddebian> OK, I gotcha (I think) + <braunr> (but they both provide the same interface, so if you don't have a + pci server and you know you're the only user, the direct version can be + used) + <bddebian> But I am not sure I see the difference between creating a second + library or just moving the raw access to the PCI server :) + <braunr> uh, there is no difference in that + <braunr> and you shouldn't do it + <braunr> (if that's what antrik meant at least) + <braunr> if you can select the backend (raw or pci server) easily, then + stick to the same code base + <bddebian> That's where I struggle. In my worthless opinion, raw access + should be the OS job while indirect access would be the libraries + responsibility + <braunr> that's true + <braunr> but as an optimization, if an application is the only user, it can + directly use raw access + <bddebian> How would you know that? + <bddebian> I'm sorry if these are dumb questions + <braunr> hum, don't try to make this behaviour automatic + <braunr> it would be selected by the user through command line switches + <bddebian> But the OS itself uses PCI for things like disk access and + video, no? + <braunr> (it could be automatic but it makes things more complicated) + <braunr> you don't need an arbiter all the time + <braunr> i can't tell you more, wait for antrik to return + <braunr> i realize i might already have said some bullshit + <antrik> bddebian: well, you have a point there that once we have the + arbiter and use it for everthing, it isn't strictly useful to still have + the register poking in the library + <antrik> however, the code will remain in the library anyways, so we better + continue using it rather than introducing redundancy... + <antrik> but again, that's rather a side issue concerning the design of the + PCI server + <bddebian> antrik: Fair enough. :) So how would I even start on this? + <antrik> bddebian: actually, libpciaccess is a good starting point: + checking the API should give you a fairly good idea what functionality + the server needs to implement + <pinotree> (+1 on library (re)use) + <bddebian> antrik: KK + <antrik> sorry, I'm a bit busy right now... diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn new file mode 100644 index 00000000..ae05e128 --- /dev/null +++ b/open_issues/performance.mdwn @@ -0,0 +1,217 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]]."]]"""]] + +*Performance analysis* ([[!wikipedia Performance_analysis desc="Wikipedia +article"]]) deals with analyzing how computing resources are used for +completing a specified task. + +[[Profiling]] is one relevant tool. + +In [[microkernel]]-based systems, there is generally a considerable [[RPC]] +overhead. + +In a multi-server system, it is non-trivial to implement a high-performance +[[I/O System|community/gsoc/project_ideas/disk_io_performance]]. + +When providing [[faq/POSIX_compatibility]] (and similar interfaces) in an +environemnt that doesn't natively implement these interfaces, there may be a +severe performance degradation. For example, in this [[`fork` system +call|/glibc/fork]]'s case. + +[[Unit_testing]] can be used for tracking performance regressions. + +--- + + * [[Degradation]] + + * [[fork]] + + * [[IPC_virtual_copy]] + + * [[microbenchmarks]] + + * [[microkernel_multi-server]] + + * [[gnumach_page_cache_policy]] + + * [[metadata_caching]] + +--- + + +# IRC, freenode, #hurd, 2012-07-05 + + <braunr> the more i study the code, the more i think a lot of time is + wasted on cpu, unlike the common belief of the lack of performance being + only due to I/O + + +## IRC, freenode, #hurd, 2012-07-23 + + <braunr> there are several kinds of scalability issues + <braunr> iirc, i found some big locks in core libraries like libpager and + libdiskfs + <braunr> but anyway we can live with those + <braunr> in the case i observed, ext2fs, relying on libdiskfs and libpager, + scans the entire file list to ask for writebacks, as it can't know if the + pages are dirty or not + <braunr> the mistake here is moving part of the pageout policy out of the + kernel + <braunr> so it would require the kernel to handle periodic synces of the + page cache + <antrik> braunr: as for big locks: considering that we don't have any SMP + so far, does it really matter?... + <braunr> antrik: yes + <braunr> we have multithreading + <braunr> there is no reason to block many threads while if most of them + could continue + <braunr> -while + <antrik> so that's more about latency than throughput? + <braunr> considering sleeping/waking is expensive, it's also about + throughput + <braunr> currently, everything that deals with sleepable locks (both + gnumach and the hurd) just wake every thread waiting for an event when + the event occurs (there are a few exceptions, but not many) + <antrik> ouch + + +## [[!message-id "20121202101508.GA30541@mail.sceen.net"]] + + +## IRC, freenode, #hurd, 2012-12-04 + + <damo22> why do some people think hurd is slow? i find it works well even + under heavy load inside a virtual machine + <braunr> damo22: the virtual machine actually assists the hurd a lot :p + <braunr> but even with that, the hurd is a slow system + <damo22> i would have thought it would have the potential to be very fast, + considering the model of the kernel + <braunr> the design implies by definition more overhead, but the true cause + is more than 15 years without optimization on the core components + <braunr> how so ? + <damo22> since there are less layers of code between the hardware bare + metal and the application that users run + <braunr> how so ? :) + <braunr> it's the contrary actually + <damo22> VFS -> IPC -> scheduler -> device drivers -> hardware + <damo22> that is monolithic + <braunr> well, it's not really meaningful + <braunr> and i'd say the same applies for a microkernel system + <damo22> if the application can talk directly to hardware through the + kernel its almost like plugging directly into the hardware + <braunr> you never talk directly to hardware + <braunr> you talk to servers instead of the kernel + <damo22> ah + <braunr> consider monolithic kernel systems like systems with one big + server + <braunr> the kernel + <braunr> whereas a multiserver system is a kernel and many servers + <braunr> you still need the VFS to identify your service (and thus your + server) + <braunr> you need much more IPC, since system calls are "replaced" with RPC + <braunr> the scheduler is basically the same + <damo22> okay + <braunr> device drivers are similar too, except they run in thread context + (which is usually a bit heavier) + <damo22> but you can do cool things like report when an interrupt line is + blocked + <braunr> and there are many context switches between all that + <braunr> you can do all that in a monolithic kernel too, and faster + <braunr> but it's far more elegant, and (when well done) easy to do on a + microkernel based system + <damo22> yes + <damo22> i like elegant, makes coding easier if you know the basics + <braunr> there are only two major differences between a monolilthic kernel + and a multiserver microkernel system + * damo22 listens + <braunr> 1/ independence of location (your resources could be anywhere) + <braunr> 2/ separation of address spaces (your servers have their own + addresses) + <damo22> wow + <braunr> these both imply additional layers of indirection, making the + system as a whole slower + <damo22> but it would be far more secure though i suspect + <braunr> yes + <braunr> and reliable + <braunr> that's why systems like qnx were usually adopted for critical + tasks + <damo22> security and reliability are very important, i would switch to the + hurd if it supported all the hardware i use + <braunr> so would i :) + <braunr> but performance matters too + <damo22> not to me + <braunr> it should :p + <braunr> it really does matter a lot in practice + <damo22> i mean, a 2x slowdown compared to linux would not affect me + <damo22> if it had all the benefits we mentioned above + <braunr> but the hurd is really slow for other reasons than its additional + layers of indrection unfortunately + <damo22> is it because of lack of optimisation in the core code? + <braunr> we're working on these issues, but it's not easy and takes a lot + of time :p + <damo22> like you said + <braunr> yes + <braunr> and also because of some fundamental design choices related to the + microkernel back in the 80s + <damo22> what about the darwin system + <damo22> it uses a mach kernel? + <braunr> yes + <damo22> what is stopping someone taking the MIT code from darwin and + creating a monster free OS + <braunr> what for ? + <damo22> because it already has hardware support + <damo22> and a mach kernel + <braunr> in kernel drivers ? + <damo22> it has kernel extensions + <damo22> you can do things like kextload module + <braunr> first, being a mach kernel doesn't make it compatible or even + easily usable with the hurd, the interfaces have evolved independantly + <braunr> and second, we really do want more stuff out of the kernel + <braunr> drivers in particular + <damo22> may i ask why you are very keen to have drivers out of kernel? + <braunr> for the same reason we want other system services out of the + kernel + <braunr> security, reliability, etc.. + <braunr> ease of debugging + <braunr> the ability to restart drivers separately, without restarting the + kernel + <damo22> i see + + +# IRC, freenode, #hurd, 2012-09-13 + +{{$news/2011-q2#phoronix-3}}. + + <braunr> the phoronix benchmarks don't actually test the operating system + .. + <hroi_> braunr: well, at least it tests its ability to run programs for + those particular tasks + <braunr> exactly, it tests how programs that don't make much use of the + operating system run + <braunr> well yes, we can run programs :) + <pinotree> those are just cpu-taking tasks + <hroi_> ok + <pinotree> if you do a benchmark with also i/o, you can see how it is + (quite) slower on hurd + <hroi_> perhaps they should have run 10 of those programs in parallel, that + would test the kernel multitasking I suppose + <braunr> not even I/O, simply system calls + <braunr> no, multitasking is ok on the hurd + <braunr> and it's very similar to what is done on other systems, which + hasn't changed much for a long time + <braunr> (except for multiprocessor) + <braunr> true OS benchmarks measure system calls + <hroi_> ok, so Im sensing the view that the actual OS kernel architecture + dont really make that much difference, good software does + <braunr> not at all + <braunr> i'm only saying that the phoronix benchmark results are useless + <braunr> because they didn't measure the right thing + <hroi_> ok diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn new file mode 100644 index 00000000..1aaae4d2 --- /dev/null +++ b/open_issues/performance/degradation.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2011, 2012 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="Degradation of GNU/Hurd ``system performance''"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +[[!toc]] + + +# Email, [[!message-id "87mxg2ahh8.fsf@kepler.schwinge.homeip.net"]] (bug-hurd, 2011-07-25, Thomas Schwinge) + +> Building a certain GCC configuration on a freshly booted system: 11 h. +> Remove build tree, build it again (2nd): 12 h 50 min. Huh. Remove build +> tree, reboot, build it again (1st): back to 11 h. Remove build tree, build +> it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. + +IRC, freenode, #hurd, 2011-07-23: + + < antrik> tschwinge: yes, the system definitely gets slower with + time. after running for a couple of weeks, it needs at least twice as + long to open a new shell for example + < antrik> I don't know whether this is only related to swap usage, or there + are some serious fragmentation issues + < braunr> antrik: both could be induced by fragmentation + + +# During [[IPC_virtual_copy]] testing + +IRC, freenode, #hurd, 2011-09-02: + + <manuel> interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + <braunr> manuel: i observed the same behaviour + [...] + + +# IRC, freenode, #hurd, 2011-09-22 + +See [[/open_issues/resource_management_problems/pagers]], IRC, freenode, #hurd, +2011-09-22. + + +# [[ext2fs_page_cache_swapping_leak]] diff --git a/open_issues/performance/fork.mdwn b/open_issues/performance/fork.mdwn new file mode 100644 index 00000000..5ceb6455 --- /dev/null +++ b/open_issues/performance/fork.mdwn @@ -0,0 +1,37 @@ +[[!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 +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_hurd]] + +Our [[`fork` implementation|glibc/fork]] is nontrivial. + +To do: hard numbers. +[[Microbenchmarks]]? + + +# Windows / Cygwin + + * <http://www.google.com/search?q=cygwin+fork> + + * <http://www.redhat.com/support/wpapers/cygnus/cygnus_cygwin/architecture.html> + + In particular, *5.6. Process Creation*. + + * <http://archive.gamedev.net/community/forums/topic.asp?topic_id=360290> + + * <http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/how-cygheap-works.txt?cvsroot=src> + + > Cygwin has recently adopted something called the "cygwin heap". This is + > an internal heap that is inherited by forked/execed children. It + > consists of process specific information that should be inherited. So + > things like the file descriptor table, the current working directory, and + > the chroot value live there. + + * <http://www.perlmonks.org/?node_id=588994> diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn new file mode 100644 index 00000000..931fd0ee --- /dev/null +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -0,0 +1,39 @@ +[[!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 +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]] + +This one may be considered as a testcase for [[I/O system +optimization|community/gsoc/project_ideas/disk_io_performance]]. + +It is taken from the [[binutils testsuite|binutils]], +`ld/ld-elf/sec64k.exp`, where this +test may occasionally [[trigger a timeout|binutils#64ksec]]. It is +extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24. + + $ wget -O - http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz | xz -d | tar -x + $ cd test/ + $ \time ./ld-new.stripped -o dump dump?.o dump??.o + 0.00user 0.00system 2:46.11elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + +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. + +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 +`io_read` is being processed. Running the testee on GNU/Linux with strace +shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't +as slow as the Hurd's. + +As Samuel figured out later, this slowness may in fact be due to a Xen-specific +issue, see [[Xen_lseek]]. After the latter has been addressed, we can +re-evaluate this issue here. diff --git a/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz b/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz Binary files differnew file mode 100644 index 00000000..6d7c606c --- /dev/null +++ b/open_issues/performance/io_system/binutils_ld_64ksec/test.tar.xz diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn new file mode 100644 index 00000000..a3baf30d --- /dev/null +++ b/open_issues/performance/io_system/clustered_page_faults.mdwn @@ -0,0 +1,162 @@ +[[!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_hurd]] + +[[community/gsoc/project_ideas/disk_io_performance]]. + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-02-16 + + <braunr> exceptfor the kernel, everything in an address space is + represented with a VM object + <braunr> those objects can represent anonymous memory (from malloc() or + because of a copy-on-write) + <braunr> or files + <braunr> on classic Unix systems, these are files + <braunr> on the Hurd, these are memory objects, backed by external pagers + (like ext2fs) + <braunr> so when you read a file + <braunr> the kernel maps it from ext2fs in your address space + <braunr> and when you access the memory, a fault occurs + <braunr> the kernel determines it's a region backed by ext2fs + <braunr> so it asks ext2fs to provide the data + <braunr> when the fault is resolved, your process goes on + <etenil> does the faul occur because Mach doesn't know how to access the + memory? + <braunr> it occurs because Mach intentionnaly didn't back the region with + physical memory + <braunr> the MMU is programmed not to know what is present in the memory + region + <braunr> or because it's read only + <braunr> (which is the case for COW faults) + <etenil> so that means this bit of memory is a buffer that ext2fs loads the + file into and then it is remapped to the application that asked for it + <braunr> more or less, yes + <braunr> ideally, it's directly written into the right pages + <braunr> there is no intermediate buffer + <etenil> I see + <etenil> and as you told me before, currently the page faults are handled + one at a time + <etenil> which wastes a lot of time + <braunr> a certain amount of time + <etenil> enough to bother the user :) + <etenil> I've seen pages have a fixed size + <braunr> yes + <braunr> use the PAGE_SIZE macro + <etenil> and when allocating memory, the size that's asked for is rounded + up to the page size + <etenil> so if I have this correctly, it means that a file ext2fs provides + could be split into a lot of pages + <braunr> yes + <braunr> once in memory, it is managed by the page cache + <braunr> so that pages more actively used are kept longer than others + <braunr> in order to minimize I/O + <etenil> ok + <braunr> so a better page cache code would also improve overall performance + <braunr> and more RAM would help a lot, since we are strongly limited by + the 768 MiB limit + <braunr> which reduces the page cache size a lot + <etenil> but the problem is that reading a whole file in means trigerring + many page faults just for one file + <braunr> if you want to stick to the page clustering thing, yes + <braunr> you want less page faults, so that there are less IPC between the + kernel and the pager + <etenil> so either I make pages bigger + <etenil> or I modify Mach so it can check up on a range of pages for faults + before actually processing + <braunr> you *don't* change the page size + <etenil> ah + <etenil> that's hardware isn't it? + <braunr> in Mach, yes + <etenil> ok + <braunr> and usually, you want the page size to be the CPU page size + <etenil> I see + <braunr> current CPU can support multiple page sizes, but it becomes quite + hard to correctly handle + <braunr> and bigger page sizes mean more fragmentation, so it only suits + machines with large amounts of RAM, which isn't the case for us + <etenil> ok + <etenil> so I'll try the second approach then + <braunr> that's what i'd recommand + <braunr> recommend* + <etenil> ok + + +# IRC, freenode, #hurd, 2011-02-16 + + <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one + place to start looking... + <antrik> (KAM ported the OSF code to gnumach IIRC) + <antrik> there is also an existing patch for clustered paging in libpager, + which needs some adaptation + <antrik> the biggest part of the task is probably modifying the Hurd + servers to use the new interface + <antrik> but as I said, KAM's code should be available through google, and + can serve as a starting point + +<http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html> + + +# IRC, freenode, #hurd, 2011-07-22 + + <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach + interface limitation + <braunr> the external memory pager interface does allow multiple pages to + be transfered + <braunr> isn't it an internal Mach VM problem ? + <braunr> isn't it simply the page fault handler ? + <antrik> braunr: are you sure? I was under the impression that changing the + pager interface was among the requirements... + <antrik> hm... I wonder whether for pageins, it could actually be handled + in the pages instead of Mach... though this wouldn't work for pageouts, + so probably not very helpful + <antrik> err... in the pagers + <braunr> antrik: i'm almost sure + <braunr> but i've be proven wrong many times, so .. + <braunr> there are two main facts that lead me to think this + <braunr> 1/ + http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data + says lengths are provided and doesn't mention the limitation + <braunr> 2/ when reading about UVM, one of the major improvements (between + 10 and 30% of global performance depending on the benchmarks) was + implementing the madvise semantics + <braunr> and this didn't involve a new pager interface, but rather a new + page fault handler + <antrik> braunr: hm... the interface indeed looks like it can handle + multiple pages in both directions... perhaps it was at the Hurd level + where the pager interface needs to be modified, not the Mach one?... + <braunr> antrik: would be nice wouldn't it ? :) + <braunr> antrik: more probably the page fault handler + + +# IRC, freenode, #hurd, 2011-09-28 + + <slpz> antrik: I've just recovered part of my old multipage I/O work + <slpz> antrik: I intend to clean and submit it after finishing the changes + to the pageout system. + <antrik> slpz: oh, great! + <antrik> didn't know you worked on multipage I/O + <antrik> slpz: BTW, have you checked whether any of the work done for GSoC + last year is any good?... + <antrik> (apart from missing copyright assignments, which would be a + serious problem for the Hurd parts...) + <slpz> antrik: It was seven years ago, but I did: + http://www.mail-archive.com/bug-hurd@gnu.org/msg10285.html :-) + <slpz> antrik: Sincerely, I don't think the quality of that code is good + enough to be considered... but I think it was my fault as his mentor for + not correcting him soon enough... + <antrik> slpz: I see + <antrik> TBH, I feel guilty myself, for not asking about the situation + immediately when he stopped attending meetings... + <antrik> slpz: oh, you even already looked into vm_pageout_scan() back then + :-) diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn new file mode 100644 index 00000000..706e1632 --- /dev/null +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -0,0 +1,2558 @@ +[[!meta copyright="Copyright © 2011, 2012 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_hurd]] + +[[!toc]] + + +# [[community/gsoc/project_ideas/disk_io_performance]] + + +# [[gnumach_page_cache_policy]] + + +# 2011-02 + +[[Etenil]] has been working in this area. + + +## IRC, freenode, #hurd, 2011-02-13 + + <etenil> youpi: Would libdiskfs/diskfs.h be in the right place to make + readahead functions? + <youpi> etenil: no, it'd rather be at the memory management layer, + i.e. mach, unfortunately + <youpi> because that's where you see the page faults + <etenil> youpi: Linux also provides a readahead() function for higher level + applications. I'll probably have to add the same thing in a place that's + higher level than mach + <youpi> well, that should just be hooked to the same common implementation + <etenil> the man page for readahead() also states that portable + applications should avoid it, but it could be benefic to have it for + portability + <youpi> it's not in posix indeed + + +## IRC, freenode, #hurd, 2011-02-14 + + <etenil> youpi: I've investigated prefetching (readahead) techniques. One + called DiskSeen seems really efficient. I can't tell yet if it's patented + etc. but I'll keep you informed + <youpi> don't bother with complicated techniques, even the most simple ones + will be plenty :) + <etenil> it's not complicated really + <youpi> the matter is more about how to plug it into mach + <etenil> ok + <youpi> then don't bother with potential pattents + <antrik> etenil: please take a look at the work KAM did for last year's + GSoC + <youpi> just use a trivial technique :) + <etenil> ok, i'll just go the easy way then + + <braunr> antrik: what was etenil referring to when talking about + prefetching ? + <braunr> oh, madvise() stuff + <braunr> i could help him with that + + +## IRC, freenode, #hurd, 2011-02-15 + + <etenil> oh, I'm looking into prefetching/readahead to improve I/O + performance + <braunr> etenil: ok + <braunr> etenil: that's actually a VM improvement, like samuel told you + <etenil> yes + <braunr> a true I/O improvement would be I/O scheduling + <braunr> and how to implement it in a hurdish way + <braunr> (or if it makes sense to have it in the kernel) + <etenil> that's what I've been wondering too lately + <braunr> concerning the VM, you should look at madvise() + <etenil> my understanding is that Mach considers devices without really + knowing what they are + <braunr> that's roughly the interface used both at the syscall() and the + kernel levels in BSD, which made it in many other unix systems + <etenil> whereas I/O optimisations are often hard disk drives specific + <braunr> that's true for almost any kernel + <braunr> the device knowledge is at the driver level + <etenil> yes + <braunr> (here, I separate kernels from their drivers ofc) + <etenil> but Mach also contains some drivers, so I'm going through the code + to find the apropriate place for these improvements + <braunr> you shouldn't tough the drivers at all + <braunr> touch + <etenil> true, but I need to understand how it works before fiddling around + <braunr> hm + <braunr> not at all + <braunr> the VM improvement is about pagein clustering + <braunr> you don't need to know how pages are fetched + <braunr> well, not at the device level + <braunr> you need to know about the protocol between the kernel and + external pagers + <etenil> ok + <braunr> you could also implement pageout clustering + <etenil> if I understand you well, you say that what I'd need to do is a + queuing system for the paging in the VM? + <braunr> no + <braunr> i'm saying that, when a page fault occurs, the kernel should + (depending on what was configured through madvise()) transfer pages in + multiple blocks rather than one at a time + <braunr> communication with external pagers is already async, made through + regular ports + <braunr> which already implement message queuing + <braunr> you would just need to make the mapped regions larger + <braunr> and maybe change the interface so that this size is passed + <etenil> mmh + <braunr> (also don't forget that page clustering can include pages *before* + the page which caused the fault, so you may have to pass the start of + that region too) + <etenil> I'm not sure I understand the page fault thing + <etenil> is it like a segmentation error? + <etenil> I can't find a clear definition in Mach's manual + <braunr> ah + <braunr> it's a fundamental operating system concept + <braunr> http://en.wikipedia.org/wiki/Page_fault + <etenil> ah ok + <etenil> I understand now + <etenil> so what's currently happening is that when a page fault occurs, + Mach is transfering pages one at a time and wastes time + <braunr> sometimes, transferring just one page is what you want + <braunr> it depends on the application, which is why there is madvise() + <braunr> our rootfs, on the other hand, would benefit much from such an + improvement + <braunr> in UVM, this optimization is account for around 10% global + performance improvement + <braunr> accounted* + <etenil> not bad + <braunr> well, with an improved page cache, I'm sure I/O would matter less + on systems with more RAM + <braunr> (and another improvement would make mach support more RAM in the + first place !) + <braunr> an I/O scheduler outside the kernel would be a very good project + IMO + <braunr> in e.g. libstore/storeio + <etenil> yes + <braunr> but as i stated in my thesis, a resource scheduler should be as + close to its resource as it can + <braunr> and since mach can host several operating systems, I/O schedulers + should reside near device drivers + <braunr> and since current drivers are in the kernel, it makes sens to have + it in the kernel too + <braunr> so there must be some discussion about this + <etenil> doesn't this mean that we'll have to get some optimizations in + Mach and have the same outside of Mach for translators that access the + hardware directly? + <braunr> etenil: why ? + <etenil> well as you said Mach contains some drivers, but in principle, it + shouldn't, translators should do disk access etc, yes? + <braunr> etenil: ok + <braunr> etenil: so ? + <etenil> well, let's say if one were to introduce SATA support in Hurd, + nothing would stop him/her to do so with a translator rather than in Mach + <braunr> you should avoid the term translator here + <braunr> it's really hurd specific + <braunr> let's just say a user space task would be responsible for that + job, maybe multiple instances of it, yes + <etenil> ok, so in this case, let's say we have some I/O optimization + techniques like readahead and I/O scheduling within Mach, would these + also apply to the user-space task, or would they need to be + reimplemented? + <braunr> if you have user space drivers, there is no point having I/O + scheduling in the kernel + <etenil> but we also have drivers within the kernel + <braunr> what you call readahead, and I call pagein/out clustering, is + really tied to the VM, so it must be in Mach in any case + <braunr> well + <braunr> you either have one or the other + <braunr> currently we have them in the kernel + <braunr> if we switch to DDE, we should have all of them outside + <braunr> that's why such things must be discussed + <etenil> ok so if I follow you, then future I/O device drivers will need to + be implemented for Mach + <braunr> currently, yes + <braunr> but preferrably, someone should continue the work that has been + done on DDe so that drivers are outside the kernel + <etenil> so for the time being, I will try and improve I/O in Mach, and if + drivers ever get out, then some of the I/O optimizations will need to be + moved out of Mach + <braunr> let me remind you one of the things i said + <braunr> i said I/O scheduling should be close to their resource, because + we can host several operating systems + <braunr> now, the Hurd is the only system running on top of Mach + <braunr> so we could just have I/O scheduling outside too + <braunr> then you should consider neighbor hurds + <braunr> which can use different partitions, but on the same device + <braunr> currently, partitions are managed in the kernel, so file systems + (and storeio) can't make good scheduling decisions if it remains that way + <braunr> but that can change too + <braunr> a single storeio representing a whole disk could be shared by + several hurd instances, just as if it were a high level driver + <braunr> then you could implement I/O scheduling in storeio, which would be + an improvement for the current implementation, and reusable for future + work + <etenil> yes, that was my first instinct + <braunr> and you would be mostly free of the kernel internals that make it + a nightmare + <etenil> but youpi said that it would be better to modify Mach instead + <braunr> he mentioned the page clustering thing + <braunr> not I/O scheduling + <braunr> theseare really two different things + <etenil> ok + <braunr> you *can't* implement page clustering outside Mach because Mach + implements virtual memory + <braunr> both policies and mechanisms + <etenil> well, I'd rather think of one thing at a time if that's alright + <etenil> so what I'm busy with right now is setting up clustered page-in + <etenil> which need to be done within Mach + <braunr> keep clustered page-outs in mind too + <braunr> although there are more constraints on those + <etenil> yes + <etenil> I've looked up madvise(). There's a lot of documentation about it + in Linux but I couldn't find references to it in Mach (nor Hurd), does it + exist? + <braunr> well, if it did, you wouldn't be caring about clustered page + transfers, would you ? + <braunr> be careful about linux specific stuff + <etenil> I suppose not + <braunr> you should implement at least posix options, and if there are + more, consider the bsd variants + <braunr> (the Mach VM is the ancestor of all modern BSD VMs) + <etenil> madvise() seems to be posix + <braunr> there are system specific extensions + <braunr> be careful + <braunr> CONFORMING TO POSIX.1b. POSIX.1-2001 describes posix_madvise(3) + with constants POSIX_MADV_NORMAL, etc., with a behav‐ ior close to that + described here. There is a similar posix_fadvise(2) for file access. + <braunr> MADV_REMOVE, MADV_DONTFORK, MADV_DOFORK, MADV_HWPOISON, + MADV_MERGEABLE, and MADV_UNMERGEABLE are Linux- specific. + <etenil> I was about to post these + <etenil> ok, so basically madvise() allows tasks etc. to specify a usage + type for a chunk of memory, then I could apply the relevant I/O + optimization based on this + <braunr> that's it + <etenil> cool, then I don't need to worry about knowing what the I/O is + operating on, I just need to apply the optimizations as advised + <etenil> that's convenient + <etenil> ok I'll start working on this tonight + <etenil> making a basic readahead shouldn't be too hard + <braunr> readahead is a misleading name + <etenil> is pagein better? + <braunr> applies to too many things, doesn't include the case where + previous elements could be prefetched + <braunr> clustered page transfers is what i would use + <braunr> page prefetching maybe + <etenil> ok + <braunr> you should stick to something that's already used in the + literature since you're not inventing something new + <etenil> yes I've read a paper about prefetching + <etenil> ok + <etenil> thanks for your help braunr + <braunr> sure + <braunr> you're welcome + <antrik> braunr: madvise() is really the least important part of the + picture... + <antrik> very few applications actually use it. but pretty much all + applications will profit from clustered paging + <antrik> I would consider madvise() an optional goody, not an integral part + of the implementation + <antrik> etenil: you can find some stuff about KAM's work on + http://www.gnu.org/software/hurd/user/kam.html + <antrik> not much specific though + <etenil> thanks + <antrik> I don't remember exactly, but I guess there is also some + information on the mailing list. check the archives for last summer + <antrik> look for Karim Allah Ahmed + <etenil> antrik: I disagree, madvise gives me a good starting point, even + if eventually the optimisations should run even without it + <antrik> the code he wrote should be available from Google's summer of code + page somewhere... + <braunr> antrik: right, i was mentioning madvise() because the kernel (VM) + interface is pretty similar to the syscall + <braunr> but even a default policy would be nice + <antrik> etenil: I fear that many bits were discussed only on IRC... so + you'd better look through the IRC logs from last April onwards... + <etenil> ok + + <etenil> at the beginning I thought I could put that into libstore + <etenil> which would have been fine + + <antrik> BTW, I remembered now that KAM's GSoC application should have a + pretty good description of the necessary changes... unfortunately, these + are not publicly visible IIRC :-( + + +## IRC, freenode, #hurd, 2011-02-16 + + <etenil> braunr: I've looked in the kernel to see where prefetching would + fit best. We talked of the VM yesterday, but I'm not sure about it. It + seems to me that the device part of the kernel makes more sense since + it's logically what manages devices, am I wrong? + <braunr> etenil: you are + <braunr> etenil: well + <braunr> etenil: drivers should already support clustered sector + read/writes + <etenil> ah + <braunr> but yes, there must be support in the drivers too + <braunr> what would really benefit the Hurd mostly concerns page faults, so + the right place is the VM subsystem + +[[clustered_page_faults]] + + +# 2012-03 + + +## IRC, freenode, #hurd, 2012-03-21 + + <mcsim> I thought that readahead should have some heuristics, like + accounting size of object and last access time, but i didn't find any in + kam's patch. Are heuristics needed or it will be overhead for + microkernel? + <youpi> size of object and last access time are not necessarily useful to + take into account + <youpi> what would usually typically be kept is the amount of contiguous + data that has been read lately + <youpi> to know whether it's random or sequential, and how much is read + <youpi> (the whole size of the object does not necessarily give any + indication of how much of it will be read) + <mcsim> if big object is accessed often, performance could be increased if + frame that will be read ahead will be increased too. + <youpi> yes, but the size of the object really does not matter + <youpi> you can just observe how much data is read and realize that it's + read a lot + <youpi> all the more so with userland fs translators + <youpi> it's not because you mount a CD image that you need to read it all + <mcsim> youpi: indeed. this will be better. But on other hand there is + principle about policy and mechanism. And kernel should implement + mechanism, but heuristics seems to be policy. Or in this case moving + readahead policy to user level would be overhead? + <antrik> mcsim: paging policy is all in kernel anyways; so it makes perfect + sense to put the readahead policy there as well + <antrik> (of course it can be argued -- probably rightly -- that all of + this should go into userspace instead...) + <mcsim> antrik: probably defpager partly could do that. AFAIR, it is + possible for defpager to return more memory than was asked. + <mcsim> antrik: I want to outline what should be done during gsoc. First, + kernel should support simple readahead for specified number of pages + (regarding direction of access) + simple heuristic for changing frame + size. Also default pager could make some analysis, for instance if it has + many data located consequentially it could return more data then was + asked. For other pagers I won't do anything. Is it suitable? + <antrik> mcsim: I think we actually had the same discussion already with + KAM ;-) + <antrik> for clustered pageout, the kernel *has* to make the decision. I'm + really not convinced it makes sense to leave the decision for clustered + pagein to the individual pagers + <antrik> especially as this will actually complicate matters because a) it + will require work in *every* pager, and b) it will probably make handling + of MADVISE & friends more complex + <antrik> implementing readahead only for the default pager would actually + be rather unrewarding. I'm pretty sure it's the one giving the *least* + benefit + <antrik> it's much, much more important for ext2 + <youpi> mcsim: maybe try to dig in the irc logs, we discussed about it with + neal. the current natural place would be the kernel, because it's the + piece that gets the traps and thus knows what happens with each + projection, while the backend just provides the pages without knowing + which projection wants it. Moving to userland would not only be overhead, + but quite difficult + <mcsim> antrik: OK, but I'm not sure that I could do it for ext2. + <mcsim> OK, I'll dig. + + +## IRC, freenode, #hurd, 2012-04-01 + + <mcsim> as part of implementing of readahead project I have to add + interface for setting appropriate behaviour for memory range. This + interface than should be compatible with madvise call, that has a lot of + possible advises, but most part of them are specific for Linux (according + to man page). Should mach also support these Linux-specific values? + <mcsim> p.s. these Linux-specific values shouldn't affect readahead + algorithm. + <youpi> the interface shouldn't prevent from adding them some day + <youpi> so that we don't have to add them yet + <mcsim> ok. And what behaviour with value MADV_NORMAL should be look like? + Seems that it should be synonym to MADV_SEQUENTIAL, isn't it? + <youpi> no, it just means "no idea what it is" + <youpi> in the linux implementation, that means some given readahead value + <youpi> while SEQUENTIAL means twice as much + <youpi> and RANDOM means zero + <mcsim> youpi: thank you. + <mcsim> youpi: Than, it seems to be better that kernel interface for + setting behaviour will accept readahead value, without hiding it behind + such constants, like VM_BEHAVIOR_DEFAULT (like it was in kam's + patch). And than implementation of madvise will call vm_behaviour_set + with appropriate frame size. Is that right? + <youpi> question of taste, better ask on the list + <mcsim> ok + + +## IRC, freenode, #hurd, 2012-06-09 + + <mcsim> hello. What fictitious pages in gnumach are needed for? + <mcsim> I mean why real page couldn't be grabbed straight, but in sometimes + fictitious page is grabbed first and than converted to real? + <braunr> mcsim: iirc, fictitious pages are needed by device pagers which + must comply with the vm pager interface + <braunr> mcsim: specifically, they must return a vm_page structure, but + this vm_page describes device memory + <braunr> mcsim: and then, it must not be treated like normal vm_page, which + can be added to page queues (e.g. page cache) + + +## IRC, freenode, #hurd, 2012-06-22 + + <mcsim> braunr: Ah. Patch for large storages introduced new callback + pager_notify_evict. User had to define this callback on his own as + pager_dropweak, for instance. But neal's patch change this. Now all + callbacks could have any name, but user defines structure with pager ops + and supplies it in pager_create. + <mcsim> So, I just changed notify_evict to confirm it to new style. + <mcsim> braunr: I want to changed interface of mo_change_attributes and + test my changes with real partitions. For both these I have to update + ext2fs translator, but both partitions I have are bigger than 2Gb, that's + why I need apply this patch.z + <mcsim> But what to do with mo_change_attributes? I need somehow inform + kernel about page fault policy. + <mcsim> When I change mo_ interface in kernel I have to update all programs + that use this interface and ext2fs is one of them. + + <mcsim> braunr: Who do you think better to inform kernel about fault + policy? At the moment I've added fault_strategy parameter that accepts + following strategies: randow, sequential with single page cluster, + sequential with double page cluster and sequential with quad page + cluster. OSF/mach has completely another interface of + mo_change_attributes. In OSF/mach mo_change_attributes accepts structure + of parameter. This structure could have different formats depending o + <mcsim> This rpc could be useful because it is not very handy to update + mo_change_attributes for kernel, for hurd libs and for glibc. Instead of + this kernel will accept just one more structure format. + <braunr> well, like i wrote on the mailing list several weeks ago, i don't + think the policy selection is of concern currently + <braunr> you should focus on the implementation of page clustering and + readahead + <braunr> concerning the interface, i don't think it's very important + <braunr> also, i really don't like the fact that the policy is per object + <braunr> it should be per map entry + <braunr> i think it mentioned that in my mail too + <braunr> i really think you're wasting time on this + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00064.html + <braunr> http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00029.html + <braunr> mcsim: any reason you completely ignored those ? + <mcsim> braunr: Ok. I'll do clustering for map entries. + <braunr> no it's not about that either :/ + <braunr> clustering is grouping several pages in the same transfer between + kernel and pager + <braunr> the *policy* is held in map entries + <antrik> mcsim: I'm not sure I properly understand your question about the + policy interface... but if I do, it's IMHO usually better to expose + individual parameters as RPC arguments explicitly, rather than hiding + them in an opaque structure... + <antrik> (there was quite some discussion about that with libburn guy) + <mcsim> antrik: Following will be ok? kern_return_t vm_advice(map, address, + length, advice, cluster_size) + <mcsim> Where advice will be either random or sequential + <antrik> looks fine to me... but then, I'm not an expert on this stuff :-) + <antrik> perhaps "policy" would be clearer than "advice"? + <mcsim> madvise has following prototype: int madvise(void *addr, size_t + len, int advice); + <mcsim> hmm... looks like I made a typo. Or advi_c_e is ok too? + <antrik> advise is a verb; advice a noun... there is a reason why both + forms show up in the madvise prototype :-) + <mcsim> so final variant should be kern_return_t vm_advise(map, address, + length, policy, cluster_size)? + <antrik> mcsim: nah, you are probably right that its better to keep + consistency with madvise, even if the name of the "advice" parameter + there might not be ideal... + <antrik> BTW, where does cluster_size come from? from the filesystem? + <antrik> I see merits both to naming the parameter "policy" (clearer) or + "advice" (more consistent) -- you decide :-) + <mcsim> antrik: also there is variant strategy, like with inheritance :) + I'll choose advice for now. + <mcsim> What do you mean under "where does cluster_size come from"? + <antrik> well, madvise doesn't have this parameter; so the value must come + from a different source? + <mcsim> in madvise implementation it could fixed value or somehow + calculated basing on size of memory range. In OSF/mach cluster size is + supplied too (via mo_change_attributes). + <antrik> ah, so you don't really know either :-) + <antrik> well, my guess is that it is derived from the cluster size used by + the filesystem in question + <antrik> so for us it would always be 4k for now + <antrik> (and thus you can probably leave it out alltogether...) + <antrik> well, fatfs can use larger clusters + <antrik> I would say, implement it only if it's very easy to do... if it's + extra effort, it's probably not worth it + <mcsim> There is sense to make cluster size bigger for ext2 too, since most + likely consecutive clusters will be within same group. + <mcsim> But anyway I'll handle this later. + <antrik> well, I don't know what cluster_size does exactly; but by the + sound of it, I'd guess it makes an assumption that it's *always* better + to read in this cluster size, even for random access -- which would be + simply wrong for 4k filesystem clusters... + <antrik> BTW, I agree with braunr that madvice() is optional -- it is way + way more important to get readahead working as a default policy first + + +## IRC, freenode, #hurd, 2012-07-01 + + <mcsim> youpi: Do you think you could review my code? + <youpi> sure, just post it to the list + <youpi> make sure to break it down into logical pieces + <mcsim> youpi: I pushed it my branch at gnumach repository + <mcsim> youpi: or it is still better to post changes to list? + <youpi> posting to the list would permit feedback from other people too + <youpi> mcsim: posix distinguishes normal, sequential and random + <youpi> we should probably too + <youpi> the system call should probably be named "vm_advise", to be a verb + like allocate etc. + <mcsim> youpi: ok. A have a talk with antrik regarding naming, I'll change + this later because compiling of glibc take a lot of time. + <youpi> mcsim: I find it odd that vm_for_every_page allocates non-existing + pages + <youpi> there should probably be at least a flag to request it or not + <mcsim> youpi: normal policy is synonym to default. And this could be + treated as either random or sequential, isn't it? + <braunr> mcsim: normally, no + <youpi> yes, the normal policy would be the default + <youpi> it doesn't mean random or sequential + <youpi> it's just to be a compromise between both + <youpi> random is meant to make no read-ahead, since that'd be spurious + anyway + <youpi> while by default we should make readahead + <braunr> and sequential makes even more aggressive readahead, which usually + implies a greater number of pages to fetch + <braunr> that's all + <youpi> yes + <youpi> well, that part is handled by the cluster_size parameter actually + <braunr> what about reading pages preceding the faulted paged ? + <mcsim> Shouldn't sequential clean some pages (if they, for example, are + not precious) that are placed before fault page? + <braunr> ? + <youpi> that could make sense, yes + <braunr> you lost me + <youpi> and something that you wouldn't to with the normal policy + <youpi> braunr: clear what has been read previously + <braunr> ? + <youpi> since the access is supposed to be sequential + <braunr> oh + <youpi> the application will proabably not re-read what was already read + <braunr> you mean to avoid caching it ? + <youpi> yes + <braunr> inactive memory is there for that + <youpi> while with the normal policy you'd assume that the application + might want to go back etc. + <youpi> yes, but you can help it + <braunr> yes + <youpi> instead of making other pages compete with it + <braunr> but then, it's for precious pages + <youpi> I have to say I don't know what a precious page it + <youpi> s + <youpi> does it mean dirty pages? + <braunr> no + <braunr> precious means cached pages + <braunr> "If precious is FALSE, the kernel treats the data as a temporary + and may throw it away if it hasn't been changed. If the precious value is + TRUE, the kernel treats its copy as a data repository and promises to + return it to the manager; the manager may tell the kernel to throw it + away instead by flushing and not cleaning the data" + <braunr> hm no + <braunr> precious means the kernel must keep it + <mcsim> youpi: According to vm_for_every_page. What kind of flag do you + suppose? If object is internal, I suppose not to cross the bound of + object, setting in_end appropriately in vm_calculate_clusters. + <mcsim> If object is external we don't know its actual size, so we should + make mo request first. And for this we should create fictitious pages. + <braunr> mcsim: but how would you implement this "cleaning" with sequential + ? + <youpi> mcsim: ah, ok, I thought you were allocating memory, but it's just + fictitious pages + <youpi> comment "Allocate a new page" should be fixed :) + <mcsim> braunr: I don't now how I will implement this specifically (haven't + tried yet), but I don't think that this is impossible + <youpi> braunr: anyway it's useful as an example where normal and + sequential would be different + <braunr> if it can be done simply + <braunr> because i can see more trouble than gains in there :) + <mcsim> braunr: ok :) + <braunr> mcsim: hm also, why fictitious pages ? + <braunr> fictitious pages should normally be used only when dealing with + memory mapped physically which is not real physical memory, e.g. device + memory + <mcsim> but vm_fault could occur when object represent some device memory. + <braunr> that's exactly why there are fictitious pages + <mcsim> at the moment of allocating of fictitious page it is not know what + backing store of object is. + <braunr> really ? + <braunr> damn, i've got used to UVM too much :/ + <mcsim> braunr: I said something wrong? + <braunr> no no + <braunr> it's just that sometimes, i'm confusing details about the various + BSD implementations i've studied + <braunr> out-of-gsoc-topic question: besides network drivers, do you think + we'll have other drivers that will run in userspace and have to implement + memory mapping ? like framebuffers ? + <braunr> or will there be a translation layer such as storeio that will + handle mapping ? + <youpi> framebuffers typically will, yes + <youpi> that'd be antrik's work on drm + <braunr> hmm + <braunr> ok + <youpi> mcsim: so does the implementation work, and do you see performance + improvement? + <mcsim> youpi: I haven't tested it yet with large ext2 :/ + <mcsim> youpi: I'm going to finish now moving of ext2 to new interface, + than other translators in hurd repository and than finish memory policies + in gnumach. Is it ok? + <youpi> which new interface? + <mcsim> Written by neal. I wrote some temporary code to make ext2 work with + it, but I'm going to change this now. + <youpi> you mean the old unapplied patch? + <mcsim> yes + <youpi> did you have a look at Karim's work? + <youpi> (I have to say I never found the time to check how it related with + neal's patch) + <mcsim> I found only his work in kernel. I didn't see his work in applying + of neal's patch. + <youpi> ok + <youpi> how do they relate with each other? + <youpi> (I have never actually looked at either of them :/) + <mcsim> his work in kernel and neal's patch? + <youpi> yes + <mcsim> They do not correlate with each other. + <youpi> ah, I must be misremembering what each of them do + <mcsim> in kam's patch was changes to support sequential reading in reverse + order (as in OSF/Mach), but posix does not support such behavior, so I + didn't implement this either. + <youpi> I can't find the pointer to neal's patch, do you have it off-hand? + <mcsim> http://comments.gmane.org/gmane.os.hurd.bugs/351 + <youpi> thx + <youpi> I think we are not talking about the same patch from Karim + <youpi> I mean lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html + <mcsim> I mean this patch: + http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00024.html + <mcsim> Oh. + <youpi> ok + <mcsim> seems, this is just the same + <youpi> yes + <youpi> from a non-expert view, I would have thought these patches play + hand in hand, do they really? + <mcsim> this patch is completely for kernel and neal's one is completely + for libpager. + <youpi> i.e. neal's fixes libpager, and karim's fixes the kernel + <mcsim> yes + <youpi> ending up with fixing the whole path? + <youpi> AIUI, karim's patch will be needed so that your increased readahead + will end up with clustered page request? + <mcsim> I will not use kam's patch + <youpi> is it not needed to actually get pages in together? + <youpi> how do you tell libpager to fetch pages together? + <youpi> about the cluster size, I'd say it shouldn't be specified at + vm_advise() level + <youpi> in other OSes, it is usually automatically tuned + <youpi> by ramping it up to a maximum readahead size (which, however, could + be specified) + <youpi> that's important for the normal policy, where there are typically + successive periods of sequential reads, but you don't know in advance for + how long + <mcsim> braunr said that there are legal issues with his code, so I cannot + use it. + <braunr> did i ? + <braunr> mcsim: can you give me a link to the code again please ? + <youpi> see above :) + <braunr> which one ? + <youpi> both + <youpi> they only differ by a typo + <braunr> mcsim: i don't remember saying that, do you have any link ? + <braunr> or log ? + <mcsim> sorry, can you rephrase "ending up with fixing the whole path"? + <mcsim> cluster_size in vm_advise also could be considered as advise + <braunr> no + <braunr> it must be the third time we're talking about this + <youpi> mcsim: I mean both parts would be needed to actually achieve + clustered i/o + <braunr> again, why make cluster_size a per object attribute ? :( + <youpi> wouldn't some objects benefit from bigger cluster sizes, while + others wouldn't? + <youpi> but again, I believe it should rather be autotuned + <youpi> (for each object) + <braunr> if we merely want posix compatibility (and for a first attempt, + it's quite enough), vm_advise is good, and the kernel selects the + implementation (and thus the cluster sizes) + <braunr> if we want finer grained control, perhaps a per pager cluster_size + would be good, although its efficiency depends on several parameters + <braunr> (e.g. where the page is in this cluster) + <braunr> but a per object cluster size is a large waste of memory + considering very few applications (if not none) would use the "feature" + .. + <braunr> (if any*) + <youpi> there must be a misunderstanding + <youpi> why would it be a waste of memory? + <braunr> "per object" + <youpi> so? + <braunr> there can be many memory objects in the kernel + <youpi> so? + <braunr> so such an overhead must be useful to accept it + <youpi> in my understanding, a cluster size per object is just a mere + integer for each object + <youpi> what overhead? + <braunr> yes + <youpi> don't we have just thousands of objects? + <braunr> for now + <braunr> remember we're trying to remove the page cache limit :) + <youpi> that still won't be more than tens of thousands of objects + <youpi> times an integer + <youpi> that's completely neglectible + <mcsim> braunr: Strange, Can't find in logs. Weird things are happening in + my memory :/ Sorry. + <braunr> mcsim: i'm almost sure i never said that :/ + <braunr> but i don't trust my memory too much either + <braunr> youpi: depends + <youpi> mcsim: I mean both parts would be needed to actually achieve + clustered i/o + <mcsim> braunr: I made I call vm_advise that applies policy to memory range + (vm_map_entry to be specific) + <braunr> mcsim: good + <youpi> actually the cluster size should even be per memory range + <mcsim> youpi: In this sense, yes + <youpi> k + <mcsim> sorry, Internet connection lags + <braunr> when changing a structure used to create many objects, keep in + mind one thing + <braunr> if its size gets larger than a threshold (currently, powers of + two), the cache used by the slab allocator will allocate twice the + necessary amount + <youpi> sure + <braunr> this is the case with most object caching allocators, although + some can have specific caches for common sizes such as 96k which aren't + powers of two + <braunr> anyway, an integer is negligible, but the final structure size + must be checked + <braunr> (for both 32 and 64 bits) + <mcsim> braunr: ok. + <mcsim> But I didn't understand what should be done with cluster size in + vm_advise? Should I delete it? + <braunr> to me, the cluster size is a pager property + <youpi> to me, the cluster size is a map property + <braunr> whereas vm_advise indicates what applications want + <youpi> you could have several process accessing the same file in different + ways + <braunr> youpi: that's why there is a policy + <youpi> isn't cluster_size part of the policy? + <braunr> but if the pager abilities are limited, it won't change much + <braunr> i'm not sure + <youpi> cluster_size is the amount of readahead, isn't it? + <braunr> no, it's the amount of data in a single transfer + <mcsim> Yes, it is. + <braunr> ok, i'll have to check your code + <youpi> shouldn't transfers permit unbound amounts of data? + <mcsim> braunr: than I misunderstand what readahead is + <braunr> well then cluster size is per policy :) + <braunr> e.g. random => 0, normal => 3, sequential => 15 + <braunr> why make it per map entry ? + <youpi> because it depends on what the application doezs + <braunr> let me check the code + <youpi> if it's accessing randomly, no need for big transfers + <youpi> just page transfers will be fine + <youpi> if accessing sequentially, rather use whole MiB of transfers + <youpi> and these behavior can be for the same file + <braunr> mcsim: the call is vm_advi*s*e + <braunr> mcsim: the call is vm_advi_s_e + <braunr> not advice + <youpi> yes, he agreed earlier + <braunr> ok + <mcsim> cluster_size is the amount of data that I try to read at one time. + <mcsim> at singe mo_data_request + <mcsim> *single + <youpi> which, to me, will depend on the actual map + <braunr> ok so it is the transfer size + <youpi> and should be autotuned, especially for normal behavior + <braunr> youpi: it makes no sense to have both the advice and the actual + size per map entry + <youpi> to get big readahead with all apps + <youpi> braunr: the size is not only dependent on the advice, but also on + the application behavior + <braunr> youpi: how does this application tell this ? + <youpi> even for sequential, you shouldn't necessarily use very big amounts + of transfers + <braunr> there is no need for the advice if there is a cluster size + <youpi> there can be, in the case of sequential, as we said, to clear + previous pages + <youpi> but otherwise, indeed + <youpi> but for me it's the converse + <youpi> the cluster size should be tuned anyway + <braunr> and i'm against giving the cluster size in the advise call, as we + may want to prefetch previous data as well + <youpi> I don't see how that collides + <braunr> well, if you consider it's the transfer size, it doesn't + <youpi> to me cluster size is just the size of a window + <braunr> if you consider it's the amount of pages following a faulted page, + it will + <braunr> also, if your policy says e.g. "3 pages before, 10 after", and + your cluster size is 2, what happens ? + <braunr> i would find it much simpler to do what other VM variants do: + compute the I/O sizes directly from the policy + <youpi> don't they autotune, and use the policy as a maximum ? + <braunr> depends on the implementations + <youpi> ok, but yes I agree + <youpi> although casting the size into stone in the policy looks bogus to + me + <braunr> but making cluster_size part of the kernel interface looks way too + messy + <braunr> it is + <braunr> that's why i would have thought it as part of the pager properties + <braunr> the pager is the true component besides the kernel that is + actually involved in paging ... + <youpi> well, for me the flexibility should still be per application + <youpi> by pager you mean the whole pager, not each file, right? + <braunr> if a pager can page more because e.g. it's a file system with big + block sizes, why not fetch more ? + <braunr> yes + <braunr> it could be each file + <braunr> but only if we have use for it + <braunr> and i don't see that currently + <youpi> well, posix currently doesn't provide a way to set it + <youpi> so it would be useless atm + <braunr> i was thinking about our hurd pagers + <youpi> could we perhaps say that the policy maximum could be a fraction of + available memory? + <braunr> why would we want that ? + <youpi> (total memory, I mean) + <youpi> to make it not completely cast into stone + <youpi> as have been in the past in gnumach + <braunr> i fail to understand :/ + <youpi> there must be a misunderstanding then + <youpi> (pun not intended) + <braunr> why do you want to limit the policy maximum ? + <youpi> how to decide it? + <braunr> the pager sets it + <youpi> actually I don't see how a pager could decide it + <youpi> on what ground does it make the decision? + <youpi> readahead should ideally be as much as 1MiB + <braunr> 02:02 < braunr> if a pager can page more because e.g. it's a file + system with big block sizes, why not fetch more ? + <braunr> is the example i have in mind + <braunr> otherwise some default values + <youpi> that's way smaller than 1MiB, isn't it? + <braunr> yes + <braunr> and 1 MiB seems a lot to me :) + <youpi> for readahead, not really + <braunr> maybe for sequential + <youpi> that's what we care about! + <braunr> ah, i thought we cared about normal + <youpi> "as much as 1MiB", I said + <youpi> I don't mean normal :) + <braunr> right + <braunr> but again, why limit ? + <braunr> we could have 2 or more ? + <youpi> at some point you don't get more efficiency + <youpi> but eat more memory + <braunr> having the pager set the amount allows us to easily adjust it over + time + <mcsim> braunr: Do you think that readahead should be implemented in + libpager? + <youpi> than needed + <braunr> mcsim: no + <braunr> mcsim: err + <braunr> mcsim: can't answer + <youpi> mcsim: do you read the log of what you have missed during + disconnection? + <braunr> i'm not sure about what libpager does actually + <mcsim> yes + <braunr> for me it's just mutualisation of code used by pagers + <braunr> i don't know the details + <braunr> youpi: yes + <braunr> youpi: that's why we want these values not hardcoded in the kernel + <braunr> youpi: so that they can be adjusted by our shiny user space OS + <youpi> (btw apparently linux uses minimum 16k, maximum 128 or 256k) + <braunr> that's more reasonable + <youpi> that's just 4 times less :) + <mcsim> braunr: You say that pager should decide how much data should be + read ahead, but each pager can't implement it on it's own as there will + be too much overhead. So the only way is to implement this in libpager. + <braunr> mcsim: gni ? + <braunr> why couldn't they ? + <youpi> mcsim: he means the size, not the actual implementation + <youpi> the maximum size, actually + <braunr> actually, i would imagine it as the pager giving per policy + parameters + <youpi> right + <braunr> like how many before and after + <youpi> I agree, then + <braunr> the kernel could limit, sure, to avoid letting pagers use + completely insane values + <youpi> (and that's just a max, the kernel autotunes below that) + <braunr> why not + <youpi> that kernel limit could be a fraction of memory, then? + <braunr> it could, yes + <braunr> i see what you mean now + <youpi> mcsim: did you understand our discussion? + <youpi> don't hesitate to ask for clarification + <mcsim> I supposed cluster_size to be such parameter. And advice will help + to interpret this parameter (whether data should be read after fault page + or some data should be cleaned before) + <youpi> mcsim: we however believe that it's rather the pager than the + application that would tell that + <youpi> at least for the default values + <youpi> posix doesn't have a way to specify it, and I don't think it will + in the future + <braunr> and i don't think our own hurd-specific programs will need more + than that + <braunr> if they do, we can slightly change the interface to make it a per + object property + <braunr> i've checked the slab properties, and it seems we can safely add + it per object + <braunr> cf http://www.sceen.net/~rbraun/slabinfo.out + <braunr> so it would still be set by the pager, but if depending on the + object, the pager could set different values + <braunr> youpi: do you think the pager should just provide one maximum size + ? or per policy sizes ? + <youpi> I'd say per policy size + <youpi> so people can increase sequential size like crazy when they know + their sequential applications need it, without disturbing the normal + behavior + <braunr> right + <braunr> so the last decision is per pager or per object + <braunr> mcsim: i'd say whatever makes your implementation simpler :) + <mcsim> braunr: how kernel knows that object are created by specific pager? + <braunr> that's the kind of things i'm referring to with "whatever makes + your implementation simpler" + <braunr> but usually, vm_objects have an ipc port and some properties + relatedto their pagers + <braunr> -usually + <braunr> the problem i had in mind was the locking protocol but our spin + locks are noops, so it will be difficult to detect deadlocks + <mcsim> braunr: and for every policy there should be variable in vm_object + structure with appropriate cluster_size? + <braunr> if you want it per object, yes + <braunr> although i really don't think we want it + <youpi> better keep it per pager for now + <braunr> let's imagine youpi finishes his 64-bits support, and i can + successfully remove the page cache limit + <braunr> we'd jump from 1.8 GiB at most to potentially dozens of GiB of RAM + <braunr> and 1.8, mostly unused + <braunr> to dozens almost completely used, almost all the times for the + most interesting use cases + <braunr> we may have lots and lots of objects to keep around + <braunr> so if noone really uses the feature ... there is no point + <youpi> but also lots and lots of memory to spend on it :) + <youpi> a lot of objects are just one page, but a lof of them are not + <braunr> sure + <braunr> we wouldn't be doing that otherwise :) + <braunr> i'm just saying there is no reason to add the overhead of several + integers for each object if they're simply not used at all + <braunr> hmm, 64-bits, better page cache, clustered paging I/O :> + <braunr> (and readahead included in the last ofc) + <braunr> good night ! + <mcsim> than, probably, make system-global max-cluster_size? This will save + some memory. Also there is usually no sense in reading really huge chunks + at once. + <youpi> but that'd be tedious to set + <youpi> there are only a few pagers, that's no wasted memory + <youpi> the user being able to set it for his own pager is however a very + nice feature, which can be very useful for databases, image processing, + etc. + <mcsim> In conclusion I have to implement following: 3 memory policies per + object and per vm_map_entry. Max cluster size for every policy should be + set per pager. + <mcsim> So, there should be 2 system calls for setting memory policy and + one for setting cluster sizes. + <mcsim> Also amount of data to transfer should be tuned automatically by + every page fault. + <mcsim> youpi: Correct me, please, if I'm wrong. + <youpi> I believe that's what we ended up to decide, yes + + +## IRC, freenode, #hurd, 2012-07-02 + + <braunr> is it safe to say that all memory objects implemented by external + pagers have "file" semantics ? + <braunr> i wonder if the current memory manager interface is suitable for + device pagers + <mcsim> braunr: What does "file" semantics mean? + <braunr> mcsim: anonymous memory doesn't have the same semantics as a file + for example + <braunr> anonymous memory that is discontiguous in physical memory can be + contiguous in swap + <braunr> and its location can change with time + <braunr> whereas with a memory object, the data exchanged with pagers is + identified with its offset + <braunr> in (probably) all other systems, this way of specifying data is + common to all files, whatever the file system + <braunr> linux uses the struct vm_file name, while in BSD/Solaris they are + called vnodes (the link between a file system inode and virtual memory) + <braunr> my question is : can we implement external device pagers with the + current interface, or is this interface really meant for files ? + <braunr> also + <braunr> mcsim: something about what you said yesterday + <braunr> 02:39 < mcsim> In conclusion I have to implement following: 3 + memory policies per object and per vm_map_entry. Max cluster size for + every policy should be set per pager. + <braunr> not per object + <braunr> one policy per map entry + <braunr> transfer parameters (pages before and after the faulted page) per + policy, defined by pagers + <braunr> 02:39 < mcsim> So, there should be 2 system calls for setting + memory policy and one for setting cluster sizes. + <braunr> adding one call for vm_advise is good because it mirrors the posix + call + <braunr> but for the parameters, i'd suggest changing an already existing + call + <braunr> not sure which one though + <mcsim> braunr: do you know how mo_change_attributes implemented in + OSF/Mach? + <braunr> after a quick reading of the reference manual, i think i + understand why they made it per object + <braunr> mcsim: no + <braunr> did they change the call to include those paging parameters ? + <mcsim> it accept two parameters: flavor and pointer to structure with + parameters. + <mcsim> flavor determines semantics of structure with parameters. + <mcsim> + http://www.darwin-development.org/cgi-bin/cvsweb/osfmk/src/mach_kernel/vm/memory_object.c?rev=1.1 + <mcsim> structure can have 3 different views and what exect view will be is + determined by value of flavor + <mcsim> So, I thought about implementing similar call that could be used + for various purposes. + <mcsim> like ioctl + <braunr> "pointer to structure with parameters" <= which one ? + <braunr> mcsim: don't model anything anywhere like ioctl please + <mcsim> memory_object_info_t attributes + <braunr> ioctl is the very thing we want NOT to have on the hurd + <braunr> ok attributes + <braunr> and what are the possible values of flavour, and what kinds of + attributes ? + <mcsim> and then appears something like this on each case: behave = + (old_memory_object_behave_info_t) attributes; + <braunr> ok i see + <mcsim> flavor could be OLD_MEMORY_OBJECT_BEHAVIOR_INFO, + MEMORY_OBJECT_BEHAVIOR_INFO, MEMORY_OBJECT_PERFORMANCE_INFO etc + <braunr> i don't really see the point of flavour here, other than + compatibility + <braunr> having attributes is nice, but you should probably add it as a + call parameter, not inside a structure + <braunr> as a general rule, we don't like passing structures too much + to/from the kernel, because handling them with mig isn't very clean + <mcsim> ok + <mcsim> What policy parameters should be defined by pager? + <braunr> i'd say number of pages to page-in before and after the faulted + page + <mcsim> Only pages before and after the faulted page? + <braunr> for me yes + <braunr> youpi might have different things in mind + <braunr> the page cleaning in sequential mode is something i wouldn't do + <braunr> 1/ applications might want data read sequentially to remain in the + cache, for other sequential accesses + <braunr> 2/ applications that really don't want to cache anything should + use O_DIRECT + <braunr> 3/ it's complicated, and we're in july + <braunr> i'd rather have a correct and stable result than too many unused + features + <mcsim> braunr: MADV_SEQUENTIAL Expect page references in sequential order. + (Hence, pages in the given range can be aggressively read ahead, and may + be freed soon after they are accessed.) + <mcsim> this is from linux man + <mcsim> braunr: Can I at least make keeping in mind that it could be + implemented? + <mcsim> I mean future rpc interface + <mcsim> braunr: From behalf of kernel pager is just a port. + <mcsim> That's why it is not clear for me how I can make in kernel + per-pager policy + <braunr> mcsim: you can't + <braunr> 15:19 < braunr> after a quick reading of the reference manual, i + think i understand why they made it per object + <braunr> + http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_madvise.html + <braunr> POSIX_MADV_SEQUENTIAL + <braunr> Specifies that the application expects to access the specified + range sequentially from lower addresses to higher addresses. + <braunr> linux might free pages after their access, why not, but this is + entirely up to the implementation + <mcsim> I know, when but applications might want data read sequentially to + remain in the cache, for other sequential accesses this kind of access + could be treated rather normal or random + <braunr> we can do differently + <braunr> mcsim: no + <braunr> sequential means the access will be sequential + <braunr> so aggressive readahead (e.g. 0 pages before, many after), should + be used + <braunr> for better performance + <braunr> from my pov, it has nothing to do with caching + <braunr> i actually sometimes expect data to remain in cache + <braunr> e.g. before playing a movie from sshfs, i sometimes prefetch it + using dd + <braunr> then i use mplayer + <braunr> i'd be very disappointed if my data didn't remain in the cache :) + <mcsim> At least these pages could be placed into inactive list to be first + candidates for pageout. + <braunr> that's what will happen by default + <braunr> mcsim: if we need more properties for memory objects, we'll adjust + the call later, when we actually implement them + <mcsim> so, first call is vm_advise and second is changed + mo_change_attributes? + <braunr> yes + <mcsim> there will appear 3 new parameters in mo_c_a: policy, pages before + and pages after? + <mcsim> braunr: With vm_advise I didn't understand one thing. This call is + defined in defs file, so that should mean that vm_advise is ordinal rpc + call. But on the same time it is defined as syscall in mach internals (in + mach_trap_table). + <braunr> mcsim: what ? + <braunr> were is it "defined" ? (it doesn't exit in gnumach currently) + <mcsim> Ok, let consider vm_map + <mcsim> I define it both in mach_trap_table and in defs file. + <mcsim> But why? + <braunr> uh ? + <braunr> let me see + <mcsim> Why defining in defs file is not enough? + <mcsim> and previous question: there will appear 3 new parameters in + mo_c_a: policy, pages before and pages after? + <braunr> mcsim: give me the exact file paths please + <braunr> mcsim: we'll discuss the new parameters after + <mcsim> kern/syscall_sw.c + <braunr> right i see + <mcsim> here mach_trap_table in defined + <braunr> i think they're not used + <braunr> they were probably introduced for performance + <mcsim> and ./include/mach/mach.defs + <braunr> don't bother adding vm_advise as a syscall + <braunr> about the parameters, it's a bit more complicated + <braunr> you should add 6 parameters + <braunr> before and after, for the 3 policies + <braunr> but + <braunr> as seen in the posix page, there could be more policies .. + <braunr> ok forget what i said, it's stupid + <braunr> yes, the 3 parameters you had in mind are correct + <braunr> don't forget a "don't change" value for the policy though, so the + kernel ignores the before/after values if we don't want to change that + <mcsim> ok + <braunr> mcsim: another reason i asked about "file semantics" is the way we + handle the cache + <braunr> mcsim: file semantics imply data is cached, whereas anonymous and + device memory usually isn't + <braunr> (although having the cache at the vm layer instead of the pager + layer allows nice things like the swap cache) + <mcsim> But this shouldn't affect possibility of implementing of device + pager. + <braunr> yes it may + <braunr> consider how a fault is actually handled by a device + <braunr> mach must use weird fictitious pages for that + <braunr> whereas it would be better to simply let the pager handle the + fault as it sees fit + <mcsim> setting may_cache to false should resolve the issue + <braunr> for the caching problem, yes + <braunr> which is why i still think it's better to handle the cache at the + vm layer, unlike UVM which lets the vnode pager handle its own cache, and + removes the vm cache completely + <mcsim> The only issue with pager interface I see is implementing of + scatter-gather DMA (as current interface does not support non-consecutive + access) + <braunr> right + <braunr> but that's a performance issue + <braunr> my problem with device pagers is correctness + <braunr> currently, i think the kernel just asks pagers for "data" + <braunr> whereas a device pager should really map its device memory where + the fault happen + <mcsim> braunr: You mean that every access to memory should cause page + fault? + <mcsim> I mean mapping of device memory + <braunr> no + <braunr> i mean a fault on device mapped memory should directly access a + shared region + <braunr> whereas file pagers only implement backing store + <braunr> let me explain a bit more + <braunr> here is what happens with file mapped memory + <braunr> you map it, access it (some I/O is done to get the page content in + physical memory), then later it's flushed back + <braunr> whereas with device memory, there shouldn't be any I/O, the device + memory should directly be mapped (well, some devices need the same + caching behaviour, while others provide direct access) + <braunr> one of the obvious consequences is that, when you map device + memory (e.g. a framebuffer), you expect changes in your mapped memory to + be effective right away + <braunr> while with file mapped memory, you need to msync() it + <braunr> (some framebuffers also need to be synced, which suggests greater + control is needed for external pagers) + <mcsim> Seems that I understand you. But how it is implemented in other + OS'es? Do they set something in mmu? + <braunr> mcsim: in netbsd, pagers have a fault operatin in addition to get + and put + <braunr> the device pager sets get and put to null and implements fault + only + <braunr> the fault callback then calls the d_mmap callback of the specific + driver + <braunr> which usually results in the mmu being programmed directly + <braunr> (e.g. pmap_enter or similar) + <braunr> in linux, i think raw device drivers, being implemented as + character device files, must provide raw read/write/mmap/etc.. functions + <braunr> so it looks pretty much similar + <braunr> i'd say our current external pager interface is insufficient for + device pagers + <braunr> but antrik may know more since he worked on ggi + <braunr> antrik: ^ + <mcsim> braunr: Seems he used io_map + <braunr> mcsim: where ar eyou looking at ? the incubator ? + <mcsim> his master's thesis + <braunr> ah the thesis + <braunr> but where ? :) + <mcsim> I'll give you a link + <mcsim> http://dl.dropbox.com/u/36519904/kgi_on_hurd.pdf + <braunr> thanks + <mcsim> see p 158 + <braunr> arg, more than 200 pages, and he says he's lazy :/ + <braunr> mcsim: btw, have a look at m_o_ready + <mcsim> braunr: This is old form of mo_change attributes + <mcsim> I'm not going to change it + <braunr> mcsim: these are actually the default object parameters right ? + <braunr> mcsim: if you don't change it, it means the kernel must set + default values until the pager changes them, if it does + <mcsim> yes. + <antrik> mcsim: madvise() on Linux has a separate flag to indicate that + pages won't be reused. thus I think it would *not* be a good idea to + imply it in SEQUENTIAL + <antrik> braunr: yes, my KMS code relies on mapping memory objects for the + framebuffer + <antrik> (it should be noted though that on "modern" hardware, mapping + graphics memory directly usually gives very poor performance, and drivers + tend to avoid it...) + <antrik> mcsim: BTW, it was most likely me who warned about legal issues + with KAM's work. AFAIK he never managed to get the copyright assignment + done :-( + <antrik> (that's not really mandatory for the gnumach work though... only + for the Hurd userspace parts) + <antrik> also I'd like to point out again that the cluster_size argument + from OSF Mach was probably *not* meant for advice from application + programs, but rather was supposed to reflect the cluster size of the + filesystem in question. at least that sounds much more plausible to me... + <antrik> braunr: I have no idea whay you mean by "device pager". device + memory is mapped once when the VM mapping is established; there is no + need for any fault handling... + <antrik> mcsim: to be clear, I think the cluster_size parameter is mostly + orthogonal to policy... and probably not very useful at all, as ext2 + almost always uses page-sized clusters. I'm strongly advise against + bothering with it in the initial implementation + <antrik> mcsim: to avoid confusion, better use a completely different name + for the policy-decided readahead size + <mcsim> antrik: ok + <antrik> braunr: well, yes, the thesis report turned out HUGE; but the + actual work I did on the KGI port is fairly tiny (not more than a few + weeks of actual hacking... everything else was just brooding) + <antrik> braunr: more importantly, it's pretty much the last (and only + non-trivial) work I did on the Hurd :-( + <antrik> (also, I don't think I used the word "lazy"... my problem is not + laziness per se; but rather inability to motivate myself to do anything + not providing near-instant gratification...) + <braunr> antrik: right + <braunr> antrik: i shouldn't consider myself lazy either + <braunr> mcsim: i agree with antrik, as i told you weeks ago + <braunr> about + <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size + parameter is mostly orthogonal to policy... and probably not very useful + at all, as ext2 almost always uses page-sized clusters. I'm strongly + advise against bothering with it + <braunr> in the initial implementation + <braunr> antrik: but how do you actually map device memory ? + <braunr> also, strangely enough, here is the comment in dragonflys + madvise(2) + <braunr> 21:45 < antrik> mcsim: to be clear, I think the cluster_size + parameter is mostly orthogonal to policy... and probably not very useful + at all, as ext2 almost always uses page-sized clusters. I'm strongly + advise against bothering with it + <braunr> in the initial implementation + <braunr> arg + <braunr> MADV_SEQUENTIAL Causes the VM system to depress the priority of + pages immediately preceding a given page when it is faulted in. + <antrik> braunr: interesting... + <antrik> (about SEQUENTIAL on dragonfly) + <antrik> as for mapping device memory, I just use to device_map() on the + mem device to map the physical address space into a memory object, and + then through vm_map into the driver (and sometimes application) address + space + <antrik> formally, there *is* a pager involved of course (implemented + in-kernel by the mem device), but it doesn't really do anything + interesting + <antrik> thinking about it, there *might* actually be page faults involved + when the address ranges are first accessed... but even then, the handling + is really trivial and not terribly interesting + <braunr> antrik: it does the most interesting part, create the physical + mapping + <braunr> and as trivial as it is, it requires a special interface + <braunr> i'll read about device_map again + <braunr> but yes, the fact that it's in-kernel is what solves the problem + here + <braunr> what i'm interested in is to do it outside the kernel :) + <antrik> why would you want to do that? + <antrik> there is no policy involved in doing an MMIO mapping + <antrik> you ask for the pysical memory region you are interested in, and + that's it + <antrik> whether the kernel adds the page table entries immediately or on + faults is really an implementation detail + <antrik> braunr: ^ + <braunr> yes it's a detail + <braunr> but do we currently have the interface to make such mappings from + userspace ? + <braunr> and i want to do that because i'd like as many drivers as possible + outside the kernel of course + <antrik> again, the userspace driver asks the kernel to establish the + mapping (through device_map() and then vm_map() on the resulting memory + object) + <braunr> hm i'm missing something + <braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Device-Map.html#Device-Map + <= this one ? + <antrik> yes, this one + <braunr> but this implies the device is implemented by the kernel + <antrik> the mem device is, yes + <antrik> but that's not a driver + <braunr> ah + <antrik> it's just the interface for doing MMIO + <antrik> (well, any physical mapping... but MMIO is probably the only real + use case for that) + <braunr> ok + <braunr> i was thinking about completely removing the device interface from + the kernel actually + <braunr> but it makes sense to have such devices there + <antrik> well, in theory, specific kernel drivers can expose their own + device_map() -- but IIRC the only one that does (besides mem of course) + is maptime -- which is not a real driver either... + <braunr> oh btw, i didn't know you had a blog :) + <antrik> well, it would be possible to replace the device interface by + specific interfaces for the generic pseudo devices... I'm not sure how + useful that would be + <braunr> there are lots of interesting stuff there + <antrik> hehe... another failure ;-) + <braunr> failure ? + <antrik> well, when I realized that I'm speding a lot of time pondering + things, and never can get myself to actually impelemnt any of them, I had + the idea that if I write them down, there might at least be *some* good + from it... + <antrik> unfortunately it turned out that I need so much effort to write + things down, that most of the time I can't get myself to do that either + :-( + <braunr> i see + <braunr> well it's still nice to have it + <antrik> (notice that the latest entry is two years old... and I haven't + even started describing most of my central ideas :-( ) + <braunr> antrik: i tried to create a blog once, and found what i wrote so + stupid i immediately removed it + <antrik> hehe + <antrik> actually some of my entries seem silly in retrospect as well... + <antrik> but I guess that's just the way it is ;-) + <braunr> :) + <braunr> i'm almost sure other people would be interested in what i had to + say + <antrik> BTW, I'm actually not sure whether the Mach interfaces are + sufficient to implement GEM/TTM... we would certainly need kernel support + for GART (as for any other kind IOMMU in fact); but beyond that it's not + clear to me + <braunr> GEM ? TTM ? GART ? + <antrik> GEM = Graphics Execution Manager. part of the "new" DRM interface, + closely tied with KMS + <antrik> TTM = Translation Table Manager. does part of the background work + for most of the GEM drivers + <braunr> "The Graphics Execution Manager (GEM) is a computer software + system developed by Intel to do memory management for device drivers for + graphics chipsets." hmm + <antrik> (in fact it was originally meant to provide the actual interface; + but the Inter folks decided that it's not useful for their UMA graphics) + <antrik> GART = Graphics Aperture + <antrik> kind of an IOMMU for graphics cards + <antrik> allowing the graphics card to work with virtual mappings of main + memory + <antrik> (i.e. allowing safe DMA) + <braunr> ok + <braunr> all this graphics stuff looks so complex :/ + <antrik> it is + <antrik> I have a whole big chapter on that in my thesis... and I'm not + even sure I got everything right + <braunr> what is nvidia using/doing (except for getting the finger) ? + <antrik> flushing out all the details for KMS, GEM etc. took the developers + like two years (even longer if counting the history of TTM) + <antrik> Nvidia's proprietary stuff uses a completely own kernel interface, + which is of course not exposed or docuemented in any way... but I guess + it's actually similar in what it does) + <braunr> ok + <antrik> (you could ask the nouveau guys if you are truly + interested... they are doing most of their reverse engineering at the + kernel interface level) + <braunr> it seems graphics have very special needs, and a lot of them + <braunr> and the interfaces are changing often + <braunr> so it's not that much interesting currently + <braunr> it just means we'll probably have to change the mach interface too + <braunr> like you said + <braunr> so the answer to my question, which was something like "do mach + external pagers only implement files ?", is likely yes + <antrik> well, KMS/GEM had reached some stability; but now there are + further changes ahead with the embedded folks coming in with all their + dedicated hardware, calling for unified buffer management across the + whole pipeline (from capture to output) + <antrik> and yes: graphics hardware tends to be much more complex regarding + the interface than any other hardware. that's because it's a combination + of actual I/O (like most other devices) with a very powerful coprocessor + <antrik> and the coprocessor part is pretty much unique amongst peripherial + devices + <antrik> (actually, the I/O part is also much more complex than most other + hardware... but that alone would only require a more complex driver, not + special interfaces) + <antrik> embedded hardware makes it more interesting in that the I/O + part(s) are separate from the coprocessor ones; and that there are often + several separate specialised ones of each... the DRM/KMS stuff is not + prepared to deal with this + <antrik> v4l over time has evolved to cover such things; but it's not + really the right place to implement graphics drivers... which is why + there are not efforts to unify these frameworks. funny times... + + +## IRC, freenode, #hurd, 2012-07-03 + + <braunr> mcsim: vm_for_every_page should be static + <mcsim> braunr: ok + <braunr> mcsim: see http://gcc.gnu.org/onlinedocs/gcc/Inline.html + <braunr> and it looks big enough that you shouldn't make it inline + <braunr> let the compiler decide for you (which is possible only if the + function is static) + <braunr> (otherwise a global symbol needs to exist) + <braunr> mcsim: i don't know where you copied that comment from, but you + should review the description of the vm_advice call in mach.Defs + <mcsim> braunr: I see + <mcsim> braunr: It was vm_inherit :) + <braunr> mcsim: why isn't NORMAL defined in vm_advise.h ? + <braunr> mcsim: i figured actually ;) + <mcsim> braunr: I was going to do it later when. + <braunr> mcsim: for more info on inline, see + http://www.kernel.org/doc/Documentation/CodingStyle + <braunr> arg that's an old one + <mcsim> braunr: I know that I do not follow coding style + <braunr> mcsim: this one is about linux :p + <braunr> mcsim: http://lxr.linux.no/linux/Documentation/CodingStyle should + have it + <braunr> mcsim: "Chapter 15: The inline disease" + <mcsim> I was going to fix it later during refactoring when I'll merge + mplaneta/gsoc12/working to mplaneta/gsoc12/master + <braunr> be sure not to forget :p + <braunr> and the best not to forget is to do it asap + <braunr> +way + <mcsim> As to inline. I thought that even if I specify function as inline + gcc makes final decision about it. + <mcsim> There was a specifier that made function always inline, AFAIR. + <braunr> gcc can force a function not to be inline, yes + <braunr> but inline is still considered as a strong hint + + +## IRC, freenode, #hurd, 2012-07-05 + + <mcsim1> braunr: hello. You've said that pager has to supply 2 values to + kernel to give it an advice how execute page fault. These two values + should be number of pages before and after the page where fault + occurred. But for sequential policy number of pager before makes no + sense. For random policy too. For normal policy it would be sane to make + readahead symmetric. Probably it would be sane to make pager supply + cluster_size (if it is necessary to supply any) that w + <mcsim1> *that will be advice for kernel of least sane value? And maximal + value will be f(free_memory, map_entry_size)? + <antrik> mcsim1: I doubt symmetric readahead would be a good default + policy... while it's hard to estimate an optimum over all typical use + cases, I'm pretty sure most situtations will benefit almost exclusively + from reading following pages, not preceeding ones + <antrik> I'm not even sure it's useful to read preceding pages at all in + the default policy -- the use cases are probably so rare that the penalty + in all other use cases is not justified. I might be wrong on that + though... + <antrik> I wonder how other systems handle that + <LarstiQ> antrik: if there is a mismatch between pages and the underlying + store, like why changing small bits of data on an ssd is slow? + <braunr> mcsim1: i don't see why not + <braunr> antrik: netbsd reads a few pages before too + <braunr> actually, what netbsd does vary on the version, some only mapped + in resident pages, later versions started asynchronous transfers in the + hope those pages would be there + <antrik> LarstiQ: not sure what you are trying to say + <braunr> in linux : + <braunr> 321 * MADV_NORMAL - the default behavior is to read clusters. + This + <braunr> 322 * results in some read-ahead and read-behind. + <braunr> not sure if it's actually what the implementation does + <antrik> well, right -- it's probably always useful to read whole clusters + at a time, especially if they are the same size as pages... that doesn't + mean it always reads preceding pages; only if the read is in the middle + of the cluster AIUI + <LarstiQ> antrik: basically what braunr just pasted + <antrik> and in most cases, we will want to read some *following* clusters + as well, but probably not preceding ones + * LarstiQ nods + <braunr> antrik: the default policy is usually rather sequential + <braunr> here are the numbers for netbsd + <braunr> 166 static struct uvm_advice uvmadvice[] = { + <braunr> 167 { MADV_NORMAL, 3, 4 }, + <braunr> 168 { MADV_RANDOM, 0, 0 }, + <braunr> 169 { MADV_SEQUENTIAL, 8, 7}, + <braunr> 170 }; + <braunr> struct uvm_advice { + <braunr> int advice; + <braunr> int nback; + <braunr> int nforw; + <braunr> }; + <braunr> surprising isn't it ? + <braunr> they may suggest sequential may be backwards too + <braunr> makes sense + <antrik> braunr: what are these numbers? pages? + <braunr> yes + <antrik> braunr: I suspect the idea behind SEQUENTIAL is that with typical + sequential access patterns, you will start at one end of the file, and + then go towards the other end -- so the extra clusters in the "wrong" + direction do not actually come into play + <antrik> only situation where some extra clusters are actually read is when + you start in the middle of a file, and thus do not know yet in which + direction the sequential read will go... + <braunr> yes, there are similar comments in the linux code + <braunr> mcsim1: so having before and after numbers seems both + straightforward and in par with other implementations + <antrik> I'm still surprised about the almost symmetrical policy for NORMAL + though + <antrik> BTW, is it common to use heuristics for automatically recognizing + random and sequential patterns in the absence of explicit madise? + <braunr> i don't know + <braunr> netbsd doesn't use any, linux seems to have different behaviours + for anonymous and file memory + <antrik> when KAM was working on this stuff, someone suggested that... + <braunr> there is a file_ra_state struct in linux, for per file read-ahead + policy + <braunr> now the structure is of course per file system, since they all use + the same address + <braunr> (which is why i wanted it to be per pager in the first place) + <antrik> mcsim1: as I said before, it might be useful for the pager to + supply cluster size, if it's different than page size. but right now I + don't think this is something worth bothering with... + <antrik> I seriously doubt it would be useful for the pager to supply any + other kind of policy + <antrik> braunr: I don't understand your remark about using the same + address... + <antrik> braunr: pre-mapping seems the obvious way to implement readahead + policy + <antrik> err... per-mapping + <braunr> the ra_state (read ahead state) isn't the policy + <braunr> the policy is per mapping, parts of the implementation of the + policy is per file system + <mcsim1> braunr: How do you look at following implementation of NORMAL + policy: We have fault page that is current. Than we have maximal size of + readahead block. First we find first absent pages before and after + current. Than we try to fit block that will be readahead into this + range. Here could be following situations: in range RBS/2 (RBS -- size of + readahead block) there is no any page, so readahead will be symmetric; if + current page is first absent page than all + <mcsim1> RBS block will consist of pages that are after current; on the + contrary if current page is last absent than readahead will go backwards. + <mcsim1> Additionally if current page is approximately in the middle of the + range we can decrease RBS, supposing that access is random. + <braunr> mcsim1: i think your gsoc project is about readahead, we're in + july, and you need to get the job done + <braunr> mcsim1: grab one policy that works, pages before and after are + good enough + <braunr> use sane default values, let the pagers decide if they want + something else + <braunr> and concentrate on the real work now + <antrik> braunr: I still don't see why pagers should mess with that... only + complicates matters IMHO + <braunr> antrik: probably, since they almost all use the default + implementation + <braunr> mcsim1: just use sane values inside the kernel :p + <braunr> this simplifies things by only adding the new vm_advise call and + not change the existing external pager interface + + +## IRC, freenode, #hurd, 2012-07-12 + + <braunr> mcsim: so, to begin with, tell us what state you've reached please + <mcsim> braunr: I'm writing code for hurd and gnumach. For gnumach I'm + implementing memory policies now. RANDOM and NORMAL seems work, but in + hurd I found error that I made during editing ext2fs. So for now ext2fs + does not work + <braunr> policies ? + <braunr> what about mechanism ? + <mcsim> also I moved some translators to new interface. + <mcsim> It works too + <braunr> well that's impressive + <mcsim> braunr: I'm not sure yet that everything works + <braunr> right, but that's already a very good step + <braunr> i thought you were still working on the interfaces to be honest + <mcsim> And with mechanism I didn't implement moving pages to inactive + queue + <braunr> what do you mean ? + <braunr> ah you mean with the sequential policy ? + <mcsim> yes + <braunr> you can consider this a secondary goal + <mcsim> sequential I was going to implement like you've said, but I still + want to support moving pages to inactive queue + <braunr> i think you shouldn't + <braunr> first get to a state where clustered transfers do work fine + <mcsim> policies are implemented in function calculate_clusters + <braunr> then, you can try, and measure the difference + <mcsim> ok. I'm now working on fixing ext2fs + <braunr> so, except from bug squashing, what's left to do ? + <mcsim> finish policies and ext2fs; move fatfs, ufs, isofs to new + interface; test this all; edit patches from debian repository, that + conflict with my changes; rearrange commits and fix code indentation; + update documentation; + <braunr> think about measurements too + <tschwinge> mcsim: Please don't spend a lot of time on ufs. No testing + required for that one. + <braunr> and keep us informed about your progress on bug fixing, so we can + test soon + <mcsim> Forgot about moving system to new interfaces (I mean determine form + of vm_advise and memory_object_change_attributes) + <braunr> s/determine/final/ + <mcsim> braunr: ok. + <braunr> what do you mean "moving system to new interfaces" ? + <mcsim> braunr: I also pushed code changes to gnumach and hurd git + repositories + <mcsim> I met an issue with memory_object_change_attributes when I tried to + use it as I have to update all applications that use it. This includes + libc and translators that are not in hurd repository or use debian + patches. So I will not be able to run system with new + memory_object_change_attributes interface, until I update all software + that use this rpc + <braunr> this is a bit like the problem i had with my change + <braunr> the solution is : don't do it + <braunr> i mean, don't change the interface in an incompatible way + <braunr> if you can't change an existing call, add a new one + <mcsim> temporary I changed memory_object_set_attributes as it isn't used + any more. + <mcsim> braunr: ok. Adding new call is a good idea :) + + +## IRC, freenode, #hurd, 2012-07-16 + + <braunr> mcsim: how did you deal with multiple page transfers towards the + default pager ? + <mcsim> braunr: hello. Didn't handle this yet, but AFAIR default pager + supports multiple page transfers. + <braunr> mcsim: i'm almost sure it doesn't + <mcsim> braunr: indeed + <mcsim> braunr: So, I'll update it just other translators. + <braunr> like other translators you mean ? + <mcsim> *just as + <mcsim> braunr: yes + <braunr> ok + <braunr> be aware also that it may need some support in vm_pageout.c in + gnumach + <mcsim> braunr: thank you + <braunr> if you see anything strange in the default pager, don't hesitate + to talk about it + <mcsim> braunr: ok. I didn't finish with ext2fs yet. + <braunr> so it's a good thing you're aware of it now, before you begin + working on it :) + <mcsim> braunr: I'm working on ext2 now. + <braunr> yes i understand + <braunr> i meant "before beginning work on the default pager" + <mcsim> ok + + <antrik> mcsim: BTW, we were mostly talking about readahead (pagein) over + the past weeks, so I wonder what the status on clustered page*out* is?... + <mcsim> antrik: I don't work on this, but following, I think, is an example + of *clustered* pageout: _pager_seqnos_memory_object_data_return: object = + 113, seqno = 4, control = 120, start_address = 0, length = 8192, dirty = + 1. This is an example of debugging printout that shows that pageout + manipulates with chunks bigger than page sized. + <mcsim> antrik: Another one with bigger length + _pager_seqnos_memory_object_data_return: object = 125, seqno = 124, + control = 132, start_address = 131072, length = 126976, dirty = 1, kcopy + <antrik> mcsim: that's odd -- I didn't know the functionality for that even + exists in our codebase... + <antrik> my understanding was that Mach always sends individual pageout + requests for ever single page it wants cleaned... + <antrik> (and this being the reason for the dreadful thread storms we are + facing...) + <braunr> antrik: ok + <braunr> antrik: yes that's what is happening + <braunr> the thread storms aren't that much of a problem now + <braunr> (by carefully throttling pageouts, which is a task i intend to + work on during the following months, this won't be an issue any more) + + +## IRC, freenode, #hurd, 2012-07-19 + + <mcsim> I moved fatfs, ufs, isofs to new interface, corrected some errors + in other that I already moved, moved kernel to new interface (renamed + vm_advice to vm_advise and added rpcs memory_object_set_advice and + memory_object_get_advice). Made some changes in mechanism and tried to + finish ext2 translator. + <mcsim> braunr: I've got an issue with fictitious pages... + <mcsim> When I determine bounds of cluster in external object I never know + its actual size. So, mo_data_request call could ask data that are behind + object bounds. The problem is that pager returns data that it has and + because of this fictitious pages that were allocated are not freed. + <braunr> why don't you know the size ? + <mcsim> I see 2 solutions. First one is do not allocate fictitious pages at + all (but I think that there could be issues). Another lies in allocating + fictitious pages, but then freeing them with mo_data_lock. + <mcsim> braunr: Because pages does not inform kernel about object size. + <braunr> i don't understand what you mean + <mcsim> I think that second way is better. + <braunr> so how does it happen ? + <braunr> you get a page fault + <mcsim> Don't you understand problem or solutions? + <braunr> then a lookup in the map finds the map entry + <braunr> and the map entry gives you the link to the underlying object + <mcsim> from vm_object.h: vm_size_t size; /* + Object size (only valid if internal) */ + <braunr> mcsim: ugh + <mcsim> For external they are either 0x8000 or 0x20000... + <braunr> and for internal ? + <braunr> i'm very surprised to learn that + <mcsim> braunr: for internal size is actual + <braunr> right sorry, wrong question + <braunr> did you find what 0x8000 and 0x20000 are ? + <mcsim> for external I met only these 2 magic numbers when printed out + arguments of functions _pager_seqno_memory_object_... when they were + called. + <braunr> yes but did you try to find out where they come from ? + <mcsim> braunr: no. I think that 0x2000(many zeros) is maximal possible + object size. + <braunr> what's the exact value ? + <mcsim> can't tell exactly :/ My hurd box has broken again. + <braunr> mcsim: how does the vm find the backing content then ? + <mcsim> braunr: Do you know if it is guaranteed that map_entry size will be + not bigger than external object size? + <braunr> mcsim: i know it's not + <braunr> but you can use the map entry boundaries though + <mcsim> braunr: vm asks pager + <braunr> but if the page is already present + <braunr> how does it know ? + <braunr> it must be inside a vm_object .. + <mcsim> If I can use these boundaries than the problem, I described is not + actual. + <braunr> good + <braunr> it makes sense to use these boundaries, as the application can't + use data outside the mapping + <mcsim> I ask page with vm_page_lookup + <braunr> it would matter for shared objects, but then they have their own + faults :p + <braunr> ok + <braunr> so the size is actually completely ignord + <mcsim> if it is present than I stop expansion of cluster. + <braunr> which makes sense + <mcsim> braunr: yes, for external. + <braunr> all right + <braunr> use the mapping boundaries, it will do + <braunr> mcsim: i have only one comment about what i could see + <braunr> mcsim: there are 'advice' fields in both vm_map_entry and + vm_object + <braunr> there should be something else in vm_object + <braunr> i told you about pages before and after + <braunr> mcsim: how are you using this per object "advice" currently ? + <braunr> (in addition, using the same name twice for both mechanism and + policy is very sonfusing) + <braunr> confusing* + <mcsim> braunr: I try to expand cluster as much as it possible, but not + much than limit + <mcsim> they both determine policy, but advice for entry has bigger + priority + <braunr> that's wrong + <braunr> mapping and content shouldn't compete for policy + <braunr> the mapping tells the policy (=the advice) while the content tells + how to implement (e.g. how much content) + <braunr> IMO, you could simply get rid of the per object "advice" field and + use default values for now + <mcsim> braunr: What sense these values for number of pages before and + after should have? + <braunr> or use something well known, easy, and effective like preceding + and following pages + <braunr> they give the vm the amount of content to ask the backing pager + <mcsim> braunr: maximal amount, minimal amount or exact amount? + <braunr> neither + <braunr> that's why i recommend you forget it for now + <braunr> but + <braunr> imagine you implement the three standard policies (normal, random, + sequential) + <braunr> then the pager assigns preceding and following numbers for each of + them, say [5;5], [0;0], [15;15] respectively + <braunr> these numbers would tell the vm how many pages to ask the pagers + in a single request and from where + <mcsim> braunr: but in fact there could be much more policies. + <braunr> yes + <mcsim> also in kernel context there is no such unit as pager. + <braunr> so there should be a call like memory_object_set_advice(int + advice, int preceding, int following); + <braunr> for example + <braunr> what ? + <braunr> the pager is the memory manager + <braunr> it does exist in kernel context + <braunr> (or i don't understand what you mean) + <mcsim> there is only port, but port could be either pager or something + else + <braunr> no, it's a pager + <braunr> it's a port whose receive right is hold by a task implementing the + pager interface + <braunr> either the default pager or an untrusted task + <braunr> (or null if the object is anonymous memory not yet sent to the + default pager) + <mcsim> port is always pager? + <braunr> the object port is, yes + <braunr> struct ipc_port *pager; /* Where to get + data */ + <mcsim> So, you suggest to keep set of advices for each object? + <braunr> i suggest you don't change anything in objects for now + <braunr> keep the advice in the mappings only, and implement default + behaviour for the known policies + <braunr> mcsim: if you understand this point, then i have nothing more to + say, and we should let nowhere_man present his work + <mcsim> braunr: ok. I'll implement only default behaviors for know policies + for now. + <braunr> (actually, using the mapping boundaries is slightly unoptimal, as + we could have several mappings for the same content, e.g. a program with + read only executable mapping, then ro only) + <braunr> mcsim: another way to know the "size" is to actually lookup for + pages in objects + <braunr> hm no, that's not true + <mcsim> braunr: But if there is no page we have to ask it + <mcsim> and I don't understand why using mappings boundaries is unoptimal + <braunr> here is bash + <braunr> 0000000000400000 868K r-x-- /bin/bash + <braunr> 00000000006d9000 36K rw--- /bin/bash + <braunr> two entries, same file + <braunr> (there is the anonymous memory layer for the second, but it would + matter for the first cow faults) + + +## IRC, freenode, #hurd, 2012-08-02 + + <mcsim> braunr: You said that I probably need some support in vm_pageout.c + to make defpager work with clustered page transfers, but TBH I thought + that I have to implement only pagein. Do you expect from me implementing + pageout either? Or I misunderstand role of vm_pageout.c? + <braunr> no + <braunr> you're expected to implement only pagins for now + <braunr> pageins + <mcsim> well, I'm finishing merging of ext2fs patch for large stores and + work on defpager in parallel. + <mcsim> braunr: Also I didn't get your idea about configuring of paging + mechanism on behalf of pagers. + <braunr> which one ? + <mcsim> braunr: You said that pager has somehow pass size of desired + clusters for different paging policies. + <braunr> mcsim: i said not to care about that + <braunr> and the wording isn't correct, it's not "on behalf of pagers" + <mcsim> servers? + <braunr> pagers could tell the kernel what size (before and after a faulted + page) they prefer for each existing policy + <braunr> but that's one way to do it + <braunr> defaults work well too + <braunr> as shown in other implementations + + +## IRC, freenode, #hurd, 2012-08-09 + + <mcsim> braunr: I'm still debugging ext2 with large storage patch + <braunr> mcsim: tough problems ? + <mcsim> braunr: The same issues as I always meet when do debugging, but it + takes time. + <braunr> mcsim: so nothing blocking so far ? + <mcsim> braunr: I can't tell you for sure that I will finish up to 13th of + August and this is unofficial pencil down date. + <braunr> all right, but are you blocked ? + <mcsim> braunr: If you mean the issues that I can not even imagine how to + solve than there is no ones. + <braunr> good + <braunr> mcsim: i'll try to review your code again this week end + <braunr> mcsim: make sure to commit everything even if it's messy + <mcsim> braunr: ok + <mcsim> braunr: I made changes to defpager, but I haven't tried + them. Commit them too? + <braunr> mcsim: sure + <braunr> mcsim: does it work fine without the large storage patch ? + <mcsim> braunr: looks fine, but TBH I can't even run such things like fsx, + because even without my changes it failed mightily at once. + <braunr> mcsim: right, well, that will be part of another task :) + + +## IRC, freenode, #hurd, 2012-08-13 + + <mcsim> braunr: hello. Seems ext2fs with large store patch works. + + +## IRC, freenode, #hurd, 2012-08-19 + + <mcsim> hello. Consider such situation. There is a page fault and kernel + decided to request pager for several pages, but at the moment pager is + able to provide only first pages, the rest ones are not know yet. Is it + possible to supply only one page and regarding rest ones tell the kernel + something like: "Rest pages try again later"? + <mcsim> I tried pager_data_unavailable && pager_flush_some, but this seems + does not work. + <mcsim> Or I have to supply something anyway? + <braunr> mcsim: better not provide them + <braunr> the kernel only really needs one page + <braunr> don't try to implement "try again later", the kernel will do that + if other page faults occur for those pages + <mcsim> braunr: No, translator just hangs + <braunr> ? + <mcsim> braunr: And I even can't deattach it without reboot + <braunr> hangs when what + <braunr> ? + <braunr> i mean, what happens when it hangs ? + <mcsim> If kernel request 2 pages and I provide one, than when page fault + occurs in second page translator hangs. + <braunr> well that's a bug + <braunr> clustered pager transfer is a mere optimization, you shouldn't + transfer more than you can just to satisfy some requested size + <mcsim> I think that it because I create fictitious pages before calling + mo_data_request + <braunr> as placeholders ? + <mcsim> Yes. Is it correct if I will not grab fictitious pages? + <braunr> no + <braunr> i don't know the details well enough about fictitious pages + unfortunately, but it really feels wrong to use them where real physical + pages should be used instead + <braunr> normally, an in-transfer page is simply marked busy + <mcsim> But If page is already marked busy kernel will not ask it another + time. + <braunr> when the pager replies, you unbusy them + <braunr> your bug may be that you incorrectly use pmap + <braunr> you shouldn't create mmu mappings for pages you didn't receive + from the pagers + <mcsim> I don't create them + <braunr> ok so you correctly get the second page fault + <mcsim> If pager supplies only first pages, when asked were two, than + second page will not become un-busy. + <braunr> that's a bug + <braunr> your code shouldn't assume the pager will provide all the pages it + was asked for + <braunr> only the main one + <mcsim> Will it be ok if I will provide special attribute that will keep + information that page has been advised? + <braunr> what for ? + <braunr> i don't understand "page has been advised" + <mcsim> Advised page is page that is asked in cluster, but there wasn't a + page fault in it. + <mcsim> I need this attribute because if I don't inform kernel about this + page anyhow, than kernel will not change attributes of this page. + <braunr> why would it change its attributes ? + <mcsim> But if page fault will occur in page that was asked than page will + be already busy by the moment. + <braunr> and what attribute ? + <mcsim> advised + <braunr> i'm lost + <braunr> 08:53 < mcsim> I need this attribute because if I don't inform + kernel about this page anyhow, than kernel will not change attributes of + this page. + <braunr> you need the advised attribute because if you don't inform the + kernel about this page, the kernel will not change the advised attribute + of this page ? + <mcsim> Not only advised, but busy as well. + <mcsim> And if page fault will occur in this page, kernel will not ask it + second time. Kernel will just block. + <braunr> well that's normal + <mcsim> But if kernel will block and pager is not going to report somehow + about this page, than translator will hang. + <braunr> but the pager is going to report + <braunr> and in this report, there can be less pages then requested + <mcsim> braunr: You told not to report + <braunr> the kernel can deduce it didn't receive all the pages, and mark + them unbusy anyway + <braunr> i told not to transfer more than requested + <braunr> but not sending data can be a form of communication + <braunr> i mean, sending a message in which data is missing + <braunr> it simply means its not there, but this info is sufficient for the + kernel + <mcsim> hmmm... Seems I understood you. Let me try something. + <mcsim> braunr: I informed kernel about missing page as follows: + pager_data_supply (pager, precious, writelock, i, 1, NULL, 0); Am I + right? + <braunr> i don't know the interface well + <braunr> what does it mean + <braunr> ? + <braunr> are you passing NULL as the data for a missing page ? + <mcsim> yes + <braunr> i see + <braunr> you shouldn't need a request for that though, avoiding useless ipc + is a good thing + <mcsim> i is number of page, 1 is quantity + <braunr> but if you can't find a better way for now, it will do + <mcsim> But this does not work :( + <braunr> that's a bug + <braunr> in your code probably + <mcsim> braunr: supplying NULL as data returns MACH_SEND_INVALID_MEMORY + <braunr> but why would it work ? + <braunr> mach expects something + <braunr> you have to change that + <mcsim> It's mig who refuses data. Mach does not even get the call. + <braunr> hum + <mcsim> That's why I propose to provide new attribute, that will keep + information regarding whether the page was asked as advice or not. + <braunr> i still don't understand why + <braunr> why don't you fix mig so you can your null message instead ? + <braunr> +send + <mcsim> braunr: because usually this is an error + <braunr> the kernel will decide if it's an erro + <braunr> r + <braunr> what kinf of reply do you intend to send the kernel with for these + "advised" pages ? + <mcsim> no reply. But when page fault will occur in busy page and it will + be also advised, kernel will not block, but ask this page another time. + <mcsim> And how kernel will know that this is an error or not? + <braunr> why ask another time ?! + <braunr> you really don't want to flood pagers with useless messages + <braunr> here is how it should be + <braunr> 1/ the kernel requests pages from the pager + <braunr> it know the range + <braunr> 2/ the pager replies what it can, full range, subset of it, even + only one page + <braunr> 3/ the kernel uses what the pager replied, and unbusies the other + pages + <mcsim> First time page was asked because page fault occurred in + neighborhood. And second time because PF occurred in page. + <braunr> well it shouldn't + <braunr> or it should, but then you have a segfault + <mcsim> But kernel does not keep bound of range, that it asked. + <braunr> if the kernel can't find the main page, the one it needs to make + progress, it's a segfault + <mcsim> And this range could be supplied in several messages. + <braunr> absolutely not + <braunr> you defeat the purpose of clustered pageins if you use several + messages + <mcsim> But interface supports it + <braunr> interface supported single page transfers, doesn't mean it's good + <braunr> well, you could use several messages + <braunr> as what we really want is less I/O + <mcsim> Noone keeps bounds of requested range, so it couldn't be checked + that range was split + <braunr> but it would be so much better to do it all with as few messages + as possible + <braunr> does the kernel knows the main page ? + <braunr> know* + <mcsim> Splitting range is not optimal, but it's not an error. + <braunr> i assume it does + <braunr> doesn't it ? + <mcsim> no, that's why I want to provide new attribute. + <braunr> i'm sorry i'm lost again + <braunr> how does the kernel knows a page fault has been serviced ? + <braunr> know* + <mcsim> It receives an interrupt + <braunr> ? + <braunr> let's not mix terms + <mcsim> oh.. I read as received. Sorry + <mcsim> It get mo_data_supply message. Than it replaces fictitious pages + with real ones. + <braunr> so you get a message + <braunr> and you kept track of the range using fictitious pages + <braunr> use the busy flag instead, and another way to retain the range + <mcsim> I allocate fictitious pages to reserve place. Than if page fault + will occur in this page fictitious page kernel will not send another + mo_data_request call, it will wait until fictitious page unblocks. + <braunr> i'll have to check the code but it looks unoptimal to me + <braunr> we really don't want to allocate useless objects when a simple + busy flag would do + <mcsim> busy flag for what? There is no page yet + <braunr> we're talking about mo_data_supply + <braunr> actually we're talking about the whole page fault process + <mcsim> We can't mark nothing as busy, that's why kernel allocates + fictitious page and marks it as busy until real page would be supplied. + <braunr> what do you mean "nothing" ? + <mcsim> VM_PAGE_NULL + <braunr> uh ? + <braunr> when are physical pages allocated ? + <braunr> on request or on reply from the pager ? + <braunr> i'm reading mo_data_supply, and it looks like the page is already + busy at that time + <mcsim> they are allocated by pager and than supplied in reply + <mcsim> Yes, but these pages are fictitious + <braunr> show me please + <braunr> in the master branch, not yours + <mcsim> that page is fictitious? + <braunr> yes + <braunr> i'm referring to the way mach currently does things + <mcsim> vm/vm_fault.c:582 + <braunr> that's memory_object_lock_page + <braunr> hm wait + <braunr> my bad + <braunr> ah that damn object chaining :/ + <braunr> ok + <braunr> the original code is stupid enough to use fictitious pages all the + time, you probably have to do the same + <mcsim> hm... Attributes will be useless, pager should tell something about + pages, that it is not going to supply. + <braunr> yes + <braunr> that's what null is for + <mcsim> Not null, null is error. + <braunr> one problem i can think of is making sure the kernel doesn't + interpret missing as error + <braunr> right + <mcsim> I think better have special value for mo_data_error + <braunr> probably + + +### IRC, freenode, #hurd, 2012-08-20 + + <antrik> braunr: I think it's useful to allow supplying the data in several + batches. the kernel should *not* assume that any data missing in the + first batch won't be supplied later. + <braunr> antrik: it really depends + <braunr> i personally prefer synchronous approaches + <antrik> demanding that all data is supplied at once could actually turn + readahead into a performace killer + <mcsim> antrik: Why? The only drawback I see is higher response time for + page fault, but it also leads to reduced overhead. + <braunr> that's why "it depends" + <braunr> mcsim: it brings benefit only if enough preloaded pages are + actually used to compensate for the time it took the pager to provide + them + <braunr> which is the case for many workloads (including sequential access, + which is the common case we want to optimize here) + <antrik> mcsim: the overhead of an extra RPC is negligible compared to + increased latencies when dealing with slow backing stores (such as disk + or network) + <mcsim> antrik: also many replies lead to fragmentation, while in one reply + all data is gathered in one bunch. If all data is placed consecutively, + than it may be transferred next time faster. + <braunr> mcsim: what kind of fragmentation ? + <antrik> I really really don't think it's a good idea for the page to hold + back the first page (which is usually the one actually blocking) while + it's still loading some other pages (which will probably be needed only + in the future anyways, if at all) + <antrik> err... for the pager to hold back + <braunr> antrik: then all pagers should be changed to handle asynchronous + data supply + <braunr> it's a bit late to change that now + <mcsim> there could be two cases of data placement in backing store: 1/ all + asked data is placed consecutively; 2/ it is spread among backing + store. If pager gets data in one message it more like place it + consecutively. So to have data consecutive in each pager, each pager has + to try send data in one message. Having data placed consecutive is + important, since reading of such data is much more faster. + <braunr> mcsim: you're confusing things .. + <braunr> or you're not telling them properly + <mcsim> Ok. Let me try one more time + <braunr> since you're working *only* on pagein, not pageout, how do you + expect spread pages being sent in a single message be better than + multiple messages ? + <mcsim> braunr: I think about future :) + <braunr> ok + <braunr> but antrik is right, paging in too much can reduce performance + <braunr> so the default policy should be adjusted for both the worst case + (one page) and the average/best (some/mane contiguous pages) + <braunr> through measurement ideally + <antrik> mcsim: BTW, I still think implementing clustered pageout has + higher priority than implementing madvise()... but if the latter is less + work, it might still make sense to do it first of course :-) + <braunr> many* + <braunr> there aren't many users of madvise, true + <mcsim> antrik: Implementing madvise I expect to be very simple. It should + just translate call to vm_advise + <antrik> well, that part is easy of course :-) so you already implemented + vm_advise itself I take it? + <mcsim> antrik: Yes, that was also quite easy. + <antrik> great :-) + <antrik> in that case it would be silly of course to postpone implementing + the madvise() wrapper. in other words: never mind my remark about + priorities :-) + + +## IRC, freenode, #hurd, 2012-09-03 + + <mcsim> I try a test with ext2fs. It works, than I just recompile ext2fs + and it stops working, than I recompile it again several times and each + time the result is unpredictable. + <braunr> sounds like a concurrency issue + <mcsim> I can run the same test several times and ext2 works until I + recompile it. That's the problem. Could that be concurrency too? + <braunr> mcsim: without bad luck, yes, unless "several times" is a lot + <braunr> like several dozens of tries + + +## IRC, freenode, #hurd, 2012-09-04 + + <mcsim> hello. I want to tell that ext2fs translator, that I work on, + replaced for my system old variant that processed only single pages + requests. And it works with partitions bigger than 2 Gb. + <mcsim> Probably I'm not for from the end. + <mcsim> But it's worth to mention that I didn't fix that nasty bug that I + told yesterday about. + <mcsim> braunr: That bug sometimes appears after recompilation of ext2fs + and always disappears after sync or reboot. Now I'm going to finish + defpager and test other translators. + + +## IRC, freenode, #hurd, 2012-09-17 + + <mcsim> braunr: hello. Do you remember that you said that pager has to + inform kernel about appropriate cluster size for readahead? + <mcsim> I don't understand how kernel store this information, because it + does not know about such unit as "pager". + <mcsim> Can you give me an advice about how this could be implemented? + <youpi> mcsim: it can store it in the object + <mcsim> youpi: It too big overhead + <mcsim> youpi: at least from my pow + <mcsim> *pov + <braunr> mcsim: we discussed this already + <braunr> mcsim: there is no "pager" entity in the kernel, which is a defect + from my PoV + <braunr> mcsim: the best you can do is follow what the kernel already does + <braunr> that is, store this property per object$ + <braunr> we don't care much about the overhead for now + <braunr> my guess is there is already some padding, so the overhead is + likely to be amortized by this + <braunr> like youpi said + <mcsim> I remember that discussion, but I didn't get than whether there + should be only one or two values for all policies. Or each policy should + have its own values? + <mcsim> braunr: ^ + <braunr> each policy should have its own values, which means it can be + implemented with a simple static array somewhere + <braunr> the information in each object is a policy selector, such as an + index in this static array + <mcsim> ok + <braunr> mcsim: if you want to minimize the overhead, you can make this + selector a char, and place it near another char member, so that you use + space that was previously used as padding by the compiler + <braunr> mcsim: do you see what i mean ? + <mcsim> yes + <braunr> good + + +## IRC, freenode, #hurd, 2012-09-17 + + <mcsim> hello. May I add function krealloc to slab.c? + <braunr> mcsim: what for ? + <mcsim> braunr: It is quite useful for creating dynamic arrays + <braunr> you don't want dynamic arrays + <mcsim> why? + <braunr> they're expensive + <braunr> try other data structures + <mcsim> more expensive than linked lists? + <braunr> depends + <braunr> but linked lists aren't the only other alternative + <braunr> that's why btrees and radix trees (basically trees of arrays) + exist + <braunr> the best general purpose data structure we have in mach is the red + black tree currently + <braunr> but always think about what you want to do with it + <mcsim> I want to store there sets of sizes for different memory + policies. I don't expect this array to be big. But for sure I can use + rbtree for it. + <braunr> why not a static array ? + <braunr> arrays are perfect for known data sizes + <mcsim> I expect from pager to supply its own sizes. So at the beginning in + this array is only default policy. When pager wants to supply it own + policy kernel lookups table of advice. If this policy is new set of sizes + then kernel creates new entry in table of advice. + <braunr> that would mean one set of sizes for each object + <braunr> why don't you make things simple first ? + <mcsim> Object stores only pointer to entry in this table. + <braunr> but there is no pager object shared by memory objects in the + kernel + <mcsim> I mean struct vm_object + <braunr> so that's what i'm saying, one set per object + <braunr> it's useless overhead + <braunr> i would really suggest using a global set of policies for now + <mcsim> Probably, I don't understand you. Where do you want to store this + static array? + <braunr> it's a global one + <mcsim> "for now"? It is not a problem to implement a table for local + advice, using either rbtree or dynamic array. + <braunr> it's useless overhead + <braunr> and it's not a single integer, you want a whole container per + object + <braunr> don't do anything fancy unless you know you really want it + <braunr> i'll link the netbsd code again as a very good example of how to + implement global policies that work more than decently for every file + system in this OS + <braunr> + http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/uvm/uvm_fault.c?rev=1.194&content-type=text/x-cvsweb-markup&only_with_tag=MAIN + <braunr> look for uvmadvice + <mcsim> But different translators have different demands. Thus changing of + global policy for one translator would have impact on behavior of another + one. + <braunr> i understand + <braunr> this isn't l4, or anything experimental + <braunr> we want something that works well for us + <mcsim> And this is acceptable? + <braunr> until you're able to demonstrate we need different policies, i'd + recommend not making things more complicated than they already are and + need to be + <braunr> why wouldn't it ? + <braunr> we've been discussing this a long time :/ + <mcsim> because every process runs in isolated environment and the fact + that there is something outside this environment, that has no rights to + do that, does it surprises me. + <braunr> ? + <mcsim> ok. let me dip in uvm code. Probably my questions disappear + <braunr> i don't think it will + <braunr> you're asking about the system design here, not implementation + details + <braunr> with l4, there are as you'd expect well defined components + handling policies for address space allocation, or paging, or whatever + <braunr> but this is mach + <braunr> mach has a big shared global vm server with in kernel policies for + it + <braunr> so it's ok to implement a global policy for this + <braunr> and let's be pragmatic, if we don't need complicated stuff, why + would we waste time on this ? + <mcsim> It is not complicated. + <braunr> retaining a whole container for each object, whereas they're all + going to contain exactly the same stuff for years to come seems overly + complicated for me + <mcsim> I'm not going to create separate container for each object. + <braunr> i'm not following you then + <braunr> how can pagers upload their sizes in the kernel ? + <mcsim> I'm going to create a new container only for combination of cluster + sizes that are not present in table of advice. + <braunr> that's equivalent + <braunr> you're ruling out the default set, but that's just an optimization + <braunr> whenever a file system decides to use other sizes, the problem + will arise + <mcsim> Before creating a container I'm going to lookup a table. And only + than create + <braunr> a table ? + <mcsim> But there will be the same container for a huge bunch of objects + <braunr> how do you select it ? + <braunr> if it's a per pager container, remember there is no shared pager + object in the kernel, only ports to external programs + <mcsim> I'll give an example + <mcsim> Suppose there are only two policies. At the beginning we have table + {{random = 4096, sequential = 8096}}. Than pager 1 wants to add new + policy where random cluster size is 8192. He asks kernel to create it and + after this table will be following: {{random = 4096, sequential = 8192}, + {random = 8192, sequential = 8192}}. If pager 2 wants to create the same + policy as pager 1, kernel will lockup table and will not create new + entry. So the table will be the same. + <mcsim> And each object has link to appropriate table entry + <braunr> i'm not sure how this can work + <braunr> how can pagers 1 and 2 know the sizes are the same for the same + policy ? + <braunr> (and actually they shouldn't) + <mcsim> For faster lookup there will be create hash keys for each entry + <braunr> what's the lookup key ? + <mcsim> They do not know + <mcsim> The kernel knows + <braunr> then i really don't understand + <braunr> and how do you select sizes based on the policy ? + <braunr> and how do you remove unused entries ? + <braunr> (ok this can be implemented with a simple ref counter) + <mcsim> "and how do you select sizes based on the policy ?" you mean at + page fault? + <braunr> yes + <mcsim> entry or object keeps pointer to appropriate entry in the table + <braunr> ok your per object data is a pointer to the table entry and the + policy is the index inside + <braunr> so you really need a ref counter there + <mcsim> yes + <braunr> and you need to maintain this table + <braunr> for me it's uselessly complicated + <mcsim> but this keeps design clear + <braunr> not for me + <braunr> i don't see how this is clearer + <braunr> it's just more powerful + <braunr> a power we clearly don't need now + <braunr> and in the following years + <braunr> in addition, i'm very worried about the potential problems this + can introduce + <mcsim> In fact I don't feel comfortable from the thought that one + translator can impact on behavior of another. + <braunr> simple example: the table is shared, it needs a lock, other data + structures you may have added in your patch may also need a lock + <braunr> but our locks are noop for now, so you just can't be sure there is + no deadlock or other issues + <braunr> and adding smp is a *lot* more important than being able to select + precisely policy sizes that we're very likely not to change a lot + <braunr> what do you mean by "one translator can impact another" ? + <mcsim> As I understand your idea (I haven't read uvm code yet) that there + is a global table of cluster sizes for different policies. And every + translator can change values in this table. That is what I mean under one + translator will have an impact on another one. + <braunr> absolutely not + <braunr> translators *can't* change sizes + <braunr> the sizes are completely static, assumed to be fit all + <braunr> -be + <braunr> it's not optimial but it's very simple and effective in practice + <braunr> optimal* + <braunr> and it's not a table of cluster sizes + <braunr> it's a table of pages before/after the faulted one + <braunr> this reflects the fact tha in mach, virtual memory (implementation + and policy) is in the kernel + <braunr> translators must not be able to change that + <braunr> let's talk about pagers here, not translators + <mcsim> Finally I got you. This is an acceptable tradeoff. + <braunr> it took some time :) + <braunr> just to clear something + <braunr> 20:12 < mcsim> For faster lookup there will be create hash keys + for each entry + <braunr> i'm not sure i understand you here + <mcsim> To found out if there is such policy (set of sizes) in the table we + can lookup every entry and compare each value. But it is better to create + a hash value for set and thus find equal policies. + <braunr> first, i'm really not comfortable with hash tables + <braunr> they really need careful configuration + <braunr> next, as we don't expect many entries in this table, there is + probably no need for this overhead + <braunr> remember that one property of tables is locality of reference + <braunr> you access the first entry, the processor automatically fills a + whole cache line + <braunr> so if your table fits on just a few, it's probably faster to + compare entries completely than to jump around in memory + <mcsim> But we can sort hash keys, and in this way find policies quickly. + <braunr> cache misses are way slower than computation + <braunr> so unless you have massive amounts of data, don't use an optimized + container + <mcsim> (20:38:53) braunr: that's why btrees and radix trees (basically + trees of arrays) exist + <mcsim> and what will be the key? + <braunr> i'm not saying to use a tree instead of a hash table + <braunr> i'm saying, unless you have many entries, just use a simple table + <braunr> and since pagers don't add and remove entries from this table + often, it's on case reallocation is ok + <braunr> one* + <mcsim> So here dynamic arrays fit the most? + <braunr> probably + <braunr> it really depends on the number of entries and the write ratio + <braunr> keep in mind current processors have 32-bits or (more commonly) + 64-bits cache line sizes + <mcsim> bytes probably? + <braunr> yes bytes + <braunr> but i'm not willing to add a realloc like call to our general + purpose kernel allocator + <braunr> i don't want to make it easy for people to rely on it, and i hope + the lack of it will make them think about other solutions instead :) + <braunr> and if they really want to, they can just use alloc/free + <mcsim> Under "other solutions" you mean trees? + <braunr> i mean anything else :) + <braunr> lists are simple, trees are elegant (but add non negligible + overhead) + <braunr> i like trees because they truely "gracefully" scale + <braunr> but they're still O(log n) + <braunr> a good hash table is O(1), but must be carefully measured and + adjusted + <braunr> there are many other data structures, many of them you can find in + linux + <braunr> but in mach we don't need a lot of them + <mcsim> Your favorite data structures are lists and trees. Next, what + should you claim, is that lisp is your favorite language :) + <braunr> functional programming should eventually rule the world, yes + <braunr> i wouldn't count lists are my favorite, which are really trees + <braunr> as* + <braunr> there is a reason why red black trees back higher level data + structures like vectors or maps in many common libraries ;) + <braunr> mcsim: hum but just to make it clear, i asked this question about + hashing because i was curious about what you had in mind, i still think + it's best to use static predetermined values for policies + <mcsim> braunr: I understand this. + <braunr> :) + <mcsim> braunr: Yeah. You should be cautious with me :) + + +## IRC, freenode, #hurd, 2012-09-21 + + <antrik> mcsim: there is only one cluster size per object -- it depends on + the properties of the backing store, nothing else. + <antrik> (while the readahead policies depend on the use pattern of the + application, and thus should be selected per mapping) + <antrik> but I'm still not convinced it's worthwhile to bother with cluster + size at all. do other systems even do that?... + + +## IRC, freenode, #hurd, 2012-09-23 + + <braunr> mcsim: how long do you think it will take you to polish your gsoc + work ? + <braunr> (and when before you begin that part actually, because we'll to + review the whole stuff prior to polishing it) + <mcsim> braunr: I think about 2 weeks + <mcsim> But you may already start review it, if you're intended to do it + before I'll rearrange commits. + <mcsim> Gnumach, ext2fs and defpager are ready. I just have to polish the + code. + <braunr> mcsim: i don't know when i'll be able to do that + <braunr> so expect a few weeks on my (our) side too + <mcsim> ok + <braunr> sorry for being slow, that's how hurd development is :) + <mcsim> What should I do with libc patch that adds madvise support? + <mcsim> Post it to bug-hurd? + <braunr> hm probably the same i did for pthreads, create a topic branch in + glibc.git + <mcsim> there is only one commit + <braunr> yes + <braunr> (mine was a one liner :p) + <mcsim> ok + <braunr> it will probably be a debian patch before going into glibc anyway, + just for making sure it works + <mcsim> But according to term. I expect that my study begins in a week and + I'll have to do some stuff then, so actually probably I'll need a week + more. + <braunr> don't worry, that's expected + <braunr> and that's the reason why we're slow + <mcsim> And what should I do with large store patch? + <braunr> hm good question + <braunr> what did you do for now ? + <braunr> include it in your work ? + <braunr> that's what i saw iirc + <mcsim> Yes. It consists of two parts. + <braunr> the original part and the modificaionts ? + <braunr> modifications* + <braunr> i think youpi would know better about that + <mcsim> First (small) adds notification to libpager interface and second + one adds support for large stores. + <braunr> i suppose we'll probably merge the large store patch at some point + anyway + <mcsim> Yes both original and modifications + <braunr> good + <mcsim> I'll split these parts to different commits and I'll try to make + support for large stores independent from other work. + <braunr> that would be best + <braunr> if you can make it so that, by ommitting (or including) one patch, + we can add your patches to the debian package, it would be great + <braunr> (only with regard to the large store change, not other potential + smaller conflicts) + <mcsim> braunr: I also found several bugs in defpager, that I haven't fixed + since winter. + <braunr> oh + <mcsim> seems nobody hasn't expect them. + <braunr> i'm very interested in those actually (not too soon because it + concerns my work on pageout, which is postponed after pthreads and + select) + <mcsim> ok. than I'll do it first. + + +## IRC, freenode, #hurd, 2012-09-24 + + <braunr> mcsim: what is vm_get_advice_info ? + <mcsim> braunr: hello. It should supply some machine specific parameters + regarding clustered reading. At the moment it supplies only maximal + possible size of cluster. + <braunr> mcsim: why such a need ? + <mcsim> It is used by defpager, as it can't allocate memory dynamically and + every thread has to allocate maximal size beforehand + <braunr> mcsim: i see + + +## IRC, freenode, #hurd, 2012-10-05 + + <mcsim> braunr: I think it's not worth to separate large store patch for + ext2 and patch for moving it to new libpager interface. Am I right? + <braunr> mcsim: it's worth separating, but not creating two versions + <braunr> i'm not sure what you mean here + <mcsim> First, I applied large store patch, and than I was changing patched + code, to make it work with new libpager interface. So changes to make + ext2 work with new interface depend on large store patch. + <mcsim> braunr: ^ + <braunr> mcsim: you're not forced to make each version resulting from a new + commit work + <braunr> but don't make big commits + <braunr> so if changing an interface requires its users to be updated + twice, it doesn't make sense to do that + <braunr> just update the interface cleanly, you'll have one or more commits + that produce intermediate version that don't build, that's ok + <braunr> then in another, separate commit, adjust the users + <mcsim> braunr: The only user now is ext2. And the problem with ext2 is + that I updated not the version from git repository, but the version, that + I've got after applying the large store patch. So in other words my + question is follows: should I make a commit that moves to new interface + version of ext2fs without large store patch? + <braunr> you're asking if you can include the large store patch in your + work, and by extension, in the main branch + <braunr> i would say yes, but this must be discussed with others diff --git a/open_issues/performance/ipc_virtual_copy.mdwn b/open_issues/performance/ipc_virtual_copy.mdwn new file mode 100644 index 00000000..9708ab96 --- /dev/null +++ b/open_issues/performance/ipc_virtual_copy.mdwn @@ -0,0 +1,395 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-09-02: + + <slpz> what's the usual throughput for I/O operations (like "dd + if=/dev/zero of=/dev/null") in one of those Xen based Hurd machines + (*bber)? + <braunr> good question + <braunr> slpz: but don't use /dev/zero and /dev/null, as they don't have + anything to do with true I/O operations + <slpz> braunr: in fact, I want to test the performance of IPC's virtual + copy operations + <braunr> ok + <slpz> braunr: sorry, the "I/O" was misleading + <braunr> use bs=4096 then i guess + <slpz> bs > 2k + <braunr> ? + <slpz> braunr: everything about 2k is copied by vm_map_copyin/copyout + <slpz> s/about/above/ + <slpz> braunr: MiG's stubs check for that value and generate complex (with + out_of_line memory) messages if datalen is above 2k, IIRC + <braunr> ok + <braunr> slpz: found it, thanks + <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 13469 + <tschwinge> 17091+0 records in + <tschwinge> 17090+0 records out + <tschwinge> 70000640 bytes (70 MB) copied, 17.1436 s, 4.1 MB/s + <tschwinge> Note, however 10 s vs. 17 s! + <tschwinge> And this is slow compared to heal hardware: + <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! && + sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 28290 + <tschwinge> 93611+0 records in + <tschwinge> 93610+0 records out + <tschwinge> 383426560 bytes (383 MB) copied, 9.99 s, 38.4 MB/s + <braunr> tschwinge: is the first result on xen vm ? + <tschwinge> I think so. + <braunr> :/ + <slpz> tschwinge: Thanks! Could you please try with a higher block size, + something like 128k or 256k? + <tschwinge> strauss is on a machine that also hosts a buildd, I think. + <braunr> oh ok + <pinotree> yes, aside either rossini or mozart + <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). + +[[open_issues/time]] + + <braunr> slpz: i'll set up xen hosts soon and can try those tests while + nothing else runs to have more accurate results + <tschwinge> tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=256k & + p=$! && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 13482 + <tschwinge> 4566+0 records in + <tschwinge> 4565+0 records out + <tschwinge> 1196687360 bytes (1.2 GB) copied, 13.6751 s, 87.5 MB/s + <braunr> slpz: gains are logarithmic beyond the page size + <tschwinge> thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=256k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + <tschwinge> [1] 28295 + <tschwinge> 6335+0 records in + <tschwinge> 6334+0 records out + <tschwinge> 1660420096 bytes (1.7 GB) copied, 9.99 s, 166 MB/s + <tschwinge> This time a the sleep 10 decided to take 13.6 s. + ``Interesting.'' + <slpz> tschwinge: Thanks again. The results for the Xen machine are not bad + though. I can't obtain a throughput over 50MB/s with KVM. + <tschwinge> slpz: Want more data (bs)? Just tell. + <braunr> slpz: i easily get more than that + <braunr> slpz: what buffer size do you use ? + <slpz> tschwinge: no, I just wanted to see if Xen has an upper limit beyond + KVM's. Thank you. + <slpz> braunr: I try with different sizes until I find the maximum + throughput for a certain amount of requests (count) + <slpz> braunr: are you working with KVM? + <braunr> yes + <braunr> slpz: my processor is a model name : Intel(R) Core(TM)2 Duo + CPU E7500 @ 2.93GHz + <braunr> Linux silvermoon 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC + 2011 x86_64 GNU/Linux + <braunr> (standard amd64 squeeze kernel) + <slpz> braunr: and KVM's version? + <braunr> squeeze (0.12.5) + <braunr> bbl + <gnu_srs> 212467712 bytes (212 MB) copied, 9.95 s, 21.4 MB/s on kvm for me! + <slpz> gnu_srs: which block size? + <gnu_srs> 4k, and 61.7 MB/s with 256k + <slpz> gnu_srs: could you try with 512k and 1M? + <gnu_srs> 512k: 56.0 MB/s, 1024k: 40.2 MB/s Looks like the peak is around a + few 100k + <slpz> gnu_srs: thanks! + <slpz> I've just obtained 1.3GB/s with bs=512k on other (newer) machine + <braunr> on which hw/vm ? + <slpz> I knew this is a cpu-bound test, but I couldn't imagine faster + processors could make this difference + <slpz> braunr: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz + <slpz> braunr: KVM + <braunr> ok + <braunr> how much time did you wait before reading the result ? + <slpz> that was 20x times better than the same test on my Intel(R) + Core(TM)2 Duo CPU T7500 @ 2.20GHz + <slpz> braunr: I've repeated the test with a fixed "count" + <gnu_srs> My box is: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz: Max + is 67 MB/s around 140k block size + <braunr> yes but how much time did dd run ? + <gnu_srs> 10 s plus/minus a few fractions of a second, + <braunr> try waiting 30s + <slpz> braunr: didn't check, let me try again + <braunr> my kvm peaks at 130 MiB/s with bs 512k / 1M + <gnu_srs> 2029690880 bytes (2.0 GB) copied, 30.02 s, 67.6 MB/s, bs=140k + <braunr> gnu_srs: i'm very surprised with slpz's result of 1.3 GiB/s + <slpz> braunr: over 60 s running, same performance + <braunr> nice + <braunr> i wonder what makes it so fast + <braunr> how much cache ? + <gnu_srs> Me too, I cannot get better values than around 67 MB/s + <braunr> gnu_srs: same questions + <slpz> braunr: 4096KB, same as my laptop + <braunr> slpz: l2 ? l3 ? + <gnu_srs> kvm: cache=writeback, CPU: 4096 KB + <braunr> gnu_srs: this has nothing to do with the qemu option, it's about + the cpu + <slpz> braunr: no idea, it's the first time I touch this machine. I going + to see if I find the model in processorfinder + <braunr> under my host linux system, i get a similar plot, that is, + performance drops beyond bs=1M + <gnu_srs> braunr: OK, bu I gave you the cache size too, same as slpz. + <braunr> i wonder what dd actually does + <braunr> read() and writes i guess + <slpz> braunr: read/write repeatedly, nothing fancy + <braunr> slpz: i don't think it's a good test for virtual copy + <braunr> io_read_request, vm_deallocate, io_write_request, right + <braunr> slpz: i really wonder what it is about i5 that improves speed so + much + <slpz> braunr: me too + <slpz> braunr: L2: 2x256KB, L3: 4MB + <slpz> and something calling "SmartCache" + <gnu_srs> slpz: where did you find these values? + <slpz> gnu_srs: ark.intel.com and wikipedia + <gnu_srs> aha, cpuinfo just gives cache size. + <slpz> that "SmartCache" thing seems to be just L2 cache sharing between + cores. Shouldn't make a different since we're using only one core, and I + don't see KVM hooping between them. + <manuel> with bs=256k: 7004487680 bytes (7.0 GB) copied, 10 s, 700 MB/s + <manuel> (qemu/kvm, 3 * Intel(R) Xeon(R) E5504 2GHz, cache size 4096 KB) + <slpz> manuel: did you try with 512k/1M? + <manuel> bs=512k: 7730626560 bytes (7.7 GB) copied, 10 s, 773 MB/s + <manuel> bs=1M: 7896825856 bytes (7.9 GB) copied, 10 s, 790 MB/s + <slpz> manuel: those are pretty good numbers too + <braunr> xeon processor + <gnu_srs> lshw gave me: L1 Cache 256KiB, L2 cache 4MiB + <slpz> sincerely, I've never seen Hurd running this fast. Just checked + "uname -a" to make sure I didn't take the wrong image :-) + <manuel> for bs=256k, 60s: 40582250496 bytes (41 GB) copied, 60 s, 676 MB/s + <braunr> slpz: i think you can assume processor differences alter raw + copies too much to get any valuable results about virtual copy operations + <braunr> you need a specialized test program + <manuel> and bs=512k, 60s, 753 MB/s + <slpz> braunr: I'm using the mach_perf suite from OSFMach to do the + "serious" testing. I just wanted a non-synthetic test to confirm the + readings. + +[[!taglink open_issue_gnumach]] -- have a look at *mach_perf*. + + <braunr> manuel: how much cache ? 2M ? + <braunr> slpz: ok + <braunr> manuel: hmno, more i guess + <manuel> braunr: /proc/cpuinfo says cache size : 4096 KB + <braunr> ok + <braunr> manuel: performance should drop beyond bs=2M + <braunr> but that's not relevant anyway + <gnu_srs> Linux: bs=1M, 10.8 GB/s + <slpz> I think this difference is too big to be only due to a bigger amount + of CPU cycles... + <braunr> slpz: clearly + <slpz> gnu_srs: your host system has 64 or 32 bits? + <slpz> braunr: I'm going to investigate a bit + <slpz> but this accidental discovery just made my day. We're able to run + Hurd at decent speeds on newer hardware! + <braunr> slpz: what result do you get with the same test on your host + system ? + <manuel> interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + +[[Degradataion]]. + + <slpz> braunr: probably an almost infinite throughput, but I don't consider + that a valid test, since in Linux, the write operation to "/dev/null" + doesn't involve memory copying/moving + <braunr> manuel: i observed the same behaviour + <gnu_srs> slpz: Host system is 64 bit + <braunr> slpz: it doesn't on the hurd either + <braunr> slpz: (under 2k, that is) + <braunr> over* + <slpz> braunr: humm, you're right, as the null translator doesn't "touch" + the memory, CoW rules apply + <braunr> slpz: the only thing which actually copies things around is dd + <braunr> probably by simply calling read() + <braunr> which gets its result from a VM copy operation, but copies the + content to the caller provided buffer + <braunr> then vm_deallocate() the data from the storeio (zero) translator + <braunr> if storeio isn't too dumb, it doesn't even touch the transfered + buffer (as anonymous vm_map()ped memory is already cleared) + +[[!taglink open_issue_documentation]] + + <braunr> so this is a good test for measuring (profiling?) our ipc overhead + <braunr> and possibly the vm mapping operations (which could partly explain + why the results get worse over time) + <braunr> manuel: can you run vminfo | wc -l on your gnumach process ? + <slpz> braunr: Yes, unless some special situation apply, like the source + address/offset being unaligned, or if the translator decides to return + the result in a different buffer (which I assume is not the case for + storeio/zero) + <manuel> braunr: 35 + <braunr> slpz: they can't be unaligned, the vm code asserts that + <braunr> manuel: ok, this is normal + <slpz> braunr: address/offset from read() + <braunr> slpz: the caller provided buffer you mean ? + <slpz> braunr: yes, and the offset of the memory_object, if it's a pager + based translator + <braunr> slpz: highly unlikely, the compiler chooses appropriate alignments + for such buffers + <slpz> braunr: in those cases, memcpy is used over vm_copy + <braunr> slpz: and the glibc memcpy() optimized versions can usually deal + with that + <braunr> slpz: i don't get your point about memory objects + <braunr> slpz: requests on memory objects always have aligned values too + <slpz> braunr: sure, but can't deal with the user requesting non + page-aligned sizes + <braunr> slpz: we're considering our dd tests, for which we made sure sizes + were page aligned + <slpz> braunr: oh, I was talking in a general sense, not just in this dd + tests, sorry + <slpz> by the way, dd on the host tops at 12 GB/s with bs=2M + <braunr> that's consistent with our other results + <braunr> slpz: you mean, even on your i5 processor with 1.3 GiB/s on your + hurd kvm ? + <slpz> braunr: yes, on the GNU/Linux which is running as host + <braunr> slpz: well that's not consistent + <slpz> braunr: consistent with what? + <braunr> slpz: i get roughly the same result on my host, but ten times less + on my hurd kvm + <braunr> slpz: what's your kernel/kvm versions ? + <slpz> 2.6.32-5-amd64 (debian's build) 0.12.5 + <braunr> same here + <braunr> i'm a bit clueless + <braunr> why do i only get 130 MiB/s where you get 1.3 .. ? :) + <slpz> well, on my laptop, where Hurd on KVM tops on 50 MB/s, Linux gets a + bit more than 10 GB/s + <braunr> see + <braunr> slpz: reduce bs to 256k and test again if you have time please + <slpz> braunr: on which system? + <braunr> slpz: the fast one + <braunr> (linux host) + <slpz> braunr: Hurd? + <slpz> ok + <slpz> 12 GB/s + <braunr> i get 13.3 + <slpz> same for 128k, only at 64k starts dropping + <slpz> maybe, on linux we're being limited by memory speed, while on Hurd's + this test is (much) more CPU-bound? + <braunr> slpz: maybe + <braunr> too bad processor stalls aren't easy to measure + <slpz> braunr: that's very true. It's funny when you read a paper which + measures performance by cycles on an old RISC processor. That's almost + impossible to do (with reliability) nowadays :-/ + <slpz> I wonder which throughput can achieve Hurd running bare-metal on + this machine... + <antrik> both the Xeon and the i5 use cores based on the Nehalem + architecture + <antrik> apparently Nehalem is where Intel first introduces nested page + tables + <antrik> which pretty much explains the considerably lower overhead of VM + magic + <cjuner> antrik, what are nested page tables? (sounds like the 4-level page + tables we already have on amd64, or 2-level or 3-level on x86 pae) + <antrik> page tables were always 2-level on x86 + <antrik> that's unrelated + <antrik> nested page tables means there is another layer of address + translation, so the VMM can do it's own translation and doesn't care what + the guest system does => no longer has to intercept all page table + manipulations + <braunr> antrik: do you imply it only applies to virtualized systems ? + <antrik> braunr: yes + <slpz> antrik: Good guess. Looks like Intel's EPT are doing the trick by + allowing the guest OS deal with its own page faults + <slpz> antrik: next monday, I'll try disabling EPT support in KVM on that + machine (the fast one). That should confirm your theory empirically. + <slpz> this also means that there're too many page faults, as we should be + doing virtual copies of memory that is not being accessed + <slpz> and looking at how the value of "page faults" in "vmstat" increases, + shows that page faults are directly proportional to the number of pages + we are asking from the translator + <slpz> I've also tried doing a long read() directly, to be sure that "dd" + is not doing something weird, and it shows the same behaviour. + <braunr> slpz: dd does copy buffers + <braunr> slpz: i told you, it's not a good test case for pure virtual copy + evaluation + <braunr> antrik: do you know if xen benefits from nested page tables ? + <antrik> no idea + +[[!taglink open_issue_xen]] + + <slpz> braunr: but my small program doesn't, and still provokes a lot of + page faults + <braunr> slpz: are you certain it doesn't ? + <slpz> braunr: looking at google, it looks like recent Xen > 3.4 supports + EPT + <braunr> ok + <braunr> i'm ordering my new server right now, core i5 :) + <slpz> braunr: at least not explicitily. I need to look at MiG stubs again, + I don't remember if they do something weird. + <antrik> braunr: sandybridge or nehalem? :-) + <braunr> antrik: no idea + <antrik> does it tell a model number? + <braunr> not yet + <braunr> but i don't have a choice for that, so i'll order it first, check + after + <antrik> hehe + <antrik> I'm not sure it makes all that much difference anyways for a + server... unless you are running it at 100% load ;-) + <braunr> antrik: i'm planning on running xen guests suchs as new buildd + <antrik> hm... note though that some of the nehalem-generation i5s were + dual-core, while all the new ones are quad + <braunr> it's a quad + <antrik> the newer generation has better performance per GHz and per + Watt... but considering that we are rather I/O-limited in most cases, it + probably won't make much difference + <antrik> not sure whether there are further virtualisation improvements + that could be relevant... + <braunr> buildds spend much time running gcc, so even such improvements + should help + <braunr> there, server ordered :) + <braunr> antrik: model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz + +IRC, freenode, #hurd, 2011-09-06: + + <slpz> youpi: what machines are being used for buildd? Do you know if they + have EPT/RVI? + <youpi> we use PV Xen there + <slpz> I think Xen could also take advantage of those technologies. Not + sure if only in HVM or with PV too. + <youpi> only in HVM + <youpi> in PV it does not make sense: the guest already provides the + translated page table + <youpi> which is just faster than anything else + +IRC, freenode, #hurd, 2011-09-09: + + <antrik> oh BTW, for another data point: dd zero->null gets around 225 MB/s + on my lowly 1 GHz Pentium3, with a blocksize of 32k + <antrik> (but only half of that with 256k blocksize, and even less with 1M) + <antrik> the system has been up for a while... don't know whether it's + faster on a freshly booted one + +IRC, freenode, #hurd, 2011-09-15: + + <sudoman> + http://www.reddit.com/r/gnu/comments/k68mb/how_intelamd_inadvertently_fixed_gnu_hurd/ + <sudoman> so is the dd command pointed to by that article a measure of io + performance? + <antrik> sudoman: no, not really + <antrik> it's basically the baseline of what is possible -- but the actual + slowness we experience is more due to very unoptimal disk access patterns + <antrik> though using KVM with writeback caching does actually help with + that... + <antrik> also note that the title of this post really makes no + sense... nested page tables should provide similar improvements for *any* + guest system doing VM manipulation -- it's not Hurd-specific at all + <sudoman> ok, that makes sense. thanks :) + +IRC, freenode, #hurd, 2011-09-16: + + <slpz> antrik: I wrote that article (the one about How AMD/Intel fixed...) + <slpz> antrik: It's obviously a bit of an exaggeration, but it's true that + nested pages supposes a great improvement in the performance of Hurd + running on virtual machines + <slpz> antrik: and it's Hurd specific, as this system is more affected by + the cost of page faults + <slpz> antrik: and as the impact of virtualization on the performance is + much higher than (almost) any other OS. + <slpz> antrik: also, dd from /dev/zero to /dev/null it's a measure on how + fast OOL IPC is. diff --git a/open_issues/performance/microbenchmarks.mdwn b/open_issues/performance/microbenchmarks.mdwn new file mode 100644 index 00000000..de3a54b7 --- /dev/null +++ b/open_issues/performance/microbenchmarks.mdwn @@ -0,0 +1,13 @@ +[[!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]]."]]"""]] + +Microbenchmarks may give useful hints, or they may not. + +<http://www.ibm.com/developerworks/java/library/j-jtp02225.html> diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..111d2b88 --- /dev/null +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -0,0 +1,47 @@ +[[!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]] + +Performance issues due to the microkernel/multi-server system architecture? + +IRC, freenode, #hurd, 2011-07-26 + + < CTKArcher> I read that, because of its microkernel+servers design, the + hurd was slower than a monolithic kernel, is that confirmed ? + < youpi> the hurd is currently slower than current monolithic kernels, but + it's not due to the microkernel + servers design + < youpi> the microkernel+servers design makes the system call path longer + < youpi> but you're bound by disk and network speed + < youpi> so the extra overhead will not hurt so much + < youpi> except dumb applications keeping doing system calls all the time + of course, but they are usually considered bogus + < braunr> there may be some patterns (like applications using pipes + extensively, e.g. git-svn) which may suffer from the design, but still in + an acceptable range + < CTKArcher> so, you are saying that disk and network are more slowing the + system than the longer system call path and because of that, it wont + really matter ? + < youpi> braunr: they should sitll be fixed because they'll suffer (even if + less) on monolithic kernels + < youpi> CTKArcher: yes + < braunr> yes + < CTKArcher> mmh + < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 + iirc, about minix + < youpi> they even go as far as using an IPC for each low-level in/out + < youpi> for security + < braunr> this has been expected for a long time + < braunr> which is what motivated research in microkernels + < CTKArcher> I've already downloaded the video :) + < youpi> and it has been more and more true with faster and faster cpus + < braunr> but in 95, processors weren't that fast compared to other + components as they are now + < youpi> while disk/mem haven't evovled so fast diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn new file mode 100644 index 00000000..48343e3e --- /dev/null +++ b/open_issues/perl.mdwn @@ -0,0 +1,101 @@ +[[!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="Foster Perl programming"]] + +[[!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: + + # apt-get install perl perl-base -o APT::Immediate-Configure=false + +"""]] + + +Resolve issues uncovered by Perl's test suite, and enable Hurd-specific +features. + +There is a [[!FF_project 264]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + + +## IRC, OFTC, #debian-hurd, 2011-11-08 + + <Dom> pinotree: so, with your three fixes applied to 5.14.2, there are + still 9 tests failing. They don't seem to be regressions in perl, since + they also fail when I build 5.14.0 (even though the buildd managed it). + <Dom> What do you suggest as the way forward? + <Dom> (incidentally I'm trying on strauss's sid chroot to see how that + compares) + <pinotree> Dom: samuel makes buildds build perl with nocheck (otherwise + we'd have no perl at all) + <pinotree> which tests still fail? + <Dom> ../cpan/Sys-Syslog/t/syslog.t ../cpan/Time-HiRes/t/HiRes.t + ../cpan/autodie/t/recv.t ../dist/IO/t/io_pipe.t ../dist/threads/t/libc.t + ../dist/threads/t/stack.t ../ext/Socket/t/socketpair.t io/pipe.t + op/sigdispatch.t + <Dom> buildds> I see + <pinotree> ah ok, those that are failing for me even with my patches + <Dom> I hadn't spotted that the builds were done with nocheck. + <Dom> (but only sometimes...) + <Dom> Explains a lot + <pinotree> syslog is kind of non-working on hurd, and syslog.t succeeds in + buildds (as opposted to crash the machine...) because there's no /var/log + in chroots + <pinotree> libc.t appears to succeed too in buildds + * Dom notices how little memory strauss has, and cancels the build, now + that he *knows* that running out of memory caused the crahses + <pinotree> iirc HiRes.t, io_pipe.t , pipe.t and sigdispatch.t fails because + of trobules we have with posix signals + <pinotree> socketpair.t is kind of curious, it seems to block on + socketpair()... + * Dom wonders if a wiki page tracking this would be worthwhile + <pinotree> stack.t fails because we cannot set a different size for pthread + stacks, yet (similar failing test cases are also in the python test + suite) + <Dom> if there are problems which aren't going to get resolved any time + soon, it may be worth a few SKIPs conditional on architecture, depending + on how serious the issue is + <Dom> then we'd get better visibility of other/new issues + <Dom> (problems which aren't bugs in perl, that is) + <pinotree> understandable, yes + <pinotree> i think nobody digged much deeper in the failing ones yet, to + actually classify them as due to glibc/hurd/mach + <pinotree> (eg unlike the pipe behaviour in sysconf.t i reported) + +### 2011-11-26 + + <pinotree> cool, my recvfrom() fix also makes the perl test recv.t pass + + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Perl. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/perlmagick.mdwn b/open_issues/perlmagick.mdwn new file mode 100644 index 00000000..8a57a8fd --- /dev/null +++ b/open_issues/perlmagick.mdwn @@ -0,0 +1,107 @@ +[[!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 +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]]."]]"""]] + +[[!debbug 557771]] + +# Bisecting + + * Good + + * 7:6.4.0.9.dfsg1-1 (2008-04-22) built from + <http://snapshot.debian.net/package/imagemagick> + * 6.4.0-11 + * 6.4.1-0 + * 6.4.1-1 + + * Bad + + * 6.4.1-2 + * 6.4.1-5 + * 6.4.1-10 + * 6.4.2-10 + * 6.4.5-9 + * 6.4.8-0 / Debian 6.4.8.0-1 + * 6.5.5-3 / Debian 6.5.5.3-1 + * 6.5.8.3-1 from Debian unstable (also in testing) + * Svn trunk (r848) + + +# 6.4.1-1 -> 6.4.1-2 + + -CFLAGS = -g -O2 -Wall -W -pthread + +CFLAGS = -fopenmp -g -O2 -Wall -W -pthread + -GOMP_LIBS = + +GOMP_LIBS = -lgomp + -LDFLAGS = -lfreetype -lz + +LDFLAGS = -fopenmp -lfreetype -lz + +Etc. + + +/usr/include/pthread.h: + + + +/usr/include/pthread/pthread.h: + + + +/usr/include/bits/spin-lock-inline.h: + + + +/usr/include/bits/cancelation.h: + + + +/usr/include/bits/pthread-np.h: + + + +/usr/lib/gcc/i486-gnu/4.4.2/include/omp.h: + + +# State as of 2011-03-06 + +freenode, #hurd channel, 2011-03-06: + + <pinotree> tschwinge: (speaking on working perl, how did it en with that + "(glibc) double free" crash with perl?) + <pinotree> *end + <tschwinge> I think I remember I suspected it's a libgomp (!) issue in the + end. I have not yet continued working on that. + <pinotree> libogmp? looks like you know more than me, then :) + <youpi> tschwinge: oh, I'm interested + <youpi> I know a bit about libgomp :) + <tschwinge> I bisected this down to where Imagemagick added -fgomp (or + whatever it is). And then the perl library (Imagemagick.pm?) which loads + the imagemagick.so segfaulted. + <tschwinge> ImageMagick did this change in the middle of a x.x.x.something + release.. + <tschwinge> My next step would have been to test whether libgomp works at + all for us. + <youpi> ./usr/sbin/debootstrap:DEBOOTSTRAP_CHECKSUM_FIELD="SHA$SHA_SIZE" + <youpi> erf + <youpi> so they switched to another checksum + <youpi> but we don't have that one on all of our packages :) + <youpi> tschwinge: + <youpi> buildd@bach:~$ OMP_NUM_THREADS=2 ./test + <youpi> I'm 0x1 + <youpi> I'm 0x3 + <youpi> libgomp works at least a bit + <tschwinge> OK. + <pinotree> i guess we should hope the working bits don't stop at that point + ;) + <tschwinge> If open_issues/perlmagick is to be believed a diff of 6.4.1-1 + and 6.4.1-2 should tell what exactly was changed. + <tschwinge> Oh! + <tschwinge> I even have it on the page already! ;-) + <tschwinge> -fopenmp + <youpi> I've tried the pragmas that imagemagick uses + <youpi> they work + <tschwinge> Might be the issue fixed itself? + <youpi> I don't know, it's the latest libc here + <youpi> (and latest hurd, to be uploaded) + + +# Other + +[[!debbug 551017]] + +Code in Svn: `+ 1` missing to account for both `/` and `\0`. diff --git a/open_issues/pfinet.mdwn b/open_issues/pfinet.mdwn new file mode 100644 index 00000000..7aadd736 --- /dev/null +++ b/open_issues/pfinet.mdwn @@ -0,0 +1,27 @@ +[[!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]] + +In certain situations, pfinet spawns more and more threads, +apparently without any bounds. + +The thread creation happens in bursts rather than continuously. +According to a backtrace in GDB, +all the threads are functional and waiting for client requests. +(The bursts are getting smaller as the number of threads rises, +but probably only because the enormous number of existing threads +slows down processing in general.) + +This can be triggered quite reliably by X clients running on the Hurd system, +connected to an X server on another machine over TCP, +and transferring fairly large amounts of data. +The easiest way to reproduce it I found is launching freeciv-gtk2, +pressing the "new game" button, and then simply waiting for a while. diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn new file mode 100644 index 00000000..09b00d30 --- /dev/null +++ b/open_issues/pfinet_vs_system_time_changes.mdwn @@ -0,0 +1,101 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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 + + <grey_gandalf> I did a sudo date... + <grey_gandalf> and the machine hangs + +This was very likely a misdiagnosis. + + +# 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? + <antrik> tschwinge: BTW, pfinet doesn't actually die I think -- it just + drops open connections... + <antrik> perhaps it thinks they timed out + <tschwinge> antrik: Isn't the translator restarted instead? + <antrik> don't think so + <antrik> when pfinet actually dies, I also loose the NFS mounts, which + doesn't happen in this case + <antrik> hehe "... and the machine hangs" + <antrik> he didn't bother to check that the machine is perfectly fine, only + the SSH connection got dropped + <tschwinge> Ah, I see. So it'S perhaps indeed simply closes TCP + connections that have been without data for ``too long''? + <antrik> yeah, that's my guess + <antrik> my clock is speeding, so ntpdate sets it in the past + <antrik> perhaps there is some math that concludes the connection have been + inactive for -200 seconds, which (unsigned) is more than any timeout :-) + <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 + + +# IRC, freenode, #hurd, 2012-06-28 + + <bddebian> great, now setting the date/time fucked my machine + <pinotree> yes, we lack a monotonic clock + <pinotree> there are select() loops that use gettimeofday to determine how + much time to wait + <pinotree> thus if the time changes (eg goes back), the calculation goes + crazy + <antrik> pinotree: didn't you implement a monotonic clock?... + <pinotree> started to + <antrik> bddebian: did it really fuck the machine? normally it only resets + TCP connections... + <pinotree> yeah, i remember such gettimeofay-based select-loops at least in + pfinet + <antrik> I don't think it's a loop. it just drops the connections, + believing they have timed out + <bddebian> antrik: Well in this case I don't know because I am at work but + it fucked me because I now cannot get to it.. :) + <antrik> bddebian: that's odd... you should be able to just log in again + IIRC + + +# IRC, freenode, #hurd, 2012-07-29 + + <antrik> pfinet can't cope with larger system time changes because it can't + use a monotonic clock + +[[clock_gettime]]. + + <braunr> well when librt becomes easily usable everywhere (it it's + possible), it will be quite easy to work around this issue + <pinotree> yes and no, you just need a monotonic clock and clock_gettime + able to use it + <braunr> why "no" ? diff --git a/open_issues/pflocal_reauth.mdwn b/open_issues/pflocal_reauth.mdwn new file mode 100644 index 00000000..839e383d --- /dev/null +++ b/open_issues/pflocal_reauth.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_glibc open_issue_hurd]] + +IRC, freenode, #hurd, 2011-04-02 + + <pinotree> youpi: i'm playing with pflocal, and noticing that a simple C + executable doesn't trigger reauthenticate + <pinotree> youpi: i've put a debug output (to file) in S_io_reauthenticate, + and with a simple C test (which uses unix sockets) it isn't called + <youpi> pinotree: it seems pflocal should return FS_RETRY_REAUTH in + retry_type + <youpi> to make glibc call reauthentication + <pinotree> pflocal? + <youpi> yes, in the dir_lookup handler + <pinotree> isn't that ext2fs? + <youpi> libtrivfs had dir_lookup() too + <youpi> trivfs_check_open_hook can be used to tweak its behavior + <pinotree> ah, missed that pflocal was using libtrivfs, sorry + <youpi> there are probably very few translators which don't use one of the + lib*fs :) + <antrik> pinotree: what are you trying to do with pflocal? + <pinotree> local socket scredentials (SCM_CREDS) + <antrik> ah + <antrik> don't really know what that is, but I remember reading some + mention of it ;-) + +--- + +See also [[pflocal_socket_credentials_for_local_sockets]] and +[[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn new file mode 100644 index 00000000..dfdc213c --- /dev/null +++ b/open_issues/pflocal_socket_credentials_for_local_sockets.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]]."]]"""]] + +IRC, freenode, #hurd, 2011-03-28 + +[[!tag open_issue_hurd]] + + <pinotree> basically, i'm trying to implement socket credentials for local + sockets, and i guessed doing it in pflocal would be the appropriate place + <pinotree> what i thought was filling the cmsg data for MSG_CRED at + S_socket_recv() call + <pinotree> in case i missed it, would there be a way to "identify" the + other side of the port associated to the sock_user of that call? + <pochu> pinotree: that's needed by dbus right? cool! (and I don't know) + <pinotree> (yes, and gamin) + <youpi> pinotree: you have them already, they're just not stored + <youpi> see S_io_reauthenticate + <youpi> Throw away the ids we went through all that trouble to get... + <youpi> (comment) + * pinotree looks + <pinotree> hm, and who calls that rpc? + <youpi> everybody + <youpi> since that's how ext2fs knows the permission to apply, for instance + <pinotree> ah, i was referring to the reauthenticate of pflocal, not + auth_server_authenticate() + <youpi> that's what I'm saying + <youpi> see __hurd_file_name_lookup_retry, which is the very internal part + of open() + <youpi> it calls io_reauthenticate() + <youpi> to authenticate itself to the underlying translator of the opened + node + <pinotree> youpi: so, hm, could be an option make the result of pflocal's + S_io_reauthenticate cached in the sock_user struct? + <youpi> yes + <pinotree> nice thanks, i will try that change first + +--- + +See also [[pflocal_reauth]] and [[sendmsg_scm_creds]]. diff --git a/open_issues/pflocal_x_slowness.mdwn b/open_issues/pflocal_x_slowness.mdwn new file mode 100644 index 00000000..9bc18128 --- /dev/null +++ b/open_issues/pflocal_x_slowness.mdwn @@ -0,0 +1,16 @@ +[[!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, #hurd, 2010-08-10 + + <antrik> m1k11e: I think the X slowness is a problem in pflocal, i.e. the translator handling UNIX domain sockets + <antrik> (X clients communicate with a local X server using domain sockets) diff --git a/open_issues/phython.mdwn b/open_issues/phython.mdwn new file mode 100644 index 00000000..62f70be0 --- /dev/null +++ b/open_issues/phython.mdwn @@ -0,0 +1,13 @@ +[[!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]]."]]"""]] + +Go through James Morrison's (phython) pages, <http://hurd.dyndns.org/>, (via +Intrernet Archive Wayback Machine), and archive / hunt down what's still +interesting. diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn new file mode 100644 index 00000000..39478f20 --- /dev/null +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -0,0 +1,103 @@ +[[!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-07-13 + + <braunr> does anyone know if posix (or mach) has requirements or a policy + about the placement of allocations of virtual space ? + <braunr> a policy such as bottom-up ? + <braunr> or "find lowest vailable space" ? + <jkoenig> braunr, you mean for vm_allocate ? You may want to check mmap() + but I can't remember ever coming across such a thing (except maybe + wrt. alignment) + <braunr> i was wondering how e.g. libraries are linked near the stack + (possibly at slightly random addresses) + <braunr> does the linker walk the address space entries top-down ? + <braunr> jkoenig: i didn't see anything either in the mach interface, but i + may have missed something + <braunr> jkoenig: most systems i've been studying mark the vm regions for + the heap and the stack + <braunr> but for mach, the stack is just allocated virtual memory at the + top of the space + <braunr> so the "placement policy" is either completely outside the kernel, + or relies on its interface + <jkoenig> braunr, actually I'm surprised Mach would even dictate where the + (one?) stack should be, I would have expected it to be the job of + whatever creates a thread to make this kind of choice + <braunr> jkoenig: threads have their own stacks, under the responsibility + of the user trhead implementation + <braunr> but a program usually needs a stack even before it runs + <braunr> i had to set one to bootstrap modules in v0.1 + <braunr> but i wonder if it's just for bootstrapping (and then propagated + by fork()) or part of the interface + <braunr> but this doesn't matter much actually, the allocation mechanism i + have in mind can actually support multiple policies + <jkoenig> I would guess the former (just for bootstrapping), since a new + task has no thread, and a new thread has no state. (but I'm no expert) + <braunr> i think so + <braunr> i'll have a look at the exec server + <braunr> jkoenig: did the previous implementation of procfs show task maps + ? + <jkoenig> braunr, I don't think so, I would probably have felt compelled to + include them in the new one if it did :-) + <braunr> hmmm + <braunr> we definitely need that + <jkoenig> is there a compelling use case you think about in particular? + <braunr> yes + <braunr> i failed to understand how gnumach behaved wrt ipc right spaces + +[[rework_gnumach_ipc_spaces]] + + <braunr> and when i did, i found out my work was impossible to integrate + <jkoenig> "ipc right spaces" ? + <braunr> each task have an ipc space, which contains righs + <braunr> rights + <braunr> the ipc translation layer converts space/name and space/port + tuples to rights + <braunr> i wanted to replace the splay tree with a radix tree but didn't + get how the ipc table made the splay tree almost unused + <braunr> i don't want to make this kind of mistake again, so i'd like a + clear and detailed view of the vm spaces + <braunr> (it's only compelling for myself, all right) + <braunr> but + <braunr> we have vminfo + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1046 + <braunr> oh my + <braunr> in comparison, a firefox instance has less than 500 on linux + <jkoenig> you mean there's some kind of port name table (or functional + equivalent) which actually resides in the task's memory? (and that's what + shows up at the beginning of the address space with prot=0?) + <braunr> jkoenig: sorry for being confusing, it's not that at all + <jkoenig> (btw feel free to tell me to just go read the source or whatever) + <braunr> jkoenig: don't worry + <jkoenig> braunr, no problem + <braunr> jkoenig: i just compared a previous attempt to improve gnumach + which failed because i didn't have enough insight of the inner workings + of the kernel + <braunr> jkoenig: i really want to miss as little as possible on the vm + part, so having detailed information about what actually happens on + running hurd systems is something i need + + +# IRC, freenode, #hurd, 2011-07-24 + + <braunr> oh btw, i noticed there are many mappings below the program text + <braunr> most notably, the stack + <braunr> except for special applications like wine, could this break + anything ? + <braunr> i also wonder how libraries are mapped, because there is nothing + to perform top-down allocations + <braunr> which means if the region below the program text is exhausted, + libraries could be mapped right after the heap + <youpi> it shouldn't break anything except things like wine & libgc, yes + <braunr> which could make malloc() fail :/ diff --git a/open_issues/populate_hurd_git_with_submodules_etc.mdwn b/open_issues/populate_hurd_git_with_submodules_etc.mdwn new file mode 100644 index 00000000..c89b95e9 --- /dev/null +++ b/open_issues/populate_hurd_git_with_submodules_etc.mdwn @@ -0,0 +1,16 @@ +[[!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="populate hurd.git with submodules, etc."]] + +Populate the top-level *[Savannah]/hurd.git* with a bunch of submodules +(various translators; everything that's intersting), have it serve as sort of a +tested distribution (because the submodules are versioned), plus adding build +machinery / cross-compilation support, etc. diff --git a/open_issues/posix_fadv_volatile.mdwn b/open_issues/posix_fadv_volatile.mdwn new file mode 100644 index 00000000..6bd25e3e --- /dev/null +++ b/open_issues/posix_fadv_volatile.mdwn @@ -0,0 +1,16 @@ +[[!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="POSIX_FADV_VOLATILE"]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +May be interesting to watch what happens: LWN, Jonathan Corbet, +[`POSIX_FADV_VOLATILE`](http://lwn.net/Articles/468896/), 2011-11-22. diff --git a/open_issues/prelink.mdwn b/open_issues/prelink.mdwn new file mode 100644 index 00000000..ad85b9e2 --- /dev/null +++ b/open_issues/prelink.mdwn @@ -0,0 +1,27 @@ +[[!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_porting]] + +The *prelink* package, as distributed via Debian unstable, does build on +GNU/Hurd. After installing the satisfiable dependencies, use +`dpkg-buildpackage -b -uc -d` to ignore SELinux and libc6-dev dependencies. + +It is unclear whether it also does work. The testsuite (run manually) does +*FAIL* on all tests, which is due to the prelinker doing something to the +copied `ld.so.1` so that it faults on every invocation. This does not happen +on GNU/Linux. + +Not much in the prelinker is Linux-specific. `src/get.c`'s `is_ldso_soname` +should already cover our `ld.so.1` case (and what about `ld.so`?). At the end +of `src/arch-i386.c`, `.dynamic_linker` has to be set properly. And, in that +file there are some Linux process VM constants, of which `REG2S` and `REG2E` +are the only relevant in the `!exec_shield` case. Probably these need to be +adjusted. What else? diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn new file mode 100644 index 00000000..1d0e92a3 --- /dev/null +++ b/open_issues/proc_server_proc_exception_raise.mdwn @@ -0,0 +1,37 @@ +[[!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-08-11 + + < youpi> in which error cases a reply port will actually have been consumed + by mach_msg ? + < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do? + < braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send + < braunr> "These return codes imply that the message was returned to the + caller with a pseudo-receive operation: " + < braunr> isn't it what you're looking for ? + < youpi> well, it's hard to tell from the name + < youpi> I don't know what "pseudo-receiv operation" means + < braunr> it's described below + < youpi> ew + < braunr> it looks close enough to a normal receive to assume it consumes + the reply port + < youpi> so it's even more complex than what I thought + < youpi> well, no, it returns the right + < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME + < youpi> which I guess means the sending part succeeded + < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise() + < youpi> when the proc_exception_raise() forward fails + < youpi> currently we always return 0, but if proc_exception_raise() + actually managed to send the message, the reply port was consumed and + MIG_NO_REPLY should be returned instead diff --git a/open_issues/profiling.mdwn b/open_issues/profiling.mdwn new file mode 100644 index 00000000..7e3c7350 --- /dev/null +++ b/open_issues/profiling.mdwn @@ -0,0 +1,28 @@ +[[!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 +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]]."]]"""]] + +*Profiling* ([[!wikipedia Profiling_(computer_programming) desc="Wikipedia +article"]]) is a tool for tracing where CPU time is spent. This is usually +done for [[performance analysis|performance]] reasons. + + * [[gprof]] + + Should be working, but some issues have been reported, regarding GCC spec + files. Should be possible to fix (if not yet done) easily. + + * [[community/gsoc/project_ideas/dtrace]] + + Have a look at this, integrate it into the main trees. + + * [[LTTng]] + + * [[SystemTap]] + + * ... or some other Linux thing. diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn index bf9c70d7..12bf5098 100644 --- a/open_issues/pth.mdwn +++ b/open_issues/pth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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 @@ -10,8 +11,18 @@ is included in the section entitled [[!tag open_issue_porting]] +IRC, unknown channel, unknown date. + <azeem> seems pth still doesn't work <bddebian> Doesn't build or doesn't work? <azeem> both <azeem> some configure test keep grinding the CPU, same for the test suite <azeem> which apparently runs pth_init() and never returns + + <azeem> actually, pth fails to build right now + <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union + + <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed + <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... + + <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn new file mode 100644 index 00000000..ac724cf0 --- /dev/null +++ b/open_issues/pthread_atfork.mdwn @@ -0,0 +1,13 @@ +[[!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]] + +pthread_atfork is not actually implemented, making some programs fail. Code can probably be borrowed from nptl/sysdeps/unix/sysv/linux/register-atfork.c diff --git a/open_issues/python.mdwn b/open_issues/python.mdwn new file mode 100644 index 00000000..403ff8aa --- /dev/null +++ b/open_issues/python.mdwn @@ -0,0 +1,47 @@ +[[!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="Foster Python programming"]] + +Resolve issues uncovered by Python's test suite, and enable Hurd-specific +features. + +There is a [[!FF_project 260]][[!tag bounty]] on this task. + +--- + + +# Part I + +First, make the language functional, have its test suite pass without errors. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/perl_python feeds=no]] + + +## Analysis + + * [[select_bogus_fd]] + +--- + + +# Part II + +Next, Hurd-specific features can be added. Add an interface to the +language/environment for being able to do [[RPC]] calls, in order to program +[[hurd/translator]]s natively in Python. + + +## Original [[community/GSoC]] Task Description + +[[!inline pages=community/gsoc/project_ideas/language_bindings feeds=no]] diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index 57c6bdbf..8f752d61 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_gnumach open_issue_hurd open_issue_viengoos]] @@ -19,3 +20,67 @@ discardable, for example. These issues are what Neal Walfield is working on with his new kernel [[microkernel/viengoos]]. + + +# Kernel + +Inside the [[kernel]], there is commonly a need to allocate resources according +to externally induced demand, dynamically. For example, for memory-management +data structures (page tables), process table entries, thread control blocks, +[[capability]] tables, incoming network packages, blocks that are read in from +disk, the keyboard type-ahead buffer for a in-kernel keyboard driver. Some of +these are due to actions driven by user-space requests, others are due to +actions internal to the the kernel itself. Some of these buffers can be sized +statically (keyboard type-ahead buffer), and are thus unproblematic. Others +are not, and should thus be attributed to their user space entities. In the +latter (ideal) case, all resources -- that is, including those needed inside +the kernel -- that a user space task needs for execution are provided by itself +(and, in turn, provided by its parent / principal), and the kernel itself does +not need to allocate any resources dynamically out of an its own memory pool. +This avoids issues like [[microkernel/Mach]]'s [[zalloc_panics]] upon user +space processes allocating too many [[microkernel/mach/port]]s, for example. + +[[!toggleable id=fof_plos09 text="""[[!template id=note +text="*[[fof\_plos09|microkernel/barrelfish]]*: +{{$microkernel/barrelfish#fof_plos09}}"]]"""]] + +[[!toggleable id=sel4 text="""[[!template id=note +text="[[*sel4*|microkernel/l4]]: {{$microkernel/l4#sel4}}"]]"""]] + +In [[!toggle id=fof_plos09 text="[fof\_plos09]"]], the authors describe in +section 3 how they model their [[capability]] system according to [[!toggle +id=sel4 text="[sel4]"]] using a *retype* operation that *takes an existing +capability and produces one or more derived capabilities [...] used to create +new kernel-level memory objects (such as page tables or execution contexts) +from capabilities to raw regions of RAM*. + +This is, of course, non-trivial to implement, and also requires changing the +[[RPC]] interfaces, for example, but it is a valid approach, a research topic. + +([[!taglink open_issue_documentation]]: compare this to Linux [`vmsplice`'s +SPLICE_F_GIFT +flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) + +IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + + +# Further Examples + + * [[hurd/critique]] + + * [[IO_accounting]] + + * [[translators_set_up_by_untrusted_users]], and [[pagers]] + + * [[configure max command line length]] diff --git a/open_issues/grub2.mdwn b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn index 235950a4..6c0a0d99 100644 --- a/open_issues/grub2.mdwn +++ b/open_issues/resource_management_problems/configure_max_command_line_length.mdwn @@ -5,17 +5,13 @@ 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="GRUB2"]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] -Just like [[GRUB (legacy)|grub_legacy]], GRUB2 needs to be ported for being -installable when attempted to be installed *from* GNU/Hurd systems: - - $ sudo grub-probe --target=device /boot/grub - grub-probe: error: cannot find a device for /boot/grub. - -Etc. + <terpstra> do the buildds also crash? + <youpi> sometimes + <youpi> usually when a configure scripts tries to find out how large a + command line can be + <youpi> (thus eating all memory) diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn new file mode 100644 index 00000000..113b965a --- /dev/null +++ b/open_issues/resource_management_problems/io_accounting.mdwn @@ -0,0 +1,49 @@ +[[!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]]."]]"""]] + +IRC, freenode, #hurd, 2011-07-22 + + <braunr> an interesting question i've had in mind for a few weeks now is + I/O accounting + <braunr> what *is* I/O on a microkernel based system ? + <braunr> can any cross address space transfer be classified as I/O ? + +IRC, freenode, #hurd, 2011-07-29 + + < braunr> how does the hurd account I/O ? + < youpi> I don't think it does + < youpi> not an easy task, actually + < youpi> since gnumach has no idea about it + < braunr> yes + < braunr> another centralization issue + < braunr> does network access count as I/O on linux ? + < youpi> no + < braunr> not even nfs ? + < youpi> else you'd get 100% for servers :) + < braunr> right + < youpi> nfs goes through vfs first + < braunr> i'll rephrase my question + < youpi> I'd need to check but I believe it can check nfs + < braunr> does I/O accounting occur at the vfs level or block layer ? + < youpi> I don't know, but I beleive vfs + < youpi> (at least that's how I'd do it) + < braunr> i don't have any more nfs box to test that :/ + < braunr> personally i'd do it at the block layer :) + < youpi> well, both + < youpi> so e2fsck can show up too + < braunr> yes + < youpi> it's just a matter of ref counting + < youpi> apparently nfs doesn't account + < youpi> find . -printf "" doesn't show up in waitio + < braunr> good + < youpi> well, depends on the point of view + < youpi> as a user, you'd like to know whether your processes are stuck on + i/o (be it disk or net) + < braunr> this implies clearly defining what io is diff --git a/open_issues/resource_management_problems/pagers.mdwn b/open_issues/resource_management_problems/pagers.mdwn new file mode 100644 index 00000000..4c36703c --- /dev/null +++ b/open_issues/resource_management_problems/pagers.mdwn @@ -0,0 +1,322 @@ +[[!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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-09-14 + +Coming from [[translators_set_up_by_untrusted_users]], 2011-09-14 discussion: + + <slpz> antrik: I think a tunable option for preventing non-root users from + creating pagers and attaching translators could also be desirable + <antrik> slpz: why would you want to prevent creating pagers and attaching + translators? + <tschwinge> Preventing resource exhaustion, I guess. + <slpz> antrik: security and (as tschwinge says) for prevent a rouge pager + from exhausting the system. + <slpz> antrik: without the ability to use translators for non-root users, + Hurd can provide (almost) the same level of resource protection than + other *nixes + +See also: [[translators_set_up_by_untrusted_users]], +[[hurd/translator/tmpfs/tmpfs_vs_defpager]]. + + <braunr> the hurd is about that though + <slpz> there should be also a limit on the number of outstanding requests + that a task can have, and some other easily traceable values + <braunr> port messages queues have limits + <antrik> slpz: anything can exhaust the system. there are much more basic + limits that are missing... and I don't see how translators or pagers are + special in that regard + <slpz> braunr: that's what I said tunable. If I don't share my computer + with untrusted users, I want full functionality. Otherwise, I can enable + that limitation + <slpz> braunr: but I think those limits are on reception + <braunr> that's a wrong solution + <slpz> antrik: because pagers are external memory objects, and those are + treated differently + <braunr> compared to what ? + <braunr> and yes, the limit is on the message queue, on reception + <braunr> why is that a problem ? + <slpz> antrik: forbidding the use of translator was for security, to avoid + the problem of traversing an untrusted FS + <slpz> braunr: compared to anonymous memory + <slpz> braunr: because if the limit is on reception, a task can easily do a + DoS against a server + <braunr> hm actually, the problems we have with swap handling is that + anonymous memory is handled in a very similar way as other objects + <slpz> braunr: I want to limit the number of outstanding (unprocessed + messages in queues) requests + <braunr> slpz: the solution isn't about forbidding the use of translators, + but changing common code (libc i guess) not to use them, they can still + run beside + <slpz> braunr: that's because, currently, the external page limit is not + enforced + <braunr> i'm also not sure about DoS attacks + <braunr> if i'm right, there is often one port for each managed object, + which usually exist per client + <slpz> braunr: yes, that could an option too (for translators, not for + pagers) + <braunr> i don't see how pagers wouldn't be translators on the hurd + <slpz> braunr: all pagers are translators, but not all translators are + pagers ;-) + <braunr> so if it works for translators, it also works for pagers + <slpz> braunr: it would fix the security issue, but not the resource + exhaustion problem, with only affects to pagers + <braunr> i just don't see a point in implementing resource limits before + even fixing other fundamental issues + <braunr> the only way to avoid resource exhaustion is resource limits + <antrik> slpz: just not following untrusted translators is much more useful + than forbidding them alltogether + <braunr> and the main problem of mach is resource accounting + <braunr> so first, fix that, using the critique as a starting point + +[[hurd/critique]]. + + <slpz> braunr: i'm not saying that this should be implemented right now, + i'm just pointing out this possibility + <braunr> i think we're all mostly aware of it + <slpz> braunr: resource accounting, as it's expressed in the critique, + would be wonderful, but it's just too complex IMHO + <braunr> it requires carefully designed changes to the interface yes + <slpz> to the interface, to the internals, to user space tasks... + <braunr> the internals wouldn't be impacted that much + <braunr> user space tasks would mostly include hurd servers + <braunr> if the changes are centralized in libraries, it should be easy to + provide to the servers + + +# IRC, freenode, #hurd, 2011-09-22 + + <slpz> antrik: I've also implemented a simple resource control on dirty + pages and changed pageout_scan to free external pages, and only touch + anonymous memory if it's really needed + <slpz> antrik: those combined make the system work better under heavy load + <slpz> antrik: 1.5 GB of RAM and another 1.5 GB of swap helps a lot, too + :-) + <antrik> hm... I'm not sure what these things mean exactly TBH... but I + wonder whether some of these could fix the performance degradation (and + ultimate crash) I described recently... + +[[/open_issues/default_pager]], [[system performance degradation +(?)|performance/degradation]]. + + <antrik> care to explain them to a noob like me? + <slpz> probably not. During my tests, I've noticed that, at some points, + the system performance starts to degrade, and this doesn't change until + it's restarted + <slpz> but I wasn't able to create a test case to reproduce the bug... + <slpz> antrik: Sure. First, I've changed GNU Mach to: + <slpz> - Classify all pages from data_supply as external, and count them + in vm_page_external_count (previously, this variable was always zero) + +[[/open_issues/mach_vm_pageout]] + + <slpz> - Count all pages for which a data_unlock has been requested as + potentially dirty pages + <antrik> there is one important bit I forgot to mention in my recent + report: one "reliable" way to cause growing swap usage is simply + installing a lot of debian packages (e.g. running an apt-get upgrade) + <antrik> some other kinds of I/O also seem to have such an effect, but I + wasn't able to pinpoint specific situations + <slpz> - Establish a limit on how many potentially dirty pages are + allowed. If it's reached, a notification (right now it's just a bogus + m_o_data_unlock, to avoid implementing a new RPC) it's sent to the pager + which has generated the page fault + <slpz> - Establish a hard limit on those dirt pages. If it's reached, + threads asking for a data_unlock are blocked until someone cleans some + pages. This should be improved with a forced pageout, if needed. + <slpz> - And finally, in vm_pageout_scan, run over the inactive queue + searching for clean, external pages, freeing them. If it's not possible + to free enough pages, or if vm_page_external_count is less than 10% of + system's memory, the "normal" pageout is used. + <slpz> I need to clean up things a little, but I want to send a preliminary + patch to bug-hurd ASAP, to have more people testing it. + <slpz> antrik: Do you thing that performance degradation can be related + with the number of threads of your ext2fs translators? + <antrik> slpz: hm... I didn't watch that recently; but in the past, I + observe that the thread count is pretty constant after it reaches + something like 14000 on heavy load... + <antrik> err... wait, 14000 was ports :-) + <antrik> I doubt my system would survive 14000 threads ;-) + <antrik> don't remember thread count... I guess I should start watching + this again + <slpz> antrik: I was thinking that 14000 threads sound like a lot :-) + <slpz> what I know for sure, is that when operating with large files, the + deactivation of all pages of the memory object which is done after every + operation really hurts to performance + <antrik> right now my root FS has 5100 ports and a mere 71 thread... but + then, it's almost freshly booted :-) + <slpz> that's why I've just commented that operation in my code, since it's + not really needed anymore :-) + <slpz> anyway, after submitting all my pending mails to bug-hurd, I'll try + to hunt that bug. Sounds funny. + <antrik> regarding your explanation, I'm still trying to wrap my head + around some of the details. I must admit that I don't remember what + data_unlock does... or maybe I never fully understood it + <antrik> the limit on dirty pages is global? + <slpz> yes, right now it's global + <marcusb> I try to find the old discussion of the thread storm stuff + <marcusb> there was some concern about deadlocks + <slpz> marcusb: yes, because we were talking about putting an static limit + for the server threads of a translators + <slpz> marcusb: and that was wrong (my fault, I was even dumber back then + :-P) + <marcusb> oh boy digging in old mail is no fun. first I see mistakes in my + english. then I see quite complicated pager stuff I don't ever remember + touching. but there is a patch, and it has my name on it + <marcusb> I think I lost a couple of the early years of my hurd hacking :) + <antrik> hm... I reread the chapter on locking, and it's still above me :-( + <marcusb> not sure what you are talking about, but if there are any + specific questions... + <antrik> marcusb: external pager interface + +[[microkernel/mach/external_pager_mechanism]]. + + <marcusb> uuuuh ;) + <antrik> memory_object_lock_request(), memory_object_lock_completed(), + memory_object_data_unlock() + <marcusb> is that from the mach manual? + <antrik> yes + <antrik> I didn't really understand that part when I first read it a couple + of years ago, and I still don't understand it now :-( + <marcusb> I am sure I didn't understand it either + <marcusb> and maybe I missed my window :) + <marcusb> let's see + <antrik> hehe + <antrik> slpz: what exactly do you mean by "the pager which has generated + the page fault"? + <antrik> marcusb: essentially I'm trying to understand the explanation of + the changes slpz did, but there are several bits totally obscure to me + :-( + <slpz> antrik: when a I/O operation is requested to ext2fs, it maps the + object in question to it's own space, and then memcpy's from/to there + <slpz> antrik: so the translator (which is also a pager) is the one who + generates the page fault + <marcusb> yeah + <marcusb> antrik: it's important to understand which messages are sent by + the kernel to the manager and which are sent the other way + <marcusb> if the dest port is memory_object_t, that indicates a msg from + kernel to manager. if it is memory_object_control_t, it's a msg from + manager to kernel + <slpz> antrik: m_o_lock_request it's used by the pager to "settle" the + status of a memory object, m_o_lock_completed is the answer from the + kernel when the lock has been completed (only if the client has requested + to be notified), and m_o_data_unlock is a request from the kernel to + change the level of protection for a page (it's called from vm_fault.c) + <marcusb> slpz: but it's not pagers generating page faults, but users of + the memory object on the other side + <antrik> marcusb: well, I think the direction is clear to me... but the + purpose not really :-) + <marcusb> ie a client that mapped a file + <slpz> antrik: in ext2fs, all pages are initially provided to the kernel + (via data_supply) write protected. When a write operation is done over + one of those pages, a page fault it's generated, which sends a + m_o_data_unlock to the pager, which answers (if convenient) which a + page_lock decreasing the protection level + <marcusb> antrik: one use of lock_request is when you want to shut down + cleanly and want to get the dirty pages written back to you from the + kernel. + <marcusb> antrik: the other thing may be COW strategies + <slpz> marcusb: well, pagers and clients are in the same task for most + translators, like ext2fs + <marcusb> slpz: oh. + <slpz> marcusb: but yes, a read operation in a mmap'ed file would trigger + the fault in a client user task + <marcusb> slpz: I think I forgot everything about pagers :) + <slpz> marcusb: pager-memcpy.c is the key :-) + <marcusb> slpz: what becomes of the fault then? the kernel sees it's a + mapped memory object. will it then talk to the manager or to a pager? + <antrik> slpz: the translator causes the faults itself when it handles + io_read()/io_write() requests I suppose, as opposed to clients accessing + mmap()ed objects which then generate the faults?... + <antrik> ah, that's actually what you already said above :-) + <slpz> marcusb: I'm not sure what do you mean by "manager"... + <marcusb> manager == memory object + <marcusb> mh + <slpz> marcusb: for all external objects, it will ask to their current + pager + <marcusb> slpz: I think I am missing a couple of details, so nevermind. + It's starting to come back to me, but I am a bit afraid of that ;) + <marcusb> what I love about the Hurd is how damn readable the code is + <marcusb> considering it's an object system, it's so much nicer to read + than gtk stuff + <slpz> when you get the big picture, it's actually somewhat fun to see how + data moves around just to fulfill a simple read() + <marcusb> you should make a diagram! + <marcusb> bonus point for animated video ;) + +[[hurd/IO_path]]. + + <slpz> marcusb: heh, take a look at the hurd specific parts of glibc... I + cry in pain every time a do that... + <marcusb> slpz: oh yeah, rdwr-internal. + <marcusb> oh man + <marcusb> slpz: funny thing, I just looked at them the other day because of + the security issue + <slpz> marcusb: I think there was one, maybe a slice from someone's + presentation... + <marcusb> I think I was always confused about the pager/memobj/kernel + interactions + <slpz> marcusb: I'm barely able to read Roland's glibc code. I think it's + out of my reach. + <antrik> marcusb: I think part of the problem is confusing terminology + <marcusb> it's good that you are instrumenting the mach kernel to see + what's actually going on in there. it was a black book for me, but neal + too a peek and got a much better understanding of the performance issues + than I ever did + <antrik> when talking about "pager", we usually mean the process doing the + paging; but in mach terminology this actually seems to be the "manager", + while a "pager" is an individual object in the manager process... or + something like that ;-) + <marcusb> antrik: I just never took a look at the big picture. I look at + the parts + <marcusb> I knew the tail, ears, and legs of the elephant. + <marcusb> it's a lot of code for a beginner + <antrik> I never understood the distinction between "pager" and "memory + object" though... + <antrik> maybe "pager" refers to the object in the external pager, while + "memory object" is the part managed in Mach itself?... + <marcusb> memory object is a real object, to which you can send messages. + it's implemented in the server + <antrik> hm... maybe it's the other way around then ;-) + <marcusb> there is also the default pager + <marcusb> I think the pager is just another name for the process that + serves the memory object (default pager == memory object for anonymous + memory == swap) + <marcusb> but! + <marcusb> there is also libpager + +[[hurd/libpager]] + + <marcusb> and that's a more complicated beast + <antrik> actually, the correct term seems to be "default memory manager"... + <marcusb> yeah + <marcusb> from mach's pov + <marcusb> we always called it default pager in the Hurd + <antrik> marcusb: problem is that "pager" is sometimes used in the Mach + documentation to refer to memory object ports IIRC + <marcusb> isn't it defpager executable? + <marcusb> could be + <marcusb> it's the same thing, really + <antrik> indeed, the program implementing the default memory manager is + called "default pager"... so the terminology is really inconsistent + <marcusb> the hurd's pager library is a high level abstraction for mach's + external memory object interface. + <marcusb> i wouldn't worry about it too much + <antrik> I never looked at libpager + <marcusb> you should! + <marcusb> it's an important beast + <antrik> never seemed relevant to anything I did so far... + <antrik> though maybe it would help understanding + <marcusb> it's related to what you are looking now :) diff --git a/open_issues/resource_management_problems/zalloc_panics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn new file mode 100644 index 00000000..9c29b07c --- /dev/null +++ b/open_issues/resource_management_problems/zalloc_panics.mdwn @@ -0,0 +1,99 @@ +[[!meta copyright="Copyright © 2005, 2007, 2008, 2010, 2012 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_hurd]] + +Written by antrik / Olaf Buddenhagen, last updated: 12 Apr 2007. + +The Hurd sometimes crashes with a kernel panic saying someting like: "Panic: zalloc failed: zone map exhausted". + +These panics are generally caused by some kind of kernel resource exhaustion, but there are several differnt reasons for that. + +It used to happen very often under heavy disk load (like large compile jobs), or in a reproducible test case by opening a large number of ports to /dev/null and then closing them all very quickly. The reason for this particular problem has been identified a while back: The multithreaded Hurd servers create a new worker thread whenever a new request (RPC) comes in while all existing threads are busy. When the server is hammered with lots of requests -- which happens both under heavy disk load, and when quickly closing many ports to one server -- it will create an absurd number of threads, causing the resource exhaustion. + +The Debian hurd package contains a patch by k0ro (Sergio Lopez), which fixes this by limiting the amount of created threads in a rather simplistic but very effective manner. This patch however hasn't been included in upstream CVS so far. A more elegant solution, suitable for upstream inclusion, would be desirable. + +Some panics still seem to happen in very specific situations, like the one described at <https://savannah.gnu.org/bugs/?19426> . These are probably the result of bugs that cause port leaks, accidental fork bombs, or similar problems. + +In principle, resource exhaustion can also happen by normal use, though this is rather unlikely in the absence of bugs or malicious programs. Nevertheless, all these problems could be avoided (or limited in effect) by introducing some limits on number of processes per user, number of threads and ports per process/user etc. + +Trying to track down causes for the panics, I got some interesting results. (UPDATE: Many of my original observations were clearly related to the server thread explosion problem. To avoid confusion, I now removed these, as this is no longer an open issue.) + +* It all started with someone (probably azeem) mentioning that builing some package always crashes Hurd at the same stage of the Debian packaging process (UPDATE: Almost all of these panics when building packages were a result of the thread explosion and don't happen anymore.) +* Someone (maybe he himself) pointed out that this stage is characterized by many processes being quickly created and destroyed +* Someone else (probably hde) started some experimenting, to get a reproducible test case +* He realized that just starting and killing five child processes in quick succession suffices to kill some Hurd systems +* I tried to confirm this, but it turned out my system is more robust + +As I could never reproduce the problem with a small number of quickly killed processes, I can't say whether this problem still exists. While I could reproduce such an effect with first opening and then very quickly closing many ports (which is more or less what happens when quickly killing many processes), I needed really large numbers of processes/ports for that. The thread throtteling patch fixed my test case; but it seems unlikely that killing only five processes could have caused a thread explosion, so maybe hde's observation was a different problem really... + +I started various other experiments with creating child processes (fork bombs), resulting in a number of interesting observations: + +* Just forking a large number of processes crashes the Hurd reliably (not surprising) +* The number of processes at which the panic occurs is very constant (typicallly +-2) under stable conditions, as long as forking doesn't happen too fast +* The exact number depends on various conditions: + * Run directly from the Mach console, it's around 1040 on my machine (given enough RAM); however, it drops to 940 when started through a raw ssh session, and to 990 when run under screen through ssh (TODO: check number of ports open per process depending on how it is started) UPDATE: In a later test, I got somewhat larger numbers (don't remember exactly, but well above 1000), but still very constant between successive runs. Not sure what effected this change. + * It doesn't depend on whether normal user or root + * With only 128 MiB of RAM, the numbers drop slightly (like 100 less or so); no further change between 256 and 384 MiB + * Lowering zone\_map\_size in mach/kern/zalloc.c reduces the numbers (quite exactly half from 8 MiB to 4 MiB) + * There seems to be some saturation near 16 MiB however: The difference between 8 MiB and 16 MiB is significantly smaller + * Also, with 8 MiB or 4 MiB, the difference between console/ssh/screen becomes much more apparent (500 vs. 800, 250 vs. 400) + * With more than 16 MiB, Mach doesn't even boot +* Creating the processes very fast results in a sooner and less predictable crash (TODO: Check whether this is still the case with thread throtteling?) +* Creating processes recursively (fork only one child which forks the next one etc.) results in faster crash +* rpcinfo shows that child processes have more ports open by default, which is very likely the reason for the above observation +* Opening many ports from a few processes doesn't usually cause a system crash; there are only lots of open() failures and translator faults once some limit is reached... Seems the zalloc-full condition is better caught on open() than on fork() (TODO: investigate this further, with different memory sizes, different zone\_map\_size, different kinds of resources using zalloc etc.) +* After opening/leaking lots of ports to /dev/null (32768 it seems), the NULL translator somehow becomes disfunctional, and a new instance is started + +While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation. + + +# IRC, freenode, #hurd, 2012-04-01 + + <mel__> antrik: i just found + http://www.gnu.org/software/hurd/open_issues/resource_management_problems/zalloc_panics.html + -- that is from 2007. is this still the current status? + <youpi> mel__: probably + <mcsim> mel__: gnumach has no more zalloc allocator, so I doubt if it could + be a problem. + +[[gnumach_memory_management]]. + + <youpi> mcsim: but it still has an allocator + <youpi> which can run out of resources + <mcsim> AFAIR, now there is no such limit. + <youpi> err, there is + <youpi> the size of your RAM :) + <mcsim> In zalloc appearing of this message didn't depend of available size + of free ram. + <youpi> then update the description, but I'm still getting allocation + errors, when userland makes crazy things like creating millions of tasks + <mcsim> At least it could appear when there still was free memory + <youpi> and that's not surprising + <youpi> sure, I know that *some* limits have been removed, but there + weren't so many, and I have seen cases where it's simply mach running out + of memory + <youpi> also, we have a limited amount of virtual addressing space + <antrik> mel__: this writeup is outdated in several regards. *some* of the + observations might still be relevant, but nothing that seems + particularily important + <antrik> the zalloc panics have pretty much disappeared after the default + zalloc zone size has been considerably extended (which was not possible + before because of some bug) + <mel__> i see + <antrik> but as mcsim pointed out, with the new allocator not relying on a + fixed-sized zalloc zone at all, they are even less likely, and should + happen only if all memory is exhausted + <antrik> I guess this outdated report can just be dropped + <mcsim> I think, that now it is problem rather of absence of OOM-killer or + resource manager + <antrik> mcsim: right :-) + <antrik> (and we have separate articles about that) diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn new file mode 100644 index 00000000..7c66776b --- /dev/null +++ b/open_issues/rework_gnumach_ipc_spaces.mdwn @@ -0,0 +1,723 @@ +[[!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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 + + <braunr> things that are referred to as "system calls" in glibc are + actually RPCs to the kernel or other tasks, those RPCs have too lookup + port rights + <braunr> the main services have tens of thousands of ports, looking up one + is slow + +There is a [[!FF_project 268]][[!tag bounty]] on this task. + + +# IRC, freenode, #hurd, 2011-04-23 + + <braunr> youpi: is there any use of the port renaming facility ? + <youpi> I don't know + <braunr> at least, did you see such use ? + <braunr> i wonder why mach mach_port_insert_right() lets the caller specify + the port name + <youpi> ../hurd-debian/hurd/serverboot/default_pager.c: kr = + mach_port_rename( default_pager_self, + <braunr> mach_port_rename() is used only once, in the default pager + <braunr> so it's not that important + <braunr> but mach_port_insert_right() lets userspace task decide the port + name value + <youpi> just to repeat myself again, I don't know port stuff very much :) + <braunr> well you know that a port denotes a right, which denotes a port + <youpi> yes, but I don't have any real experience with it + <braunr> err + <braunr> port name + <braunr> the only reason I see is that the caller, say /hurd/exec running a + fork() + <braunr> hm + <braunr> no, i don't even see the reason here + <braunr> port names should be allocated by the kernel only, like file + descriptors + <youpi> you can choose file descriptor values too + <braunr> really ? + <youpi> with dup2, yes + <braunr> oh + <braunr> hm + <braunr> what's the data structure in current unices to store file + descriptors ? + <braunr> a hash table ? + <youpi> I don't know + <braunr> i'll have to look at that + <braunr> FYI, i'm asking these questions because i'm thinking of reworking + ipc spaces + <braunr> i believe the use of splay trees completely destroys performance + of tasks with many many port names such as the root file system + <youpi> that can be a problem yes + <youpi> since there are 3 ports per opened file, and like 3 per thread too + <braunr> + the page cache + <youpi> with a few thousand opened files and threads, that makes a lot + <youpi> by "opened file" I meant page cache actually + <braunr> i saw numbers up to 30k + <braunr> ok + <youpi> on buildds I easily see 100k ports + <braunr> for a single task ? + <braunr> wow + <youpi> yes + <youpi> the page cache is 4k files + <braunr> so that's definitely worth the try + <youpi> so that already makes 12k ports + <youpi> and 4k is not so big + <braunr> it's limited to 4K ? + <youpi> I haven't been able to check where the 100k come from yet + <youpi> braunr: yas + <braunr> could be leaks :/ + <youpi> yes + <braunr> omg, a hard limit on the page cache .. + <youpi> vm/vm_object.c:int vm_object_cached_max = 4000; /* may + be patched*/ + <braunr> mach is really old :( + <youpi> I've raised it + <youpi> before it was 200 + <youpi> ... + <braunr> oO + <youpi> I tried to dro pthe limit, but then I was lacking memory + <youpi> which I believe have fixed the other day, but I have to test again + <braunr> that implementation doesn't know how to deal with memory pressure + <youpi> yes + <braunr> i saw your recent changes about adding warnings in such cases + <braunr> so, back to ipc spaces + <braunr> i think splay trees 1/ can get very unbalanced easily + <braunr> which isn't hard to imagine + <braunr> and 2/ make poor usage of the cpu caches because they're BST and + write a lot to memory + <youpi> maybe you could write a patch which would dump statistics on that? + <braunr> that's part of the job i'm assigning to myself + <youpi> ok + <braunr> i'd like to try replacing splay trees with radix trees + <youpi> I can run it on the buildds + <youpi> buildds are very good stress-tests :) + <braunr> :) + <youpi> 22h building -> 77k ports + <youpi> 26h building -> 97k ports + <youpi> the problem is that when I add leak debugging (backtraces), I'm + getting out of memory :) + <braunr> that will be a small summer of code outside the gsoc :p + <braunr> :/ + <braunr> backtraces are very consuming + <youpi> but that's only because of hardcoded limits + <youpi> I'll have to test again with bigger limits + <braunr> again .. + <braunr> evil hard limits + <youpi> well, actually we could as well just drop them + <youpi> but we'd also need to easily get statistics on zone/vm_maps usage + <youpi> because else we don't see leaks + <youpi> (except that the machine eventually crashes) + <braunr> hm + <braunr> i haven't explained why i was asking my questions actually + <braunr> so, i want radix trees, because they're nice + <braunr> they reduce the paths lengths + <braunr> they don't get too unbalanced (they're invariant wrt the order of + operations) + <braunr> they don't need to write to memory on lookups + <braunr> the only drawback is that they can create much overhead if their + usage pattern isn't appropriate + <braunr> elements in such a structure should be close, so that they share + common nodes + <youpi> the common usage pattern in ext2fs is a big bunch of ever-open + ports :) + <braunr> if there is one entry per node, it's a big waste + <braunr> yes + <youpi> there are 3, actually + <braunr> but the port names have low values + <braunr> they're allocated sequentially, beginning at 0 + <braunr> (or 1 actually) + <braunr> which is perfect for radix trees + <youpi> yes + <youpi> 97989: send + <braunr> but if anyone can rename + <braunr> this introduces a new potential weakness + <youpi> ah, if it's just a weakness it's probably not a problem + <youpi> I thought it was even a no-go + <braunr> i think so + <youpi> I guess port rename is very seldom + <braunr> but in a future version, it would be nice not to allow port + renaming + <braunr> unless there are similar issues in current unix kernels + <braunr> in which case i'd say it's acceptable + <youpi> there are + <braunr> of that order ? + <youpi> and it'd be useful for e.g. processing + tracing/debugging/tweaking/whatever + <youpi> it's also used to hide fds from a process + <braunr> port renaming you mean ? + <youpi> you allocate them very high + <youpi> yes + <braunr> ok + <youpi> choosing your port name, generally + <youpi> to match what the process expects for instance + <braunr> then it would be a matter of resource limiting (which we totally + lack afaik) + <braunr> along the number of maximum open files, you would have a number of + maximum rights + <braunr> does that seem fine to you ? + <youpi> if done throught rlimits, sure + <braunr> something similar yes + <youpi> (_no_ PORTS_MAX ;) ) + <braunr> oh and, in addition, i remember gnumach has a special + configuration of the processor in which caching is limited + <braunr> like write-through only + <youpi> didn't I fix that recently ? + <braunr> i don't know :) + <braunr> CR0=e001003b + <braunr> i don't think it's fixed + <youpi> I mean, in the git + <braunr> ah + <youpi> not in the debian package + <braunr> didn't tried the git version yet + <braunr> last time i tried (which was a long time ago), it made the kernel + crash + <braunr> have you figured why ? + <youpi> I'm not aware of that + <braunr> anyway, splay trees write a lot, and most trees write a lot even + at insertion/removal to rebalance + <youpi> braunr: Mmm, there's no clearance of CD in the kernel actually + <braunr> with radix trees, even if caching can't be fully enabled, it would + make much better use of it + <braunr> so if port renaming isn't a true issue, i'll choose that data + structure + <youpi> that'd probably be better yes + <youpi> I'm surprised by the CD, I do remember fixing something like this + lately + <braunr> there are several levels where CD can be set + <braunr> the processors ORs all those if i'm right + <braunr> to determine if caching is enabled + <youpi> I know + <braunr> ok + <youpi> but in my memory that was at the CR* level, precisely + <braunr> maybe for xen only ? + <youpi> no + <braunr> well good luck if you hunt that one, i'm off, see you :) + <youpi> braunr: ah, no, it was the PGE flag that I had fixed + + <antrik> braunr: explicit port naming is used for example to pass some + initial ports to a new task at well-known places IIRC + <antrik> braunr: but these tend to be low numbers, so I don't see a problem + there + <antrik> (I'm not familiar with radix trees... why would high numbers be a + problem?) + + <youpi> braunr: iirc the ipc space is limited to ~192k ports + + <braunr> antrik: in most cases i've seen, the insert_right() call is used + on task_self() + <braunr> and if there really are special ports (like the bootstrap or + device ports), they should have special names + <braunr> IIRC, these ports are given through command line expansion by the + kernel at boot time + <braunr> but it seems reasonable to think of port renaming as a potentially + useful feature + <braunr> antrik: the problem with radix trees isn't them being high, it's + them being sparse + <braunr> you get the most efficient trees when entries have keys that are + close to each other + <braunr> because radix trees are a type of tries (the path in the tree is + based on the elements composing the key) + <braunr> so the more common prefixes you have, the less external nodes you + need + <braunr> here, keys are port names, but they can be memory addresses or + offsets in memory objects (like in the page cache) + <braunr> the radix algorithm takes a few bits, say 4 or 6, at a time from a + key, and uses that as an index in a node + <braunr> if keys are sparse, there can be as little as one entry per node + <braunr> IIRC, the worst case (on entry per node with the maximum possible + number of nodes for a 32-bits key) is 2% entries + <braunr> the reste being null entries and almost-empty nodes containing + them + <braunr> so if you leave the ability to give port rights the names you + want, you can create such worst case trees + <braunr> which may consume several MiB of memory per tree + <braunr> tens of MiB i'd say + <braunr> on the other hand, in the current state, almost all hurd + applications use sequentially allocated port names, close to 0 (which + allows a nice optimization) + <braunr> so a radix ree would be the most efficient + <antrik> well, if some processes really feel they must use random numbers + for port names, they *ought* to be penalized ;-) + + +# IRC, freenode, #hurd, 2011-04-27 + + <braunr> antrik: remember when you asked why high numbers would be a + problem with radix trees ? + <braunr> here is a radix tree with one entry, which key is around 5000 + <braunr> [ 656.296412] tree height: 3 + <braunr> [ 656.296412] index: 0, level: 0, height: 3, count: 1, + bitmap: 0000000000000002 + <braunr> [ 656.296412] index: 1, level: 1, height: 2, count: 1, + bitmap: 0000000000004000 + <braunr> [ 656.296412] index: 14, level: 2, height: 1, count: 1, + bitmap: 0000000000000080 + <braunr> three levels, each with an external node (dynamically allocated), + for one entry + <braunr> so in the worst case of entries with keys close to the highest + values, the could be many external nodes with higher paths lengths than + when keys are close to 0 + <braunr> which also brings the problem of port name allocation + <braunr> can someone with access to a buildd which has an uptime of at + least a few days (and did at least one build) show me the output of + portinfo 3 | tail ? + <braunr> port names are allocated linearly IIRC, like PIDs, and some parts + of the kernel may rely on them not being reused often + <braunr> but for maximum effifiency, they should be + <braunr> efficiency* + <braunr> 00:00 < braunr> can someone with access to a buildd which has an + uptime of at least a few days (and did at least one build) show me the + output of portinfo 3 | tail ? + <braunr> :) + <youpi> it's almost like wc -l + <youpi> 4905: receive + <youpi> vs 4647 + <youpi> for / + <youpi> 52902: receive + <youpi> vs 52207 + <youpi> for the chroot + <braunr> even after several builds ? + <braunr> and several days ? + <youpi> that's after 2 days + <youpi> it's not so many builds + <youpi> rossini is not so old + <youpi> (7h) + <youpi> but many builds + <youpi> 70927: send + <youpi> vs 70938 + <braunr> ok + <braunr> so it seems port names are reused + <braunr> good + <youpi> yes they are clearly + <braunr> i think i remember a comment about why the same port name + shouldn't be reused too soon + <youpi> well, it could help catching programming errors + <braunr> that it helped catch bugs in applications that could + deallocate/reallote quickly + <braunr> reallocate* + <braunr> without carefuly synchronization + <braunr> careful + <braunr> damn, i'm tired :/ + <youpi> but that's about debugging + <youpi> so we don't care about performance there + <braunr> yes + <braunr> i'll try to improve allocation performance too + <braunr> using e.g. bitmaps in each external node back to the root so that + unused slots are quickly found + <braunr> i thknk that's what idr does in linux + <antrik> braunr: idr? + <braunr> antrik: a data structure used to map integers to pointers + <braunr> http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6 + + +# IRC, freenode, #hurd, 2011-06-08 + + <braunr> hm, reverse space/port to name lookups also suck + <braunr> having separate types for simple ipc entries and splay tree + entries really makes many parts of the ipc code complicated + <braunr> and a global hash table for these operations is scary + + +# IRC, freenode, #hurd, 2011-06-09 + + <braunr> hm nice, my radix tree code runs inside gnumach, along with the + original splay tree code and assertions making sure results are the same + <braunr> there is this "collision" thing i'm not sure to understand but + once this is solved, replacing the splay trees should be easy + + <braunr> youpi: is there a way to easily know the number of send rights + associated to a port ? + <youpi> portinfo ? + <braunr> portinfo gives information in a space + <braunr> but this is specific to a port + <braunr> is there an option for that ? + <youpi> -v + <braunr> hm ok + <youpi> 25: send (refs: 550) + <braunr> nice + <braunr> youpi: if you have time, could you give me the min/max/avg numbers + of send rights referring to the same port on buildds ? + <braunr> i'm trying to estimate if it's better to have space->list_of_ports + or port->list_of_spaces to replace the global ipc hash table + <braunr> the latter seems better but there could be unexpected cases on + machines using large amounts of resources like the buildds + <youpi> max is 64k + <youpi> min is 1 of course :) + <braunr> 64k + <braunr> then it's not what i'm looking for + <youpi> avg is 55 + <braunr> isn't this the number of urefs ? + <youpi> I don't know + <braunr> hmm + <braunr> what i'm looking for is the number of *pure send rights* for the + same port + <braunr> i don't think portinfo can give it + <braunr> there can only be one such send right per task for the same port + <braunr> 64k would mean there are 64k tasks + <youpi> ok, so it's more difficult + <youpi> it means using -t + <braunr> ahh + <youpi> and run n^2 portinfo over the n processes + <braunr> i see + <youpi> Mmm, that will however still show any duplicate send right + <youpi> but then by min/max/avg, you mean, over time ? + <braunr> i'll change the source code, simpler + <youpi> e.g. min would be right after boot? + <braunr> min is 1 + <youpi> 1 what ? + <braunr> 1 send right to a port + <youpi> ah, 1 for a given port + <braunr> yes + <youpi> ok, it becomes really hairy to compute, I don't hav ethe time :) + <braunr> avg and max are more interesting :) + <braunr> no worries + <youpi> braunr: I wouldn't be surprised that max is the number of tasks + <youpi> e.g. for a send port to the proc server for instance + <braunr> youpi: it is, but i'm not looking for potential numbers + <youpi> I'm not talking about a potential number, but an actual number + that's almost always true + <braunr> for one port, yes + <braunr> but yes, ok for max + <braunr> this makes choosing an appropriate data structure difficult + + <antrik> braunr: actually, min number of send rights to a port is 0... but + I'm sure you know that already :-) + + <antrik> youpi: normally each client gets a separate port. I'm not sure + there are any ports with send rights distributed over many tasks... + + <jkoenig> antrik, what about / ? + + <youpi> antrik: not necessarily + + <antrik> jkoenig: not sure... isn't the "/" port authenticated to the + specific user? + + <jkoenig> antrik, I guess so, but a single user could still have many + tasks. + <jkoenig> (wrt /) + <antrik> jkoenig: well, in theory the tasks having exactly the same UIDs + and GITs could probably share an auth token... but that's not how things + are handled in general + <antrik> at least I don't think so + <antrik> tasks are authenticated, not users + <antrik> err... GIDs :-) + <jkoenig> antrik, still, my quick glance to the fork() code seemed to + indicate the port is inherited as-is, maybe authentication happens only + when something is actually looked up? + <jkoenig> hmm "rpctrace ls -d /" does not show any authentication calls, + only a lookup("") on the root which returns a different port + <jkoenig> so I guess the root port is "deauthenticated" or something when + the uid of a process is changed. + <antrik> too bad cfhammer isn't around, he digged into all this stuff... + <antrik> I know that there is a mechanism which reauths all FDs when the + IDs of a process change + <antrik> but I'm not sure the "/" port uses this mechanism + + <braunr> antrik: but the radix tree codee is really used as is, which means + no locking, no preloading before locking, all of this because simple + locks don't exist on UP, and because the kernel isn't preemptible + + <braunr> antrik: and yes, min number is 0, but in that case you don't need + (space, port) -> right lookups :) + <braunr> antrik: or put in another way, whichever reasonable structure you + use, when it's empty, you don't care much + <braunr> which also means that the min number has actually no value here + <braunr> because the same applies to 1 + + <braunr> then what seems to take most time is forks + <braunr> and i hope my upcoming kernel changes will help the situation a + bit + <pinotree> what are your incoming gnumach changes about? + <braunr> the ipc translation layer speed + <braunr> which basically means operating on port names (looking them up, + inserting, removing, renaming, looking up send rights to a specific + ports) will be faster + <braunr> and i believe forks are (one of) the most demanding use cases wrt + ipc space manipulation + <braunr> i'm really surprised how badly the splay trees are used + <braunr> the worst case for this data structure is traversal + <braunr> and this is done in many situations + <braunr> leaving the tree in its worst case shape + <braunr> and i didn't mentioned the bunch of memory writes occurring, event + for things like lookups or traversals + <braunr> this is slow and can disrupt many cpu cache lines + <braunr> and when there are 10k to 100+k (e.g. in some ext2fs instances on + buildds), just imagine the number of operations involved in those + operations + <braunr> a simple traversal_next involves a rotation *gasp* + <braunr> this means potentially writing on 3 different cache lines, for + *one* next operation + <pinotree> what are you replacing that splay tree with? + <braunr> radix trees + <braunr> much shorter paths + <braunr> extremely few memory writes + <braunr> locality of reference when traversing + <braunr> good cache usage (as many of the top nodes are reused) + <braunr> the two drawbacks are 1/ memory allocation for external nodes, + which means the tree must be preloaded before locking + <braunr> and 2/ high memory overhead if the keys are sparse + <braunr> but this isn't the case with port names, unless someone messes it + up by assigning random names to many rights + + <antrik> braunr: so, when will we see the first performance comparision? + :-) + <braunr> antrik: that's a topic of itself, how to compare ? + <braunr> antrik: the thing is, my current gnumach patches only makes + assertions + <braunr> this is the best way i found to test my tree in real life + conditions + <braunr> much cleanup is needed + <braunr> and what i'd like to do is to completely replace all teh + translation layer structures with it + <braunr> which means removing much code, making sure it still works as + expected + <braunr> this is tedious + <braunr> so one month at least + <antrik> braunr: comparing shouldn't be too hard... the average configure + script does a lot of forking, which should be a good benchmark according + to your observations + <braunr> rough estimates are easy, yes + <braunr> but my observations my be wrong :p + <antrik> braunr: well, we don't really need precise numbers... + <antrik> unless you need to do some kind of fine-tuning? + <braunr> i don't know yet + + +# IRC, freenode, #hurd, 2011-06-18 + + < braunr> hmm, i'm having a problem with integrating my radix tree code in + gnumach + < braunr> inserting into such a tree can trigger memory allocation + < braunr> so commonly, the tree i loaded with nodes before insertion, + usually if it requires strong locking + < braunr> ipc spaces are locked using "simple locks" (which are spin locks) + < braunr> but spin locks are noops on UP, and gnumach is always UP .. + < braunr> so, should i still include preloading code, even if it'll end up + dead code ? + < antrik> hm... I think we discussed this before; but isn't gnumach + supposed to be SMP-capable, minus bugs?... + < braunr> it is + < braunr> but ofc, if i choose not to include preloading, i'll write + #errors so that the day gnumach is built for SMP again, such support will + be included + < antrik> oh, sorry, I think I misread. what is UP? + < braunr> uniprocessor + < antrik> well, if it's just bugs forcing the current UP state, I think + saying that gnumach is always UP is a stretch... + < braunr> sure, but it's a practical consideration + < antrik> does the locking complicate stuff? or is it just performance + considerations? + < braunr> no it's about correctness and completeness + < braunr> if you don't preload a tree before locking + < braunr> and memory allocation occurs while you're holding a simple lock + < braunr> and memory allocation requires the kernel to sleep + < braunr> you're screwed + < braunr> but i hate the idea of including code that won't be used and + which won't be easy to test + < braunr> so i'm wondering if it's ok for now to just put this in a TODO + comment and write it when the time is right + < braunr> or if i should spens the week adding this and tweaking the + userspace implementation to "emulate" spin locks + < antrik> well, it's tricky situation. on one hand, it seems stupid to + include handling for something that presently isn't used, and it's not + clear when it will. on the other hand, I'd rather not see additional + problems introduced that will make fixing SMP even harder... + < braunr> that's why i'm asking here + < antrik> of course, you could resolve this question by fixing SMP + first... ;-) + < braunr> ew + < antrik> well, I guess it would be best first to make the code work... and + we can still decide about the locking thing before it goes mainline I'd + say? + < braunr> "make the code work" ? + < antrik> I mean make gnumach work with your radix tree code + < braunr> without preloading then + < antrik> yeah... as a first step... I guess adding it later won't be any + harder than adding it right now? + < braunr> not much + < braunr> testing is what requires time really + + +# IRC, freenode, #hurd, 2011-06-27 + + < braunr> ok, here is the radix tree code: + http://git.sceen.net/rbraun/libbraunr.git/ + < braunr> the preloading stuff will be added in the kernel only, as it's + really pointless and not easily doable in userspace + < youpi> preloading? + < braunr> youpi: yes, preloading + < braunr> radix trees allocate external nodes + < youpi> well, providing a url at some random time of some random day is + not a great way to get eyes on it :) + < braunr> and ipc spaces are locked when inserting/allocating names + < braunr> we normally don't need preloading in gnumach + < braunr> since there is no preemption nor SMP + < braunr> but in case someone changes that, i'd like the code to be mostly + ready + < braunr> and correctly handle those ugly simple locks + < braunr> youpi: is what i say clear enough or do you need more background + on what is done ? + < youpi> about preloading? + < braunr> yes + < youpi> I guess it means allocating nodes in advance? + < braunr> yes + < youpi> k + < braunr> before locking the ipc spaces + + +# IRC, freenode, #hurd, 2011-06-28 + + < braunr> antrik: i think i won't write the code for the preloading stuff + actually + < braunr> antrik: it's not very difficult, but i really hate the idea of + not being able to reliably test it + < braunr> antrik: and i'd rather concentrate on integrating the radix tree + code in gnu mach now + < braunr> (i've already removed much code, even some files which weren't + actually used before my changes !) + < braunr> hmm, i won't be able not to write the preloading code after all + < antrik> braunr: not able not to write? how's that? + < braunr> antrik: it's actually required + < braunr> there are three functions, ipc_entry_get, ipc_entry_alloc, and + ipc_entry_grow_table + < braunr> ipc_entry_get cannot allocate memory + < braunr> if it fails, ipc_entry_grow_table is called, which will allocate + memory + < braunr> ipc_entry_alloc calls both of them depending on the result of + ipc_entry_get + < braunr> this is the equivalent of the preloading thing i had in mind + < braunr> not a bad thing after all + < braunr> the only thing i'm afraid of are the "optimized" version of those + ipc functions in te so-called fast paths + < braunr> i'm afraid if i don't deal right with those, the kernel may end + up using mostly slow paths + < braunr> but considering the purpose of those fast paths was merely to + avoid the overhead of function calls and some locking functions, it + shouldn't be that bad + < braunr> this is such a mess eh + < antrik> hurray microoptimisations ;-) + < braunr> there, the preload functions are done, easy :) + < antrik> braunr: seems you spent less time implementing it than pondering + whether you should implement it ;-) + < braunr> well, i couldn't implement it correctly before knowing what + should have been done exactly + < braunr> and there are still other problems :/ + < braunr> and the other problems make me reconsider if this was useful at + all eh + < braunr> youpi: i'm unable to find where ipc tree entries are released + except in ipc_entry_alloc_name(), which could mean they're leaked ... + < braunr> youpi: would you have time to take a look ? + < youpi> they aren't in ipc_entry_dealloc() ? + < braunr> no ..... + < youpi> it's not so unprobable that they're only freed when the task quits + < braunr> i don't see that either + < braunr> i only see them released in ipc_entry_alloc_name() + < braunr> so maybe they're reused + < braunr> but i'm not sure about that when reading the code + < braunr> oh wait, yes, they are :/ + < braunr> my bad + < youpi> in the ipc_splay_tree_* fucntions I guess? + < braunr> yes + < braunr> it's just surprsing to see them allocated outside the tree code + only + < braunr> but released in both the entry and the splay tree code ... + + +# IRC, freenode, #hurd, 2011-06-29 + + < braunr> hmm i missed an important thing :/ + < braunr> and it's scary + < braunr> it looks like the splay tree is mainly used when names are + provided + < braunr> whereas the entry table is used when names are allocated + < braunr> which means the table is the main ipc data structure, even for + tasks with lots of rights + < braunr> i can make my root ext2fs have more than 10k rights, and i see + the ipc table table grow along that number ... + < braunr> now thetable has 15k+ entries + < braunr> IOW there is no point to put the radix tree code in gnumach :( + < antrik> braunr: what do you mean by "provided" and "allocated"? + < antrik> and what is that table you are talking about? + < braunr> antrik: provided means the user space tasks gives the name of the + new right + < braunr> antrik: allocated means the kernel generates it + < braunr> antrik: the table i'm talking about is is_table in struct + ipc_space + < braunr> 55 * Every space has a non-NULL is_table with + is_table_size entries. + < braunr> 56 * A space may have a NULL is_tree. is_tree_small + records the + < braunr> 57 * number of entries in the tree that, if the table were + to grow + < braunr> 58 * to the next larger size, would move from the tree to + the table. + < braunr> here is the description which mislead me (in addition of the + obscure code) + < braunr> 50 * Spaces hold capabilities for ipc_object_t's (ports + and port sets). + < braunr> 51 * Each ipc_entry_t records a capability. Most + capabilities have + < braunr> 52 * small names, and the entries are elements of a table. + < braunr> 53 * Capabilities can have large names, and a splay tree + holds + < braunr> 54 * those entries. The cutoff point between the table + and the tree + < braunr> 55 * is adjusted dynamically to minimize memory + consumption. + < antrik> ah, so the rights with a low name are in a linear table, and only + those with "random" high names are stored in the splay tree instead? + < antrik> seems a rather complex design... I guess though there isn't much + room for further optimisation there :-( + < antrik> (well, except for code size optimisation -- which could in fact + make a considerable difference...) + < braunr> well there are problems with this approach, but most don't + concern performance + < braunr> when the table gets big (close to the page size or more), it gets + remapped when reallocated + < braunr> which will incur some penalty because of the tlb + < braunr> but it's annoying even for small tables + < braunr> the initial table size is 4 entries, and from what i can see, + most tables are 128 entries wide when tasks are destroyed + < braunr> an obvious simple optimization is to set a larger default size + < braunr> the same applies for the dead name tables + < braunr> those reallocations are a pain, and they're due to this design + < braunr> they can also fail because of fragmentation + < braunr> there would be a point to radix trees if they would replace all + that, and not just the splay tree + < braunr> but this would cause a lot of changes in a lot of places, and in + particular the "optimized" fast paths i mentioned yesterday + < braunr> we'll see how they perform in x15 :> + < braunr> there is a slight noticeable improvement when increasing the + initial size of the entry table + < antrik> braunr: well, if you use them in a completely different + implementation, there will be no way of telling whether they make a + difference + < antrik> how did you test the improvement? + < braunr> antrik: no actually it's completely negligeable + < braunr> hm + < braunr> is that a valid word ? :) + < braunr> negligible + < braunr> youpi: did you see my comments about the ipc stuff this earlier + today ? + < braunr> youpi: well to make things short, when port names are allocated, + the right they refer to is allocated from the ipc table + < braunr> youpi: the splay tree is only used for user provided names + < braunr> youpi: i had tables as large as the number of rights in a space + (i could easily reach 20k) + < braunr> youpi: whereas the splay trees had at most ~40 entries .. diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn new file mode 100644 index 00000000..aab52d97 --- /dev/null +++ b/open_issues/rm_fr.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_hurd]] + +From: Samuel Thibault <samuel.thibault@gnu.org> +Subject: rm -fr slowness + +I have always been surprised by the slowness of a mere rm -fr. Looking a +bit inside, I see that diskfs_dirremove_hard() calls diskfs_file_update +(dp, 1) (as does diskfs_truncate, diskfs_direnter_hard, and +diskfs_dirrewrite_hard). diskfs_file_update then calls pager_sync on +the pager, which thus writes back the whole ext2fs pager! + +This sounds a bit excessive to me, an unlink could just record it in +memory and actually sync later. Also, the wait flag is set, so we +really waits for all I/Os, which basically means strictly serializing +file removals: remove one file, wait for the disk to have done it +(~10ms), remove the next one, etc. I guess this is for safety reasons +against crashes, but isn't the sync option there for such kind of + + +# IRC, freenode, #hurd, 2011-07-23 + + <antrik> youpi: hm... async deletion does have one downside: I just removed + something to make space, and retried the other command immediately + afterwards, and it still said "no space left on device"... a few seconds + later (after the next regular sync I suppose?) it worked + <youpi> well, that's sorta expected, yes + <youpi> we get the same on Linux + <youpi> Mmm, on second thought, I'm not sure how that can happen + <youpi> the asynchronous thing is for disk writes, not cache writes diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn new file mode 100644 index 00000000..1f8aa0c6 --- /dev/null +++ b/open_issues/robustness.mdwn @@ -0,0 +1,129 @@ +[[!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 open_issue_hurd]] + + +# IRC, freenode, #hurd, 2011-11-18 + + <nocturnal> I'm learning about GNU Hurd and was speculating with a friend + who is also a computer enthusiast. I would like to know if Hurds + microkernel can recover services should they crash? and if it can, does + that recovery code exist in multiple services or just one core kernel + service? + <braunr> nocturnal: you should read about passive translators + <braunr> basically, there is no dedicated service to restore crashed + servers + <etenil> Hi everyone! + <braunr> services can crash and be restarted, but persistence support is + limited, and rather per serivce + <braunr> actually persistence is more a side effect than a designed thing + <braunr> etenil: hello + <etenil> braunr: translators can also be spawned on an ad-hoc basis, for + instance when accessing a particular file, no? + <braunr> that's what being passive, for a translator, means + <etenil> ah yeah I thought so :) + + +# IRC, freenode, #hurd, 2011-11-19 + + <chromaticwt> will hurd ever have the equivalent of a rs server?, is that + even possible with hurd? + <youpi> chromaticwt: what is an rs server ? + <chromaticwt> a reincarnation server + <youpi> ah, like minix. Well, the main ground issue is restoring existing + information, such as pids of processes, etc. + <youpi> I don't know how minix manages it + <antrik> chromaticwt: I have a vision of a session manager that could also + take care of reincarnation... but then, knowing myself, I'll probably + never imlement it + <youpi> we do get proc crashes from times to times + <youpi> it'd be cool to see the system heal itself :) + <braunr> i need a better description of reincarnation + <braunr> i didn't think it would make core servers like proc able to get + resurrected in a safe way + <antrik> depends on how it is implemented + <antrik> I don't know much about Minix, but I suspect they can recover most + core servers + <antrik> essentially, the condition is to make all precious state be + constantly serialised, and held by some third party, so the reincarnated + server could restore it + <braunr> should it work across reboots ? + <antrik> I haven't thought about the details of implementing it for each + core server; but proc should be doable I guess... it's not necessary for + the system to operate, just for various UNIX mechanisms + <antrik> well, I'm not aware of the Minix implementation working across + reboots. the one I have in mind based on a generic session management + infrastructure should though :-) + + +## IRC, freenode, #hurd, 2012-12-06 + + <Tekk_> out of curiosity, would it be possible to strap on a resurrection + server to hurd? + <Tekk_> in the future, that is + <braunr> sure + <Tekk_> cool :) + <braunr> but this requires things like persistence + <spiderweb> like a reincarnation server? + <braunr> it's a lot of works, with non negligible overhead + <Tekk_> spiderweb: yes, exactly. I didn't remember tanenbaum's wording on + that + <braunr> i'm pretty sure most people would be against that + <spiderweb> braunr: why so? + <Tekk_> it was actually the feature that convinced me that ukernels were a + good idea + <Tekk_> spiderweb: because then you need a process that keeps track of all + the other servers + <Tekk_> and they have to be replying to "useless" pings to see if they're + still alive + <braunr> spiderweb: the hurd community isn't looking for a system reliable + in critical environments + <braunr> just a general purpose system + <braunr> and persistence requires regular data saves + <braunr> it's expensive + <Tekk_> as well as that + <braunr> we already have performance problems because of the nature of the + system, adding more without really looking for the benefits is useless + <spiderweb> so you can't theoretically have both? + <braunr> persistence and performance ? + <braunr> it's hard + <Tekk_> spiderweb: you need to modify the other translators to be + persistent + <braunr> only the ones you care about actually + <braunr> but it's just better to make the critical servers very stable + <Tekk_> so it's not just turning on and off the reincarnation + <braunr> (there isn't that much code there) + <braunr> and the other servers restartable + <mcsim> braunr: I think that if there will be aim to make something like + resurrection server than it will be needed rewrite most servers to make + them stateless, isn't it? + <braunr> that's a lot easier and already works with non essential passive + translators + <Tekk_> mcsim: pretty much + <braunr> mcsim: only those you care about + <braunr> mcsim: the proc auth exec servers for example, perhaps the file + system servers that can act as root fs, but the others would simply be + restarted by the passive translator mechanism + <spiderweb> what about restarting device drivers, that would be simple + right? + <braunr> that's perfectly doable, yes + <spiderweb> (being an OS newbie) - it does seem to me that the whole + reincarnation server concept could quite possibly be a band aid. + <braunr> spiderweb: no it really works + <braunr> many systems do that actually + <braunr> let me give you a link + <braunr> + http://ftp.sceen.net/curios_improving_reliability_through_operating_system_structure.pdf + <braunr> it's a bit old, but there is a review of systems aiming at + resilience and how they achieve part of it + <spiderweb> neat, thanks + <braunr> actually it's not that old at all + <braunr> around 2007 diff --git a/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn new file mode 100644 index 00000000..9db92250 --- /dev/null +++ b/open_issues/rpc_to_self_with_rendez-vous_leading_to_duplicate_port_destroy.mdwn @@ -0,0 +1,163 @@ +[[!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]] + +[RPC to self with rendez-vous leading to duplicate port +destroy](http://lists.gnu.org/archive/html/bug-hurd/2011-03/msg00045.html) + +IRC, freenode, #hurd, 2011-03-14 + + <antrik> youpi: I wonder, why does the root FS call diskfs_S_dir_lookup() + at all?... + <youpi> errr, because a client asked for it? + <youpi> (problem with RPCs is you can't easily know where they come from :) + ) + <youpi> (especially when it's the root fs...) + <antrik> ah, it's about a client request... didn't see that + <youpi> well, I just said "is called", yes + <antrik> I do not really understand though why it tries to reauthenticate + against itself... + <antrik> I fear my memory of the lookup mechanism grew a bit dim + <youpi> see the source + <youpi> it's about a translated entry + <antrik> (and I never fully understood some aspects anyways...) + <youpi> it needs to start the translated entry as another user, possibly + <antrik> yes, but a translated entry normally would be served by *another* + process?... + <youpi> sure, but ext2fs has to prepare it + <youpi> thus reauthenticate to prepare the correct set of rights + <antrik> prepare what? + <youpi> rights + <youpi> so the process is not root, doesn't have / opened as root, etc. + <antrik> rights for what? + <youpi> err, about everything + <antrik> IIRC the reauthentication is done by the parent FS on the port to + the *translated* node + <antrik> and the translated node should be a different process?... + <youpi> that's not what I read in the source + <youpi> fshelp_fetch_root + <youpi> ports[INIT_PORT_CRDIR] = reauth (getcrdir ()); + <youpi> here, getcrdir() returns ext2fs itself + <antrik> well, perhaps the issue is that I have no idea what + fshelp_fetch_root() does, nor why it is called here... + <youpi> it notably starts the translator that dir_lookup is looking at, if + needed + <youpi> possibly as a different user, thus reauthentication of CRDIR + <antrik> so this is about a port that is passed to the translator being + started? + <youpi> no + <youpi> well, depends on what you mean by "port" + <youpi> it's about reauthenticating a port to be passed to the translator + being started + <youpi> and for that a rendez-vous port is needed for the reauthentication + <youpi> and that's the one at stake + <antrik> yeah, I meant the port that is reauthenticated + <antrik> what is CRDIR? + <youpi> current root dir ... + <antrik> so the parent translator passes it's own root dir to the child + translator; and the issue is that for the root FS the root dir points to + the root FS itself... + <youpi> yes + <antrik> OK, that makes sense + <youpi> (but that's only one example, rgrep mach_port_destroy hurd/ show + other potential issues) + <antrik> well, that's actually what I wanted to mention next... why is the + rendez-vous port destroyed, instead of just deallocating the port right + and letting reference counting to it's thing?... + <antrik> do its thing + <youpi> "just to make sure" I guess + <antrik> it's pretty obvious that this will cause trouble for any RPC + referencing itself... + <youpi> well, follow-up with that on the list + <youpi> with roland/tb in CC + <youpi> only they would know any real reason for destroy + <youpi> btw, if you knew how we could make _hurd_select()'s raw __mach_msg + call be interruptible by signals, that'll permit to fix sudo + <youpi> (damn, I need sleep, my tenses are all wrong) + <antrik> BTW, does this cause any actual trouble?... + <antrik> I don't know much about interruption... cfhammer might have a + better idea, he look into that stuff quite a bit AIUI + <antrik> looked + <antrik> (hehe, it's not only your tenses... guess there's something in the + ether ;-) ) + <youpi> it makes sudo, mailq, etc. fail sometimes + <antrik> I mean the rendez-vous thing + <youpi> that's it, yes + <youpi> sudo etc. fail at least due to this + <antrik> so these are two different problems that both affect sudo? + <antrik> (rendez-vous and interruption I mean) + <youpi> yes + <youpi> with my patch the buildds have much fewer issues, but still some + <youpi> (my interrupt-related patch) + <youpi> I'm installing a s/destroy/deallocate/ version of ext2fs on the + buildds, we'll see how it behaves + <youpi> (it fixes my testcase at least) + <antrik> interrupt-related patch? + <antrik> only thing interrupt-related I remember was the reauthentication + race... + <youpi> that's what I mean + <antrik> well, cfhammer investigated this is quite some depth, explaining + quite well why the race is only mitigated but still exists... problem is + that we didn't know how to fix it properly + <antrik> because nobody seems to understand the cancellation code, except + perhaps for Roland and Thomas + <antrik> (and I'm not even entirely sure about them :-) ) + <antrik> I think his findings and our conclusions are documented on the + ML... + <youpi> by "much fewer issues", I mean that some of the symptoms have + disappeared, others haven't + <antrik> BTW, couldn't the rendez-vous thing be worked around by simply + ignoring the errors from the failing deallocate?... + <youpi> no, failing deallocate are actually dangerous + <antrik> why? + <youpi> since the name might have been reused for something else in the + meanwhile + <youpi> that's the whole point of the warning I had added in the kernel + itself + <antrik> I see + <youpi> such things really deserve tracking, since they can have any kind + of consequence + <antrik> does Mach try to reuse names quickly, rather than only after + wrapping around?... + <youpi> it seems to + <antrik> OK, then this is a serious problem indeed + <youpi> (note: I rarely divine issues when there aren't actual frequent + symptoms :) ) + <antrik> well, the problem with the warning is that it only shows in the + cases that do *not* cause a problem... so it's hard to associate them + with any specific issues + <youpi> well, most of the time the port is not reused quickly enough + <youpi> so in most case it shows up more often than causing problem + +IRC, freenode, #hurd, 2011-03-14 + + <youpi> ok, mach_port_deallocate actually can't be used + <youpi> since mach_reply_port() returns a receive right, not a send right + * youpi guesses he will really have to manage to understand all that port + stuff completely + <antrik> oh, right + <antrik> youpi: hm... now I'm confused though. if one client holds a + receive right, the other client (or in this case the same process) should + have a send or send-once right -- these should *not* share the same name + in my understanding + <antrik> destroying the receive right should turn the send right into a + dead name + <antrik> so unless I'm missing something, the destroy shouldn't be a + problem, and there must be something else going wrong + <antrik> hm... actually I'm probably wrong + <antrik> yeah, definitely wrong. receive rights and "ordinary" send rights + share the name. only send-once rights are special + <antrik> I wonder whether the problem could be worked around by using a + send-once right... + <antrik> mach_port_mod_refs(mach_task_self(), name, + MACH_PORT_RIGHT_RECEIVE, -1) can be used to deallocate only the receive + right + <antrik> oh, you already figured that out :-) diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index c7a0962c..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]] @@ -17,3 +18,33 @@ report is just from his memory, and his memory is dim... The problem *might* either be a time stamping issue (which might be fixed by now) or it *might* be the `select` call failing issue we're seeing from time to time. Or something else. + +[[Harish Badrinath|harishbadrinath]] +Originally answered by Samuel Thibault: +> 120->proc_dostop_request ( 138) = 0 +> +> </snip> + +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); + +So it simply looks like the known "signals don't interrupt select" bug. diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn new file mode 100644 index 00000000..4e1fa849 --- /dev/null +++ b/open_issues/sa_siginfo_sa_sigaction.mdwn @@ -0,0 +1,96 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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="SA_SIGINFO, SA_SIGACTION"]] + +[[!tag open_issue_glibc]] + +Note: SA_SIGINFO has now been implemented by Jérémie Koenig. It will be +uploaded in Debian eglibc 2.13-19. + +IRC, #hurd, August / September 2010: + + <giselher> Hy, I came across SA_SIGINFO in cherokee, I have the void sighandler(int num) prototype but how do I add the sa_handler field? + <pinotree> if SA_SIGACTION is not defined, then you use sa_handler instead of sa_sigaction, and not add SA_SIGINFO in the sa_flags + <giselher> SA_SIGINFO is not defined + <pinotree> s/SA_SIGACTION/SA_SIGINFO/ above, yes + <giselher> K + <giselher> I am not sure if I fully understand this, there is the line "act.sa_flags = SA_SIGINFO" and how do I have to change that >_> + <pinotree> can you paste the source in a pastebin? + <giselher> k + <giselher> http://archhurd.pastebin.com/N8BCnG6g at line 790 + <pinotree> something along the lines of http://www.archhurd.pastebin.com/tdpcFD5G + <pinotree> note that in the handler the siginfo_t parameter is used, which cannot be done if SA_SIGINFO is not defined + <pinotree> (that code still won't compile, yet) + <giselher> btw: is there a reason why SA_SIGINFO is not implemented? + <giselher> the guildlines only say "It's not implemented" + <azeem> 09:43 < azeem> signal stuff is tricky :-/ + <azeem> basically it was pending on a complete rewrite by Roland, which never occured + <youpi> I have an almost complete implementation, just not finished yet + <youpi> (only the siginfo part) + <azeem> nobody really groked that code for years until youpi showed up, but he added partial support AFAIK, not having much time on his hand + <azeem> ah, he's here + <azeem> :) + <giselher> oh, should I just wait ? + <youpi> no + <giselher> k + <youpi> there are OSes which don't have SA_SIGINFO + <youpi> just cope with them: use sa_handler instead of sa_sigaction, and don't set SA_SIGINFO + <youpi> (i.e. replace with 0 in your example) + <giselher> ok + <youpi> when SA_SIGINFO becomes available, it'll just be used + +IRC, freenode, #hurd, 2011-08-20: + + < youpi> erf, tcpwrappers will need si_pid + < jkoenig> I could implement it not too far away in the future, we just + need a version of msg_sig_post() with a siginfo argument or something. + < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... + < youpi> (probably copy/pasty code) + < youpi> sa.sa_flags = SA_SIGINFO; + < youpi> sa.sa_handler = parse_config; + < youpi> void parse_config(int) + < youpi> yay + < youpi> if(siginf->si_signo == SIGXCPU) + < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); + < youpi> ... + < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO + they request... + < youpi> jkoenig: si_pid should get us almost all actually used coverage + < youpi> I've seen only one example using si_errno + < jkoenig> ok + < youpi> oh, it's actually supported by your patch + < youpi> (errno) + < jkoenig> but I guess since implementing si_pid will require a new RPC, we + might as well plan for the rest + < youpi> jkoenig: indeed + < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? + < youpi> ok, well, we'll see + < pinotree> jkoenig: if it can be of help, boost::unit_test queries various + fields of siginfo_t depending on the signal + < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting + memory on SIGBUS + < jkoenig> pinotree, oh ok good to know + < pinotree> *faulty + < youpi> jkoenig: well, I guess you had checked that the si_addr field is + correct in a few simple testcase :) + < jkoenig> hmm I think so, yes + < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC + < youpi> ok + < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV + depending on the upper bit, or something (I can't quite remember) + < jkoenig> but when sigsegv was generated si_addr was right. + < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost + sources) + < pinotree> maybe you can try the unit tests for boost::unit_tests, if any + :) + < pinotree> (while src/pulsecore/memtrap.c in PA) + * pinotree stops doing MrObvious™ diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn new file mode 100644 index 00000000..4bbf92ef --- /dev/null +++ b/open_issues/sbcl.mdwn @@ -0,0 +1,31 @@ +[[!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_porting]] + +IRC, freenode, #hurd, 2011-08-12 + + < zyg> did the segment registers had any purpose? I see fs is set equal to + others, but on linux fs is 0 (atleast on this x86 box). + < braunr> zyg: it can be used by special applications like wine, yes + < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can + be used for TLS, fs in syscall to pass userspace. + < braunr> zyg: why are you interested in that ? + < zyg> a native compiler under linux places assumptions on fs register. So + I'm trying to find out what it should do under gnumach/hurd. + < braunr> what compiler ? + < zyg> braunr: it's sbcl + < braunr> ok + < youpi> zyg: the same, basically + < zyg> ok.. looking at the code, I've remarked where it sets up FS, because + /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the + equiv. + < youpi> zyg: mach/i386/mach_i386.h + < youpi> the descriptor structure diff --git a/open_issues/screen.mdwn b/open_issues/screen.mdwn new file mode 100644 index 00000000..e0394f0d --- /dev/null +++ b/open_issues/screen.mdwn @@ -0,0 +1,120 @@ +[[!meta copyright="Copyright © 2009, 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_porting]] + +Typing `C-c` (*SIGINT*) in a *screen* session (Debian package 4.0.3-14; -11 is +fine): + + * shell prompt: no reaction (nothing printed) + * `sleep 10` running: `^C` printed, but SIGINT is not sent. + +[[!debbug 522689#38]]. + +--- + +Revisit this issue: [[!debbug 97343]] -- special handling of `TIOCSCTTY` +depending on `__GNU__`. + +--- + +`#ifdef linux` and friends are used in quite a number of places. + +--- + +All diffs are GNU/Linux vs. GNU/Hurd. + + /* + * If your system supports BSD4.4's seteuid() and setegid(), define + * HAVE_SETEUID. + */ + -/* #undef HAVE_SETEUID */ + +#define HAVE_SETEUID 1 + +TODO: check. + +--- + + /* + * define HAVE_SVR4_PTYS if you have a /dev/ptmx character special + * device and support the ptsname(), grantpt(), unlockpt() functions. + */ + -#define HAVE_SVR4_PTYS 1 + +/* #undef HAVE_SVR4_PTYS */ + + /* + * define HAVE_GETPT if you have the getpt() function. + */ + #define HAVE_GETPT 1 + + /* + * define HAVE_OPENPTY if your system has the openpty() call. + */ + -/* #undef HAVE_OPENPTY */ + +#define HAVE_OPENPTY 1 + + /* + * define PTYRANGE0 and or PTYRANGE1 if you want to adapt screen + * to unusual environments. E.g. For SunOs the defaults are "qpr" and + * "0123456789abcdef". For SunOs 4.1.2 + * #define PTYRANGE0 "pqrstuvwxyzPQRST" + * is recommended by Dan Jacobson. + */ + -/* #undef PTYRANGE0 */ + -/* #undef PTYRANGE1 */ + +#define PTYRANGE0 "pq" + +#define PTYRANGE1 "0123456789abcdefghijklmnopqrstuv" + +TODO: check: `HAVE_SVR4_PTYS` is due to `configure.in` doing `test -c +/dev/ptmx`. But: even if we don't have that file, we still have `ptsname`, +`grantpt`, `unlockpt`. + +--- + + gcc -c -I. -I. -g -O2 -O2 -g -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers pty.c + +pty.c: In function 'OpenPTY': + +pty.c:323: warning: implicit declaration of function 'openpty' + +pty.c: At top level: + +pty.c:75: warning: 'PtyName' defined but not used + +pty.c:86: warning: 'PtyProto' defined but not used + +pty.c:87: warning: 'TtyProto' defined but not used + +TODO: check. + +--- + + --- linux/osdef.h 2009-10-06 18:43:53.000000000 +0200 + +++ screen-4.0.3/osdef.h 2009-10-06 18:49:49.000000000 +0200 + @@ -42,13 +42,19 @@ + #endif + + #ifdef SYSV + +extern char *strchr __P((char *, int)); + +extern char *strrchr __P((char *, int)); + +extern char *memset __P((char *, int, int)); + +extern int memcmp __P((char *, char *, int)); + #else + #endif + + #ifndef USEBCOPY + # ifdef USEMEMCPY + +extern void memcpy __P((char *, char *, int)); + # else + # ifdef USEMEMMOVE + +extern void memmove __P((char *, char *, int)); + # else + # endif + # endif + +TODO: check. + +--- + + * [[screen_dead_session]] diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn new file mode 100644 index 00000000..fe51523b --- /dev/null +++ b/open_issues/screen_dead_session.mdwn @@ -0,0 +1,69 @@ +[[!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 +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_porting]] + +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. + +[[!toc]] + + +# One reproducible scenario goes like this + + * `ssh [somewhere]`, + + * start a *screen* session, and some long-running process *P* in there, + + * at some point the link is forcefully terminated (also known as disconnect + after 24 hours with consumer DSL), + + * *P* will continue to execute, + + * 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 + + * `ssh [somewhere]`, + + * start a *screen* session, and some long-running process *P* in there, + + * at some point the link is forcefully terminated (also known as disconnect + after 24 hours with consumer DSL), + + * `ssh [somewhere]`, + + * `screen -x`, and notice that *P* will *immediatelly* terminate / hang + (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/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn new file mode 100644 index 00000000..45e983a7 --- /dev/null +++ b/open_issues/secure_file_descriptor_handling.mdwn @@ -0,0 +1,24 @@ +[[!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 +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]] + +`O_CLOEXEC`, `dup3` et al.; see +<http://udrepper.livejournal.com/20407.html>. [[tschwinge]] once worked +on this, posted patches to [[mailing_lists/libc-alpha]]. This works needs to +be resumed +and finished. + +--- + +In <http://lwn.net/Articles/417421/> an interesting point is made: *you [may] +want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you +don't want it to be open after the exec succeeds*. [[I|tschwinge]]'m not sure +whether our current `O_CLOEXEC` implementation adheres to that. diff --git a/open_issues/security.mdwn b/open_issues/security.mdwn new file mode 100644 index 00000000..055c8bdc --- /dev/null +++ b/open_issues/security.mdwn @@ -0,0 +1,34 @@ +[[!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]]."]]"""]] + +There are [[several aspects to security|/security]] that are (mainly) relevant +to the design space. + +There are also security issues in the implemenation space, for example using +the correct coding paradigms. + +Large parts of our code base have not beed audited, either manually or in an +automated fashion. + +[[Unit testing]] is one aspect: testing for reliably failing for invalid input. + +[[Code analysis]] is another aspect. + +All publically usable interfaces provide attacking targets. This includes all +[[system call]]s and [[RPC]] interfaces. + +Fuzzing techniques can be use for locating possible issues. + + * <http://lwn.net/Articles/414273/> + + * Has already been used in the 70s / 80s (?) for testing [[UNIX]] command + line tools. + + * <http://www.ece.cmu.edu/~koopman/ballista/> diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn new file mode 100644 index 00000000..778af530 --- /dev/null +++ b/open_issues/select.mdwn @@ -0,0 +1,1636 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]] + +There are a lot of reports about this issue, but no thorough analysis. + + +# Short Timeouts + +## `elinks` + +IRC, unknown channel, unknown date: + + <paakku> This is related to ELinks... I've looked at the select() + implementation for the Hurd in glibc and it seems that giving it a short + timeout could cause it not to report that file descriptors are ready. + <paakku> It sends a request to the Mach port of each file descriptor and + then waits for responses from the servers. + <paakku> Even if the file descriptors have data for reading or are ready + for writing, the server processes might not respond immediately. + <paakku> So if I want ELinks to check which file descriptors are ready, how + long should the timeout be in order to ensure that all servers can + respond in time? + <paakku> Or do I just imagine this problem? + + +## [[dbus]] + + +## IRC + +### IRC, freenode, #hurd, 2012-01-31 + + <braunr> don't you find vim extremely slow lately ? + <braunr> (and not because of cpu usage but rather unnecessary sleeps) + <jkoenig> yes. + <braunr> wasn't there a discussion to add a minimum timeout to mach_msg for + select() or something like that during the past months ? + <youpi> there was, and it was added + <youpi> that could be it + <youpi> I don't want to drop it though, some app really need it + <braunr> as a debian patch only iirc ? + <youpi> yes + <braunr> ok + <braunr> if i'm right, the proper solution was to fix remote servers + instead of client calls + <youpi> (no drop, unless the actual bug gets fixed of course) + <braunr> so i'm guessing it's just a hack in between + <youpi> not only + <youpi> with a timeout of zero, mach will just give *no* time for the + servers to give an answer + <braunr> that's because the timeout is part of the client call + <youpi> so the protocol has to be rethought, both server/client side + <braunr> a suggested solution was to make it a parameter + <braunr> i mean, part of the message + <braunr> not a mach_msg parameter + <jkoenig> OTOH the servers should probably not be trusted to enforce the + timeout. + <braunr> why ? + <jkoenig> they're not necessarily trusted. (but then again, that's not the + only circumstances where that's a problem) + <braunr> there is a proposed solution for that too (trust root and self + servers only by default) + <jkoenig> I'm not sure they're particularily easy to identify in the + general case + <braunr> "they" ? the solutions you mean ? + <braunr> or the servers ? + <youpi> jkoenig: you can't trust the servers in general to provide an + answer, timeout or not + <jkoenig> yes the root/self servers. + <braunr> ah + <youpi> jkoenig: you can stat the actual node before dereferencing the + translator + <jkoenig> could they not report FD activity asynchronously to the message + port? libc would cache the state + <youpi> I don't understand what you mean + <youpi> anyway, really making the timeout part of the message is not a + problem + <braunr> 10:10 < youpi> jkoenig: you can't trust the servers in general to + provide an answer, timeout or not + <youpi> we already trust everything (e.g. read() ) into providing an answer + immediately + <braunr> i don't see why + <youpi> braunr: put sleep(1) in S_io_read() + <youpi> it'll not give you an immediate answer, O_NODELAY being set or not + <braunr> well sleep is evil, but let's just say the server thread blocks + <braunr> ok + <braunr> well fix the server + <youpi> so we agree + <braunr> ? + <youpi> in the current security model, we trust the server into achieve the + timeout + <braunr> yes + <youpi> and jkoenig's remark is more global than just select() + <braunr> taht's why we must make sure we're contacting trusted servers by + default + <youpi> it affects read() too + <braunr> sure + <youpi> so there's no reason not to fix select() + <youpi> that's the important point + <braunr> but this doesn't mean we shouldn't pass the timeout to the server + and expect it to handle it correctly + <youpi> we keep raising issues with things, and not achieve anything, in + the Hurd + <braunr> if it doesn't, then it's a bug, like in any other kernel type + <youpi> I'm not the one to convince :) + <braunr> eh, some would say it's one of the goals :) + <braunr> who's to be convinced then ? + <youpi> jkoenig: + <youpi> who raised the issue + <braunr> ah + <youpi> well, see the irc log :) + <jkoenig> not that I'm objecting to any patch, mind you :-) + <braunr> i didn't understand it that way + <braunr> if you can't trust the servers to act properly, it's similar to + not trusting linux fs code + <youpi> no, the difference is that servers can be non-root + <youpi> while on linux they can't + <braunr> again, trust root and self + <youpi> non-root fuse mounts are not followed by default + <braunr> as with fuse + <youpi> that's still to be written + <braunr> yes + <youpi> and as I said, you can stat the actual node and then dereference + the translator afterwards + <braunr> but before writing anything, we'd better agree on the solution :) + <youpi> which, again, "just" needs to be written + <antrik> err... adding a timeout to mach_msg()? that's just wrong + <antrik> (unless I completely misunderstood what this discussion was + about...) + + +#### IRC, freenode, #hurd, 2012-02-04 + + <youpi> this is confirmed: the select hack patch hurts vim performance a + lot + <youpi> I'll use program_invocation_short_name to make the patch even more + ugly + <youpi> (of course, we really need to fix select somehow) + <pinotree> could it (also) be that vim uses select() somehow "badly"? + <youpi> fsvo "badly", possibly, but still + <gnu_srs1> Could that the select() stuff be the reason for a ten times + slower ethernet too, e.g. scp and apt-get? + <pinotree> i didn't find myself neither scp nor apt-get slower, unlike vim + <youpi> see strace: scp does not use select + <youpi> (I haven't checked apt yet) + + +### IRC, freenode, #hurd, 2012-02-14 + + <braunr> on another subject, I'm wondering how to correctly implement + select/poll with a timeout on a multiserver system :/ + <braunr> i guess a timeout of 0 should imply a non blocking round-trip to + servers only + <braunr> oh good, the timeout is already part of the io_select call + + +### IRC, freenode, #hurdfr, 2012-02-22 + + <braunr> le gros souci de notre implé, c'est que le timeout de select est + un paramètre client + <braunr> un paramètre passé directement à mach_msg + <braunr> donc si tu mets un timeout à 0, y a de fortes chances que mach_msg + retourne avant même qu'un RPC puisse se faire entièrement (round-trip + client-serveur donc) + <braunr> et donc quand le timeout est à 0 pour du non bloquant, ben tu + bloques pas, mais t'as pas tes évènements .. + <abique|work> peut-être que passer le timeout de 10ms à 10 us améliorerait + la situation. + <abique|work> car 10ms c'est un peut beaucoup :) + <braunr> c'est l'interval timer système historique unix + <braunr> et mach n'est pas préemptible + <braunr> donc c'est pas envisageable en l'état + <braunr> ceci dit c'est pas complètement lié + <braunr> enfin si, il nous faudrait qqchose de similaire aux high res + timers de linux + <braunr> enfin soit des timer haute résolution, soit un timer programmable + facilement + <braunr> actuellement il n'y a que le 8254 qui est programmé, et pour + assurer un scheduling à peu près correct, il est programmé une fois, à + 10ms, et basta + <braunr> donc oui, préciser 1ms ou 1us, ça changera rien à l'interval + nécessaire pour déterminer que le timer a expiré + + +### IRC, freenode, #hurd, 2012-02-27 + + <youpi> braunr: extremely dirty hack + <youpi> I don't even want to detail :) + <braunr> oh + <braunr> does it affect vim only ? + <braunr> or all select users ? + <youpi> we've mostly seen it with vim + <youpi> but possibly fakeroot has some issues too + <youpi> it's very little probable that only vim has the issue :) + <braunr> i mean, is it that dirty to switch behaviour depending on the + calling program ? + <youpi> not all select users + <braunr> ew :) + <youpi> just those which do select({0,0}) + <braunr> well sure + <youpi> braunr: you guessed right :) + <braunr> thanks anyway + <braunr> it's probably a good thing to do currently + <braunr> vim was getting me so mad i was using sshfs lately + <youpi> it's better than nothing yes + + +# IRC, freenode, #hurd, 2012-07-21 + + <braunr> damn, select is actually completely misdesigned :/ + <braunr> iiuc, it makes servers *block*, in turn :/ + <braunr> can't be right + <braunr> ok i understand it better + <braunr> yes, timeouts should be passed along with the other parameters to + correctly implement non blocking select + <braunr> (or the round-trip io_select should only ask for notification + requests instead of making a server thread block, but this would require + even more work) + <braunr> adding the timeout in the io_select call should be easy enough for + whoever wants to take over a not-too-complicated-but-not-one-liner-either + task :) + <antrik> braunr: why is a blocking server thread a problem? + <braunr> antrik: handling the timeout at client side while server threads + block is the problem + <braunr> the timeout must be handled along with blocking obviously + <braunr> so you either do it at server side when async ipc is available, + which is the case here + <braunr> or request notifications (synchronously) and block at client side, + waiting forthose notifications + <antrik> braunr: are you saying the client has a receive timeout, but when + it elapses, the server thread keeps on blocking?... + <braunr> antrik: no i'm referring to the non-blocking select issue we have + <braunr> antrik: the client doesn't block in this case, whereas the servers + do + <braunr> which obviously doesn't work .. + <braunr> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358 + <braunr> this is the reason why vim (and probably others) are slow on the + hurd, while not consuming any cpu + <braunr> the current work around is that whenevever a non-blocking select + is done, it's transformed into a blocking select with the smallest + possible timeout + <braunr> whenever* + <antrik> braunr: well, note that the issue only began after fixing some + other select issue... it was fine before + <braunr> apparently, the issue was raised in 2000 + <braunr> also, note that there is a delay between sending the io_select + requests and blocking on the replies + <braunr> when machines were slow, this delay could almost guarantee a + preemption between these steps, making the servers reply soon enough even + for a non blocking select + <braunr> the problem occurs when sending all the requests and checking for + replies is done before servers have a chance the send the reply + <antrik> braunr: I don't know what issue was raised in 2000, but I do know + that vim worked perfectly fine until last year or so. then some select + fix was introduced, which in turn broke vim + <braunr> antrik: could be the timeout rounding, Aug 2 2010 + <braunr> hum but, the problem wasn't with vim + <braunr> vim does still work fine (in fact, glibc is patched to check some + well known process names and selectively fix the timeout) + <braunr> which is why vim is fast and view isn't + <braunr> the problem was with other services apparently + <braunr> and in order to fix them, that workaround had to be introduced + <braunr> i think it has nothing to do with the timeout rounding + <braunr> it must be the time when youpi added the patch to the debian + package + <antrik> braunr: the problem is that with the patch changing the timeout + rounding, vim got extremely slow. this is why the ugly hacky exception + was added later... + <antrik> after reading the report, I agree that the timeout needs to be + handled by the server. at least the timeout=0 case. + <pinotree> vim uses often 0-time selects to check whether there's input + <antrik> client-side handling might still be OK for other timeout settings + I guess + <antrik> I'm a bit ambivalent about that + <antrik> I tend to agree with Neal though: it really doesn't make much + sense to have a client-side watchdog timer for this specific call, while + for all other ones we trust the servers not to block... + <antrik> or perhaps not. for standard sync I/O, clients should expect that + an operation could take long (though not forever); but they might use + select() precisely to avoid long delays in I/O... so it makes some sense + to make sure that select() really doesn't delay because of a busy server + <antrik> OTOH, unless the server is actually broken (in which anything + could happen), a 0-time select should never actually block for an + extended period of time... I guess it's not wrong to trust the servers on + that + <antrik> pinotree: hm... that might explain a certain issue I *was* + observing with Vim on Hurd -- though I never really thought about it + being an actual bug, as opposed to just general Hurd sluggishness... + <antrik> but it makes sense now + <pinotree> antrik: + http://patch-tracker.debian.org/patch/series/view/eglibc/2.13-34/hurd-i386/local-select.diff + <antrik> so I guess we all agree that moving the select timeout to the + server is probably the most reasonably approach... + <antrik> braunr: BTW, I wouldn't really consider the sync vs. async IPC + cases any different. the client blocks waiting for the server to reply + either way... + <antrik> the only difference is that in the sync IPC case, the server might + want to take some special precaution so it doesn't have to block until + the client is ready to receive the reply + <antrik> but that's optional and not really select-specific I'd say + <antrik> (I'd say the only sane approach with sync IPC is probably for the + server never to wait -- if the client fails to set up for receiving the + reply in time, it looses...) + <antrik> and with the receive buffer approach in Viengoos, this can be done + really easy and nice :-) + + +## IRC, freenode, #hurd, 2012-07-22 + + <braunr> antrik: you can't block in servers with sync ipc + <braunr> so in this case, "select" becomes a request for notifications + <braunr> whereas with async ipc, you can, so it's less efficient to make a + full round trip just to ask for requests when you can just do async + requests (doing the actual blocking) and wait for any reply after + <antrik> braunr: I don't understand. why can't you block in servers with + async IPC? + <antrik> braunr: err... with sync IPC I mean + <braunr> antrik: because select operates on more than one fd + <antrik> braunr: and what does that got to do with sync vs. async IPC?... + <antrik> maybe you are thinking of endpoints here, which is a whole + different story + <antrik> traditional L4 has IPC ports bound to specific threads; so + implementing select requires a separate client thread for each + server. but that's not mandatory for sync IPC. Viengoos has endpoints not + bound to threads + <braunr> antrik: i don't know what "endpoint" means here + <braunr> but, you can't use sync IPC to implement select on multiple fds + (and thus possibly multiple servers) by blocking in the servers + <braunr> you'd block in the first and completely miss the others + <antrik> braunr: I still don't see why... or why async IPC would change + anything in that regard + <braunr> antrik: well, you call select on 3 fds, each implemented by + different servers + <braunr> antrik: you call a sync select on the first fd, obviously you'll + block there + <braunr> antrik: if it's async, you don't block, you just send the + requests, and wait for any reply + <braunr> like we do + <antrik> braunr: I think you might be confused about the meaning of sync + IPC. it doesn't in any way imply that after sending an RPC request you + have to block on some particular reply... + <youpi> antrik: what does sync mean then? + <antrik> braunr: you can have any number of threads listening for replies + from the various servers (if using an L4-like model); or even a single + thread, if you have endpoints that can listen on replies from different + sources (which was pretty much the central concern in the Viengoos IPC + design AIUI) + <youpi> antrik: I agree with your "so it makes some sense to make sure that + select() really doesn't delay because of a busy server" (for blocking + select) and "OTOH, unless the server is actually broken (in which + anything could happen), a 0-time select should never actually block" (for + non-blocking select) + <antrik> youpi: regarding the select, I was thinking out loud; the former + statement was mostly cancelled by my later conclusions... + <antrik> and I'm not sure the latter statement was quite clear + <youpi> do you know when it was? + <antrik> after rethinking it, I finally concluded that it's probably *not* + a problem to rely on the server to observe the timout. if it's really + busy, it might take longer than the designated timeout (especially if + timeout is 0, hehe) -- but I don't think this is a problem + <antrik> and if it doens't observe the timout because it's + broken/malicious, that's not more problematic that any other RPC the + server doesn't handle as expected + <youpi> ok + <youpi> did somebody wrote down the conclusion "let's make select timeout + handled at server side" somewhere? + <antrik> youpi: well, neal already said that in a followup to the select + issue Debian bug... and after some consideration, I completely agree with + his reasoning (as does braunr) + + +## IRC, freenode, #hurd, 2012-07-23 + + <braunr> antrik: i was meaning sync in the most common meaning, yes, the + client blocking on the reply + <antrik> braunr: I think you are confusing sync IPC with sync I/O ;-) + <antrik> braunr: by that definition, the vast majority of Hurd IPC would be + sync... but that's obviously not the case + <antrik> synchronous IPC means that send and receive happen at the same + time -- nothing more, nothing less. that's why it's called synchronous + <braunr> antrik: yes + <braunr> antrik: so it means the client can't continue unless he actually + receives + <antrik> in a pure sync model such as L4 or EROS, this means either the + sender or the receiver has to block, so synchronisation can happen. which + one is server and which one is client is completely irrelevant here -- + this is about individual message transfer, not any RPC model on top of it + <braunr> i the case of select, i assume sender == client + <antrik> in Viengoos, the IPC is synchronous in the sense that transfer + from the send buffer to the receive buffer happens at the same time; but + it's asynchronous in the sense that the receiver doesn't necessarily have + to be actively waiting for the incoming message + <braunr> ok, i was talking about a pure sync model + <antrik> (though it most cases it will still do so...) + <antrik> braunr: BTW, in the case of select, the sender is *not* the + client. the reply is relevant here, not the request -- so the client is + the receiver + <antrik> (the select request is boring) + <braunr> sorry, i don't understand, you seem to dismiss the select request + for no valid reason + <antrik> I still don't see how sync vs. async affects the select reply + receive though... blocking seems the right approach in either case + <braunr> blocking is required + <braunr> but you either block in the servers, or in the client + <braunr> (and if blocking in the servers, the client also blocks) + <braunr> i'll explain how i see it again + <braunr> there are two approaches to implementing select + <braunr> 1/ send requests to all servers, wait for any reply, this is what + the hurd does + <braunr> but it's possible because you can send all the requests without + waiting for the replies + <braunr> 2/ send notification requests, wait for a notification + <braunr> this doesn't require blocking in the servers (so if you have many + clients, you don't need as many threads) + <braunr> i was wondering which approach was used by the hurd, and if it + made sense to change + <antrik> TBH I don't see the difference between 1) and 2)... whether the + message from the server is called an RPC reply or a notification is just + a matter of definition + <antrik> I think I see though what you are getting at + <antrik> with sync IPC, if the client sent all requests and only afterwards + started to listen for replies, the servers might need to block while + trying to deliver the reply because the client is not ready yet + <braunr> that's one thing yes + <antrik> but even in the sync case, the client can immediately wait for + replies to each individual request -- it might just be more complicated, + depending on the specifics of the IPC design + <braunr> what i mean by "send notification requests" is actually more than + just sending, it's a complete RPC + <braunr> and notifications are non-blocking, yes + <antrik> (with L4, it would require a separate client thread for each + server contacted... which is precisely why a different mechanism was + designed for Viengoos) + <braunr> seems weird though + <braunr> don't they have a portset like abstraction ? + <antrik> braunr: well, having an immediate reply to the request and a + separate notification later is just a waste of resources... the immediate + reply would have no information value + <antrik> no, in original L4 IPC is always directed to specific threads + <braunr> antrik: some could see the waste of resource as being the + duplication of the number of client threads in the server + <antrik> you could have one thread listening to replies from several + servers -- but then, replies can get lost + <braunr> i see + <antrik> (or the servers have to block on the reply) + <braunr> so, there are really no capabilities in the original l4 design ? + <antrik> though I guess in the case of select() it wouldn't really matter + if replies get lost, as long as at least one is handled... would just + require the listener thread by separate from the thread sending the + requests + <antrik> braunr: right. no capabilities of any kind + <braunr> that was my initial understanding too + <braunr> thanks + <antrik> so I partially agree: in a purely sync IPC design, it would be + more complicated (but not impossible) to make sure the client gets the + replies without the server having to block while sending replies + + <braunr> arg, we need hurd_condition_timedwait (and possible + condition_timedwait) to cleanly fix io_select + <braunr> luckily, i still have my old patch for condition_timedwait :> + <braunr> bddebian: in order to implement timeouts in select calls, servers + now have to use a hurd_condition_timedwait function + <braunr> is it possible that a thread both gets canceled and timeout on a + wait ? + <braunr> looks unlikely to me + + <braunr> hm, i guess the same kind of compatibility constraints exist for + hurd interfaces + <braunr> so, should we have an io_select1 ? + <antrik> braunr: I would use a more descriptive name: io_select_timeout() + <braunr> antrik: ah yes + <braunr> well, i don't really like the idea of having 2 interfaces for the + same call :) + <braunr> because all select should be select_timeout :) + <braunr> but ok + <braunr> antrik: actually, having two select calls may be better + <braunr> oh it's really minor, we do'nt care actually + <antrik> braunr: two select calls? + <braunr> antrik: one with a timeout and one without + <braunr> the glibc would choose at runtime + <antrik> right. that was the idea. like with most transitions, that's + probably the best option + <braunr> there is no need to pass the timeout value if it's not needed, and + it's easier to pass NULL this way + <antrik> oh + <antrik> nah, that would make the transition more complicated I think + <braunr> ? + <braunr> ok + <braunr> :) + <braunr> this way, it becomes very easy + <braunr> the existing io_select call moves into a select_common() function + <antrik> the old variant doesn't know that the server has to return + immediately; changing that would be tricky. better just use the new + variant for the new behaviour, and deprecate the old one + <braunr> and the entry points just call this common function with either + NULL or the given timeout + <braunr> no need to deprecate the old one + <braunr> that's what i'm saying + <braunr> and i don't understand "the old variant doesn't know that the + server has to return immediately" + <antrik> won't the old variant block indefinitely in the server if there + are no ready fds? + <braunr> yes it will + <antrik> oh, you mean using the old variant if there is no timeout value? + <braunr> yes + <antrik> well, I guess this would work + <braunr> well of course, the question is rather if we want this or not :) + <antrik> hm... not sure + <braunr> we need something to improve the process of changing our + interfaces + <braunr> it's really painful currnelty + <antrik> inside the servers, we probably want to use common code + anyways... so in the long run, I think it simplifies the code when we can + just drop the old variant at some point + <braunr> a lot of the work we need to do involves changing interfaces, and + we very often get to the point where we don't know how to do that and + hardly agree on a final version : + <braunr> :/ + <braunr> ok but + <braunr> how do you tell the server you don't want a timeout ? + <braunr> a special value ? like { -1; -1 } ? + <antrik> hm... good point + <braunr> i'll do it that way for now + <braunr> it's the best way to test it + <antrik> which way you mean now? + <braunr> keeping io_select as it is, add io_select_timeout + <antrik> yeah, I thought we agreed on that part... the question is just + whether io_select_timeout should also handle the no-timeout variant going + forward, or keep io_select for that. I'm really not sure + <antrik> maybe I'll form an opinion over time :-) + <antrik> but right now I'm undecided + <braunr> i say we keep io_select + <braunr> anyway it won't change much + <braunr> we can just change that at the end if we decide otherwise + <antrik> right + <braunr> even passing special values is ok + <braunr> with a carefully written hurd_condition_timedwait, it's very easy + to add the timeouts :) + <youpi> antrik, braunr: I'm wondering, another solution is to add an + io_probe, i.e. the server has to return an immediate result, and the + client then just waits for all results, without timeout + <youpi> that'd be a mere addition in the glibc select() call: when timeout + is 0, use that, and otherwise use the previous code + <youpi> the good point is that it looks nicer in fs.defs + <youpi> are there bad points? + <youpi> (I don't have the whole issues in the mind now, so I'm probably + missing things) + <braunr> youpi: the bad point is duplicating the implementation maybe + <youpi> what duplication ? + <youpi> ah you mean for the select case + <braunr> yes + <braunr> although it would be pretty much the same + <braunr> that is, if probe only, don't enter the wait loop + <youpi> could that be just some ifs here and there? + <youpi> (though not making the code easier to read...) + <braunr> hm i'm not sure it's fine + <youpi> in that case oi_select_timeout looks ncier ideed :) + <braunr> my problem with the current implementation is having the timeout + at the client side whereas the server side is doing the blocking + <youpi> I wonder how expensive a notification is, compared to blocking + <youpi> a blocking indeed needs a thread stack + <youpi> (and kernel thread stuff) + <braunr> with the kind of async ipc we have, it's still better to do it + that way + <braunr> and all the code already exists + <braunr> having the timeout at the client side also have its advantage + <braunr> has* + <braunr> latency is more precise + <braunr> so the real problem is indeed the non blocking case only + <youpi> isn't it bound to kernel ticks anyway ? + <braunr> uh, not if your server sucks + <braunr> or is loaded for whatever reason + <youpi> ok, that's not what I understood by "precision" :) + <youpi> I'd rather call it robustness :) + <braunr> hm + <braunr> right + <braunr> there are several ways to do this, but the io_select_timeout one + looks fine to me + <braunr> and is already well on its way + <braunr> and it's reliable + <braunr> (whereas i'm not sure about reliability if we keep the timeout at + client side) + <youpi> btw make the timeout nanoseconds + <braunr> ?? + <youpi> pselect uses timespec, not timeval + <braunr> do we want pselect ? + <youpi> err, that's the only safe way with signals + <braunr> not only, no + <youpi> and poll is timespec also + <youpi> not only?? + <braunr> you mean ppol + <braunr> ppoll + <youpi> no, poll too + <youpi> by "the only safe way", I mean for select calls + <braunr> i understand the race issue + <youpi> ppoll is a gnu extension + <braunr> int poll(struct pollfd *fds, nfds_t nfds, int timeout); + <youpi> ah, right, I was also looking at ppoll + <youpi> any + <youpi> way + <youpi> we can use nanosecs + <braunr> most event loops use a pipe or a socketpair + <youpi> there's no reason not to + <antrik> youpi: I briefly considered special-casisg 0 timeouts last time we + discussed this; but I concluded that it's probably better to handle all + timeouts server-side + <youpi> I don't see why we should even discuss that + <braunr> and translate signals to writes into the pipe/socketpair + <youpi> antrik: ok + <antrik> you can't count on select() timout precision anyways + <antrik> a few ms more shouldn't hurt any sanely written program + <youpi> braunr: "most" doesn't mean "all" + <youpi> there *are* applications which use pselect + <braunr> well mach only handles millisedonds + <braunr> seconds + <youpi> and it's not going out of the standard + <youpi> mach is not the hurd + <youpi> if we change mach, we can still keep the hurd ipcs + <youpi> anyway + <youpi> agagin + <youpi> I reallyt don't see the point of the discussion + <youpi> is there anything *against* using nanoseconds? + <braunr> i chose the types specifically because of that :p + <braunr> but ok i can change again + <youpi> becaus what?? + <braunr> i chose to use mach's native time_value_t + <braunr> because it matches timeval nicely + <youpi> but it doesn't match timespec nicely + <braunr> no it doesn't + <braunr> should i add a hurd specific time_spec_t then ? + <youpi> "how do you tell the server you don't want a timeout ? a special + value ? like { -1; -1 } ?" + <youpi> you meant infinite blocking? + <braunr> youpi: yes + <braunr> oh right, pselect is posix + <youpi> actually posix says that there can be limitations on the maximum + timeout supported, which should be at least 31 days + <youpi> -1;-1 is thus fine + <braunr> yes + <braunr> which is why i could choose time_value_t (a struct of 2 integer_t) + <youpi> well, I'd say gnumach could grow a nanosecond-precision time value + <youpi> e.g. for clock_gettime precision and such + <braunr> so you would prefer me adding the time_spec_t time to gnumach + rather than the hurd ? + <youpi> well, if hurd RPCs are using mach types and there's no mach type + for nanoseconds, it m akes sense to add one + <youpi> I don't know about the first part + <braunr> yes some hurd itnerfaces also use time_value_t + <antrik> in general, I don't think Hurd interfaces should rely on a Mach + timevalue. it's really only meaningful when Mach is involved... + <antrik> we could even pass the time value as an opaque struct. don't + really need an explicit MIG type for that. + <braunr> opaque ? + <youpi> an opaque type would be a step backward from multi-machine support + ;) + <antrik> youpi: that's a sham anyways ;-) + <youpi> what? + <youpi> ah, using an opaque type, yes :) + <braunr> probably why my head bugged while reading that + <antrik> it wouldn't be fully opaque either. it would be two ints, right? + even if Mach doesn't know what these two ints mean, it still could to + byte order conversion, if we ever actually supported setups where it + matters... + <braunr> so uh, should this new time_spec_t be added in gnumach or the hurd + ? + <braunr> youpi: you're the maintainer, you decide :p + *** antrik (~olaf@port-92-195-60-96.dynamic.qsc.de) has joined channel + #hurd + <youpi> well, I don't like deciding when I didn't even have read fs.defs :) + <youpi> but I'd say the way forward is defining it in the hurd + <youpi> and put a comment "should be our own type" above use of the mach + type + <braunr> ok + *** antrik (~olaf@port-92-195-60-96.dynamic.qsc.de) has quit: Remote host + closed the connection + <braunr> and, by the way, is using integer_t fine wrt the 64-bits port ? + <youpi> I believe we settled on keeping integer_t a 32bit integer, like xnu + does + *** elmig (~elmig@a89-155-34-142.cpe.netcabo.pt) has quit: Quit: leaving + <braunr> ok so it's not + *** antrik (~olaf@port-92-195-60-96.dynamic.qsc.de) has joined channel + #hurd + <braunr> uh well + <youpi> why "not" ? + <braunr> keeping it 32-bits for the 32-bits userspace hurd + <braunr> but i'm talking about a true 64-bits version + <braunr> wouldn't integer_t get 64-bits then ? + <youpi> I meant we settled on a no + <youpi> like xnu does + <braunr> xnu uses 32-bits integer_t even when userspace runs in 64-bits + mode ? + <youpi> because things for which we'd need 64bits then are offset_t, + vm_size_t, and such + <youpi> yes + <braunr> ok + <braunr> youpi: but then what is the type to use for long integers ? + <braunr> or uintptr_t + <youpi> braunr: uintptr_t + <braunr> the mig type i mean + <youpi> type memory_object_offset_t = uint64_t; + <youpi> (and size) + <braunr> well that's a 64-bits type + <youpi> well, yes + <braunr> natural_t and integer_t were supposed to have the processor word + size + <youpi> probably I didn't understand your question + <braunr> if we remove that property, what else has it ? + <youpi> yes, but see rolands comment on this + <braunr> ah ? + <youpi> ah, no, he just says the same + <antrik> braunr: well, it's debatable whether the processor word size is + really 64 bit on x86_64... + <antrik> all known compilers still consider int to be 32 bit + <antrik> (and int is the default word size) + <braunr> not really + <youpi> as in? + <braunr> the word size really is 64-bits + <braunr> the question concerns the data model + <braunr> with ILP32 and LP64, int is always 32-bits, and long gets the + processor word size + <braunr> and those are the only ones current unices support + <braunr> (which is why long is used everywhere for this purpose instead of + uintptr_t in linux) + <antrik> I don't think int is 32 bit on alpha? + <antrik> (and probably some other 64 bit arches) + <braunr> also, assuming we want to maintain the ability to support single + system images, do we really want RPC with variable size types ? + <youpi> antrik: linux alpha's int is 32bit + <braunr> sparc64 too + <youpi> I don't know any 64bit port with 64bit int + <braunr> i wonder how posix will solve the year 2038 problem ;p + <youpi> time_t is a long + <youpi> the hope is that there'll be no 32bit systems by 2038 :) + <braunr> :) + <youpi> but yes, that matters to us + <youpi> number of seconds should not be just an int + <braunr> we can force a 64-bits type then + <braunr> i tend to think we should have no variable size type in any mig + interface + <braunr> youpi: so, new hurd type, named time_spec_t, composed of two + 64-bits signed integers + <pinotree> braunr: i added that in my prototype of monotonic clock patch + for gnumach + <braunr> oh + <youpi> braunr: well, 64bit is not needed for the nanosecond part + <braunr> right + <braunr> it will be aligned anyway :p + <youpi> I know + <youpi> uh, actually linux uses long there + <braunr> pinotree: i guess your patch is still in debian ? + <braunr> youpi: well yes + <braunr> youpi: why wouldn't it ? :) + <pinotree> no, never applied + <youpi> braunr: because 64bit is not needed + <braunr> ah, i see what you mean + <youpi> oh, posix says longa ctually + <youpi> *exactly* long + <braunr> i'll use the same sizes + <braunr> so it fits nicely with timespec + <braunr> hm + <braunr> but timespec is only used at the client side + <braunr> glibc would simply move the timespec values into our hurd specific + type (which can use 32-bits nanosecs) and servers would only use that + type + <braunr> all right, i'll do it that way, unless there are additional + comments next morning :) + <antrik> braunr: we never supported federations, and I'm pretty sure we + never will. the remnants of network IPC code were ripped out some years + ago. some of the Hurd interfaces use opaque structs too, so it wouldn't + even work if it existed. as I said earlier, it's really all a sham + <antrik> as for the timespec type, I think it's easier to stick with the + API definition at RPC level too + + +## IRC, freenode, #hurd, 2012-07-24 + + <braunr> youpi: antrik: is vm_size_t an appropriate type for a c long ? + <braunr> (appropriate mig type) + <antrik> I wouldn't say so. while technically they are pretty much + guaranteed to be the same, conceptually they are entirely different + things -- it would be confusing at least to do it that way... + <braunr> antrik: well which one then ? :( + <antrik> braunr: no idea TBH + <braunr> antrik_: that should have been natural_t and integer_t + <braunr> so maybe we should new types to replace them + <antrik_> braunr: actually, RPCs should never have nay machine-specific + types... which makes me realise that a 1:1 translation to the POSIX + definition is actually not possible if we want to follow the Mach ideals + <braunr> i agree + <braunr> (well, the original mach authors used natural_t in quite a bunch + of places ..) + <braunr> the mig interfaces look extremely messy to me because of this type + issue + <braunr> and i just want to move forward with my work now + <braunr> i could just use 2 integer_t, that would get converted in the + massive future revamp of the interfaces for the 64-bits userspace + <braunr> or 2 64-bits types + <braunr> i'd like us to agree on one of the two not too late so i can + continue + + +## IRC, freenode, #hurd, 2012-07-25 + + <antrik_> braunr: well, for actual kernel calls, machine-specific types are + probably hard to avoid... the problem is when they are used in other RPCs + <braunr> antrik: i opted for a hurd specific time_data_t = struct[2] of + int64 + <braunr> and going on with this for now + <braunr> once it works we'll finalize the types if needed + <antrik> I'm really not sure how to best handle such 32 vs. 64 bit issues + in Hurd interfaces... + <braunr> you *could* consider time_t and long to be machine specific types + <antrik> well, they clearly are + <braunr> long is + <braunr> time_t isn't really + <antrik> didn't you say POSIX demands it to be longs? + <braunr> we could decide to make it 64 bits in all versions of the hurd + <braunr> no + <braunr> posix requires the nanoseconds field of timespec to be long + <braunr> the way i see it, i don't see any problem (other than a little bit + of storage and performance) using 64-bits types here + <antrik> well, do we really want to use a machine-independent time format, + if the POSIX interfaces we are mapping do not?... + <antrik> (perhaps we should; I'm just uncertain what's better in this case) + <braunr> this would require creating new types for that + <braunr> probably mach types for consistency + <braunr> to replace natural_t and integer_t + <braunr> now this concerns a totally different issue than select + <braunr> which is how we're gonna handle the 64-bits port + <braunr> because natural_t and integer_t are used almost everywhere + <antrik> indeed + <braunr> and we must think of 2 ports + <braunr> the 32-bits over 64-bits gnumach, and the complete 64-bits one + <antrik> what do we do for the interfaces that are explicitly 64 bit? + <braunr> what do you mean ? + <braunr> i'm not sure there is anything to do + <antrik> I mean what is done in the existing ones? + <braunr> like off64_t ? + <antrik> yeah + <braunr> they use int64 and unsigned64 + <antrik> OK. so we shouldn't have any trouble with that at least... + <pinotree> braunr: were you adding a time_value_t in mach, but for + nanoseconds? + <braunr> no i'm adding a time_data_t to the hurd + <braunr> for nanoseconds yes + <pinotree> ah ok + <pinotree> (maybe sure it is available in hurd/hurd_types.defs) + <braunr> yes it's there + <pinotree> \o/ + <braunr> i mean, i didn't forget to add it there + <braunr> for now it's a struct[2] of int64 + <braunr> but we're not completely sure of that + <braunr> currently i'm teaching the hurd how to use timeouts + <pinotree> cool + <braunr> which basically involves adding a time_data_t *timeout parameter + to many functions + <braunr> and replacing hurd_condition_wait with hurd_condition_timedwait + <braunr> and making sure a timeout isn't an error on the return path + * pinotree has a simplier idea for time_data_t: add a file_utimesns to + fs.defs + <braunr> hmm, some functions have a nonblocking parameter + <braunr> i'm not sure if it's better to replace them with the timeout, or add the timeout parameter + <braunr> considering the functions involved may return EWOULDBLOCK + <braunr> for now i'll add a timeout parameter, so that the code requires as little modification as possible + <braunr> tell me your opinion on that please + <antrik> braunr: what functions? + <braunr> connq_listen in pflocal for example + <antrik> braunr: I don't really understand what you are talking about :-( + <braunr> some servers implement select this way : + <braunr> 1/ call a function in non-blocking mode, if it indicates data is available, return immediately + <braunr> 2/ call the same function, in blocking mode + <braunr> normally, with the new timeout parameter, non-blocking could be passed in the timeout parameter (with a timeout of 0) + <braunr> operating in non-blocking mode, i mean + <braunr> antrik: is it clear now ? :) + <braunr> i wonder how the hurd managed to grow so much code without a cond_timedwait function :/ + <braunr> i think i have finished my io_select_timeout patch on the hurd side + <braunr> :) + <braunr> a small step for the hurd, but a big one against vim latencies !! + <braunr> (which is the true reason i'm working on this haha) + <braunr> new hurd rbraun/io_select_timeout branch for those interested + <braunr> hm, my changes clashes hard with the debian pflocal patch by neal :/ + <braunr> clash* + <antrik> braunr: replace I'd say. no need to introduce redundancy; and code changes not affecting interfaces are cheap + <antrik> (in general, I'm always in favour of refactoring) + <braunr> antrik: replace what ? + <antrik> braunr: wow, didn't think moving the timeouts to server would be such a quick task :-) + <braunr> antrik: :) + <antrik> 16:57 < braunr> hmm, some functions have a nonblocking parameter + <antrik> 16:58 < braunr> i'm not sure if it's better to replace them with the timeout, or add the timeout parameter + <braunr> antrik: ah about that, ok + + +## IRC, freenode, #hurd, 2012-07-26 + + <pinotree> braunr: wrt your select_timeout branch, why not push only the + time_data stuff to master? + <braunr> pinotree: we didn't agree on that yet + + <braunr> ah better, with the correct ordering of io routines, my hurd boots + :) + <pinotree> and works too? :p + <braunr> so far yes + <braunr> i've spotted some issues in libpipe but nothing major + <braunr> i "only" have to adjust the client side select implementation now + + +## IRC, freenode, #hurd, 2012-07-27 + + <braunr> io_select should remain a routine (i.e. synchronous) for server + side stub code + <braunr> but should be asynchronous (send only) for client side stub code + <braunr> (since _hurs_select manually handles replies through a port set) + + +## IRC, freenode, #hurd, 2012-07-28 + + <braunr> why are there both REPLY_PORTS and IO_SELECT_REPLY_PORT macros in + the hurd .. + <braunr> and for the select call only :( + <braunr> and doing the exact same thing unless i'm mistaken + <braunr> the reply port is required for select anyway .. + <braunr> i just want to squeeze them into a new IO_SELECT_SERVER macro + <braunr> i don't think i can maintain the use the existing io_select call + as it is + <braunr> grr, the io_request/io_reply files aren't synced with the io.defs + file + <braunr> calls like io_sigio_request seem totally unused + <antrik> yeah, that's a major shortcoming of MIG -- we shouldn't need to + have separate request/reply defs + <braunr> they're not even used :/ + <braunr> i did something a bit ugly but it seems to do what i wanted + + +## IRC, freenode, #hurd, 2012-07-29 + + <braunr> good, i have a working client-side select + <braunr> now i need to fix the servers a bit :x + <braunr> arg, my test cases work, but vim doesn't :(( + <braunr> i hate select :p + <braunr> ah good, my problems are caused by a deadlock because of my glibc + changes + <braunr> ah yes, found my locking problem + <braunr> building my final libc now + * braunr crosses fingers + <braunr> (the deadlock issue was of course a one liner) + <braunr> grr deadlocks again + <braunr> grmbl, my deadlock is in pfinet :/ + <braunr> my select_timeout code makes servers deadlock on the libports + global lock :/ + <braunr> wtf.. + <braunr> youpi: it may be related to the failed asserttion + <braunr> deadlocking on mutex_unlock oO + <braunr> grr + <braunr> actually, mutex_unlock sends a message to notify other threads + that the lock is ready + <braunr> and that's what is blocking .. + <braunr> i'm not sure it's a fundamental problem here + <braunr> it may simply be a corruption + <braunr> i have several (but not that many) threads blocked in mutex_unlock + and one blocked in mutex_lcok + <braunr> i fail to see how my changes can create such a behaviour + <braunr> the weird thing is that i can't reproduce this with my test cases + :/ + <braunr> only vim makes things crazy + <braunr> and i suppose it's related to the terminal + <braunr> (don't terminals relay select requests ?) + <braunr> when starting vim through ssh, pfinet deadlocks, and when starting + it on the mach console, the console term deadlocks + <pinotree> no help/hints when started with rpctrace? + <braunr> i only get assertions with rpctrace + <braunr> it's completely unusable for me + <braunr> gdb tells vim is indeed blocked in a select request + <braunr> and i can't see any in the remote servers :/ + <braunr> this is so weird .. + <braunr> when using vim with the unmodified c library, i clearly see the + select call, and everything works fine .... + <braunr> 2e27: a1 c4 d2 b7 f7 mov 0xf7b7d2c4,%eax + <braunr> 2e2c: 62 (bad) + <braunr> 2e2d: f6 47 b6 69 testb $0x69,-0x4a(%edi) + <braunr> what's the "bad" line ?? + <braunr> ew, i think i understand my problem now + <braunr> the timeout makes blocking threads wake prematurely + <braunr> but on an mutex unlock, or a condition signal/broadcast, a message + is still sent, as it is expected a thread is still waiting + <braunr> but the receiving thread, having returned sooner than expected + from mach_msg, doesn't dequeue the message + <braunr> as vim does a lot of non blocking selects, this fills the message + queue ... + + +## IRC, freenode, #hurd, 2012-07-30 + + <braunr> hm nice, the problem i have with my hurd_condition_timedwait seems + to also exist in libpthread + +[[!taglink open_issue_libpthread]]. + + <braunr> although at a lesser degree (the implementation already correctly + removes a thread that timed out from a condition queue, and there is a + nice FIXME comment asking what to do with any stale wakeup message) + <braunr> and the only solution i can think of for now is to drain the + message queue + <braunr> ah yes, i know have vim running with my io_select_timeout code :> + <braunr> but hum + <braunr> eating all cpu + <braunr> ah nice, an infinite loop in _hurd_critical_section_unlock + <braunr> grmbl + <tschwinge> braunr: But not this one? + http://www.gnu.org/software/hurd/open_issues/fork_deadlock.html + <braunr> it looks similar, yes + <braunr> let me try again to compare in detail + <braunr> pretty much the same yes + <braunr> there is only one difference but i really don't think it matters + <braunr> (#3 _hurd_sigstate_lock (ss=0x2dff718) at hurdsig.c:173 + <braunr> instead of + <braunr> #3 _hurd_sigstate_lock (ss=0x1235008) at hurdsig.c:172) + <braunr> ok so we need to review jeremie's work + <braunr> tschwinge: thanks for pointing me at this + <braunr> the good thing with my patch is that i can reproduce in a few + seconds + <braunr> consistently + <tschwinge> braunr: You're welcome. Great -- a reproducer! + <tschwinge> You might also build a glibc without his patches as a + cross-test to see the issues goes away? + <braunr> right + <braunr> i hope they're easy to find :) + <tschwinge> Hmm, have you already done changes to glibc? Otherwise you + might also simply use a Debian package from before? + <braunr> yes i have local changes to _hurd_select + <tschwinge> OK, too bad. + <tschwinge> braunr: debian/patches/hurd-i386/tg-hurdsig-*, I think. + <braunr> ok + <braunr> hmmmmm + <braunr> it may be related to my last patch on the select_timeout branch + <braunr> (i mean, this may be caused by what i mentioned earlier this + morning) + <braunr> damn i can't build glibc without the signal disposition patches :( + <braunr> libpthread_sigmask.diff depends on it + <braunr> tschwinge: doesn't libpthread (as implemented in the debian glibc + patches) depend on global signal dispositions ? + <braunr> i think i'll use an older glibc for now + <braunr> but hmm which one .. + <braunr> oh whatever, let's fix the deadlock, it's simpler + <braunr> and more productive anyway + <tschwinge> braunr: May be that you need to revert some libpthread patch, + too. Or even take out the libpthread build completely (you don't need it + for you current work, I think). + <tschwinge> braunr: Or, of course, you locate the deadlock. :-) + <braunr> hum, now why would __io_select_timeout return + EMACH_SEND_INVALID_DEST :( + <braunr> the current glibc code just transparently reports any such error + as a false positive oO + <braunr> hm nice, segfault through recursion + <braunr> "task foo destroying an invalid port bar" everywhere :(( + <braunr> i still have problems at the server side .. + <braunr> ok i think i have a solution for the "synchronization problem" + <braunr> (by this name, i refer to the way mutex and condition variables + are implemented" + <braunr> (the problem being that, when a thread unblocks early, because of + a timeout, another may still send a message to attempt it, which may fill + up the message queue and make the sender block, causing a deadlock) + <braunr> s/attempt/attempt to wake/ + <bddebian> Attempts to wake a dead thread? + <braunr> no + <braunr> attempt to wake an already active thread + <braunr> which won't dequeue the message because it's doing something else + <braunr> bddebian: i'm mentioning this because the problem potentially also + exists in libpthread + +[[!taglink open_issue_libpthread]]. + + <braunr> since the underlying algorithms are exactly the same + <youpi> (fortunately the time-out versions are not often used) + <braunr> for now :) + <braunr> for reference, my idea is to make the wake call truely non + blocking, by setting a timeout of 0 + <braunr> i also limit the message queue size to 1, to limit the amount of + spurious wakeups + <braunr> i'll be able to test that in 30 mins or so + <braunr> hum + <braunr> how can mach_msg block with a timeout of 0 ?? + <braunr> never mind :p + <braunr> unfortunately, my idea alone isn't enough + <braunr> for those interested in the problem, i've updated the analysis in + my last commit + (http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d) + + +## IRC, freenode, #hurd, 2012-08-01 + + <braunr> damn, i can't manage to make threads calling condition_wait to + dequeue themselves from the condition queue :( + <braunr> (instead of the one sending the signal/broadcast) + <braunr> my changes on cthreads introduce 2 intrusive changes + <braunr> the first is that the wakeup port is limited to 1 port, and the + wakeup operation is totally non blocking + <braunr> which is something we should probably add in any case + <braunr> the second is that condition_wait dequeues itself after blocking, + instead of condition_signal/broadcast + <braunr> and this second change seems to introduce deadlocks, for reasons + completely unknown to me :(( + <braunr> limited to 1 message* + <braunr> if anyone has an idea about why it is bad for a thread to remove + itself from a condition/mutex queue, i'm all ears + <braunr> i'm hitting a wall :( + <braunr> antrik: if you have some motivation, can you review this please ? + http://www.sceen.net/~rbraun/0001-Rework-condition-signal-broadcast.patch + <braunr> with this patch, i get threads blocked in condition_wait, + apparently waiting for a wakeup that never comes (or was already + consumed) + <braunr> and i don't understand why : + <braunr> :( + <bddebian> braunr: The condition never happens? + <braunr> bddebian: it works without the patch, so i guess that's not the + problem + <braunr> bddebian: hm, you could be right actually :p + <bddebian> braunr: About what? :) + <braunr> 17:50 < bddebian> braunr: The condition never happens? + <braunr> although i doubt it again + <braunr> this problem is getting very very frustrating + <bddebian> :( + <braunr> it frightens me because i don't see any flaw in the logic :( + + +## IRC, freenode, #hurd, 2012-08-02 + + <braunr> ah, seems i found a reliable workaround to my deadlock issue, and + more than a workaround, it should increase efficiency by reducing + messaging + * braunr happy + <kilobug> congrats :) + <braunr> the downside is that we may have a problem with non blocking send + calls :/ + <braunr> which are used for signals + <braunr> i mean, this could be a mach bug + <braunr> let's try running a complete hurd with the change + <braunr> arg, the boot doesn't complete with the patch .. :( + <braunr> grmbl, by changing only a few bits in crtheads, the boot process + freezes in an infinite loop in somethign started after auth + (/etc/hurd/runsystem i assume) + + +## IRC, freenode, #hurd, 2012-08-03 + + <braunr> glibc actually makes some direct use of cthreads condition + variables + <braunr> and my patch seems to work with servers in an already working + hurd, but don't allow it to boot + <braunr> and the hang happens on bash, the first thing that doesn't come + from the hurd package + <braunr> (i mean, during the boot sequence) + <braunr> which means we can't change cthreads headers (as some primitives + are macros) + <braunr> *sigh* + <braunr> the thing is, i can't fix select until i have a + condition_timedwait primitive + <braunr> and i can't add this primitive until either 1/ cthreads are fixed + not to allow the inlining of its primitives, or 2/ the switch to pthreads + is done + <braunr> which might take a loong time :p + <braunr> i'll have to rebuild a whole libc package with a fixed cthreads + version + <braunr> let's do this + <braunr> pinotree: i see two __condition_wait calls in glibc, how is the + double underscore handled ? + <pinotree> where do you see it? + <braunr> sysdeps/mach/hurd/setpgid.c and sysdeps/mach/hurd/setsid.c + <braunr> i wonder if it's even used + <braunr> looks like we use posix/setsid.c now + <pinotree> #ifdef noteven + <braunr> ? + <pinotree> the two __condition_wait calls you pointed out are in such + preprocessor block + <pinotree> s + <braunr> but what does it mean ? + <pinotree> no idea + <braunr> ok + <pinotree> these two files should be definitely be used, they are found + earlier in the vpath + <braunr> hum, posix/setsid.c is a nop stub + <pinotree> i don't see anything defining "noteven" in glibc itself nor in + hurd + <braunr> :( + <pinotree> yes, most of the stuff in posix/, misc/, signal/, time/ are + ENOSYS stubs, to be reimplemented in a sysdep + <braunr> hm, i may have made a small mistake in cthreads itself actually + <braunr> right + <braunr> when i try to debug using a subhurd, gdb tells me the blocked + process is spinning in ld .. + <braunr> i mean ld.so + <braunr> and i can't see any debugging symbol + <braunr> some progress, it hangs at process_envvars + <braunr> eh + <braunr> i've partially traced my problem + <braunr> when a "normal" program starts, libc creates the signal thread + early + <braunr> the main thread waits for the creation of this thread by polling + its address + <braunr> (i.e. while (signal_thread == 0); ) + <braunr> for some reason, it is stuck in this loop + <braunr> cthread creation being actually governed by + condition_wait/broadcast, it makes some sense + <bddebian> braunr: When you say the "main" thread, do you mean the main + thread of the program? + <braunr> bddebian: yes + <braunr> i think i've determined my mistake + <braunr> glibc has its own variants of the mutex primitives + <braunr> and i changed one :/ + <bddebian> Ah + <braunr> it's good news for me :) + <braunr> hum no, that's not exactly what i described + <braunr> glibc has some stubs, but it's not the problem, the problem is + that mutex_lock/unlock are macros, and i changed one of them + <braunr> so everything that used that macro inside glibc wasn't changed + <braunr> yes! + <braunr> my patched hurd now boots :) + * braunr relieved + <braunr> this experience at least taught me that it's not possible to + easily change the singly linked queues of thread (waiting for a mutex or + a condition variable) :( + <braunr> for now, i'm using a linear search from the start + <braunr> so, not only does this patched hurd boot, but i was able to use + aptitude, git, build a whole hurd, copy the whole thing, and remove + everything, and it still runs fine (whereas usually it would fail very + early) + * braunr happy + <antrik> and vim works fine now? + <braunr> err, wait + <braunr> this patch does only one thing + <braunr> it alters the way condition_signal/broadcast and + {hurd_,}condition_wait operate + <braunr> currently, condition_signal/broadcast dequeues threads from a + condition queue and wake them + <braunr> my patch makes these functions only wake the target threads + <braunr> which dequeue themselves + <braunr> (a necessary requirement to allow clean timeout handling) + <braunr> the next step is to fix my hurd_condition_wait patch + <braunr> and reapply the whole hurd patch indotrucing io_select_timeout + <braunr> introducing* + <braunr> then i'll be able to tell you + <braunr> one side effect of my current changes is that the linear search + required when a thread dequeues itself is ugly + <braunr> so it'll be an additional reason to help the pthreads porting + effort + <braunr> (pthreads have the same sort of issues wrt to timeout handling, + but threads are a doubly-linked lists, making it way easier to adjust) + <braunr> +on + <braunr> damn i'm happy + <braunr> 3 days on this stupid bug + <braunr> (which is actually responsible for what i initially feared to be a + mach bug on non blocking sends) + <braunr> (and because of that, i worked on the code to make it sure that 1/ + waking is truely non blocking and 2/ only one message is required for + wakeups + <braunr> ) + <braunr> a simple flag is tested instead of sending in a non blocking way + :) + <braunr> these improvments should be ported to pthreads some day + +[[!taglink open_issue_libpthread]] + + <braunr> ahah ! + <braunr> view is now FAST ! + <mel-> braunr: what do you mean by 'view'? + <braunr> mel-: i mean the read-only version of vim + <mel-> aah + <braunr> i still have a few port leaks to fix + <braunr> and some polishing + <braunr> but basically, the non-blocking select issue seems fixed + <braunr> and with some luck, we should get unexpected speedups here and + there + <mel-> so vim was considerable slow on the Hurd before? didn't know that. + <braunr> not exactly + <braunr> at first, it wasn't, but the non blocking select/poll calls + misbehaved + <braunr> so a patch was introduced to make these block at least 1 ms + <braunr> then vim became slow, because it does a lot of non blocking select + <braunr> so another patch was introduced, not to set the 1ms timeout for a + few programs + <braunr> youpi: darnassus is already running the patched hurd, which shows + (as expected) that it can safely be used with an older libc + <youpi> i.e. servers with the additional io_select? + <braunr> yes + <youpi> k + <youpi> good :) + <braunr> and the modified cthreads + <braunr> which is the most intrusive change + <braunr> port leaks fixed + <gnu_srs> braunr: Congrats:-D + <braunr> thanks + <braunr> it's not over yet :p + <braunr> tests, reviews, more tests, polishing, commits, packaging + + +## IRC, freenode, #hurd, 2012-08-04 + + <braunr> grmbl, apt-get fails on select in my subhurd with the updated + glibc + <braunr> otherwise it boots and runs fine + <braunr> fixed :) + <braunr> grmbl, there is a deadlock in pfinet with my patch + <braunr> deadlock fixed + <braunr> the sigstate and the condition locks must be taken at the same + time, for some obscure reason explained in the cthreads code + <braunr> but when a thread awakes and dequeues itself from the condition + queue, it only took the condition lock + <braunr> i noted in my todo list that this could create problems, but + wanted to leave it as it is to really see it happen + <braunr> well, i saw :) + <braunr> the last commit of my hurd branch includes the 3 line fix + <braunr> these fixes will be required for libpthreads + (pthread_mutex_timedlock and pthread_cond_timedwait) some day + <braunr> after the select bug is fixed, i'll probably work on that with you + and thomas d + + +## IRC, freenode, #hurd, 2012-08-05 + + <braunr> eh, i made dpkg-buildpackage use the patched c library, and it + finished the build oO + <gnu_srs> braunr: :) + <braunr> faked-tcp was blocked in a select call :/ + <braunr> (with the old libc i mean) + <braunr> with mine i just worked at the first attempt + <braunr> i'm not sure what it means + <braunr> it could mean that the patched hurd servers are not completely + compatible with the current libc, for some weird corner cases + <braunr> the slowness of faked-tcp is apparently inherent to its + implementation + <braunr> all right, let's put all these packages online + <braunr> eh, right when i upload them, i get a deadlock + <braunr> this one seems specific to pfinet + <braunr> only one deadlock so far, and the libc wasn't in sync with the + hurd + <braunr> :/ + <braunr> damn, another deadlock as soon as i send a mail on bug-hurd :( + <braunr> grr + <pinotree> thou shall not email + <braunr> aptitude seems to be a heavy user of select + <braunr> oh, it may be due to my script regularly chaning the system time + <braunr> or it may not be a deadlock, but simply the linear queue getting + extremely large + + +## IRC, freenode, #hurd, 2012-08-06 + + <braunr> i have bad news :( it seems there can be memory corruptions with + my io_select patch + <braunr> i've just seen an auth server (!) spinning on a condition lock + (the internal spin lock), probably because the condition was corrupted .. + <braunr> i guess it's simply because conditions embedded in dynamically + allocated structures can be freed while there are still threads waiting + ... + <braunr> so, yes the solution to my problem is simply to dequeue threads + from both the waker when there is one, and the waiter when no wakeup + message was received + <braunr> simple + <braunr> it's so obvious i wonder how i didn't think of it earlier :(- + <antrik> braunr: an elegant solution always seems obvious afterwards... ;-) + <braunr> antrik: let's hope this time, it's completely right + <braunr> good, my latest hurd packages seem fixed finally + <braunr> looks like i got another deadlock + * braunr hangs himselg + <braunr> that, or again, condition queues can get very large (e.g. on + thread storms) + <braunr> looks like this is the case yes + <braunr> after some time the system recovered :( + <braunr> which means a doubly linked list is required to avoid pathological + behaviours + <braunr> arg + <braunr> it won't be easy at all to add a doubly linked list to condition + variables :( + <braunr> actually, just a bit messy + <braunr> youpi: other than this linear search on dequeue, darnassus has + been working fine so far + <youpi> k + <youpi> Mmm, you'd need to bump the abi soname if changing the condition + structure layout + <braunr> :( + <braunr> youpi: how are we going to solve that ? + <youpi> well, either bump soname, or finish transition to libpthread :) + <braunr> it looks better to work on pthread now + <braunr> to avoid too many abi changes + +[[libpthread]]. + + +## IRC, freenode, #hurd, 2012-08-07 + + <rbraun_hurd> anyone knows of applications extensively using non-blocking + networking functions ? + <rbraun_hurd> (well, networking functions in a non-blocking way) + <antrik> rbraun_hurd: X perhaps? + <antrik> it's single-threaded, so I guess it must be pretty async ;-) + <antrik> thinking about it, perhaps it's the reason it works so poorly on + Hurd... + <braunr> it does ? + <rbraun_hurd> ah maybe at the client side, right + <rbraun_hurd> hm no, the client side is synchronous + <rbraun_hurd> oh by the way, i can use gitk on darnassys + <rbraun_hurd> i wonder if it's because of the select fix + <tschwinge> rbraun_hurd: If you want, you could also have a look if there's + any improvement for these: + http://www.gnu.org/software/hurd/open_issues/select.html (elinks), + http://www.gnu.org/software/hurd/open_issues/dbus.html, + http://www.gnu.org/software/hurd/open_issues/runit.html + <tschwinge> rbraun_hurd: And congratulations, again! :-) + <rbraun_hurd> tschwinge: too bad it can't be merged before the pthread port + :( + <antrik> rbraun_hurd: I was talking about server. most clients are probably + sync. + <rbraun_hurd> antrik: i guessed :) + <antrik> (thought certainly not all... multithreaded clients are not really + supported with xlib IIRC) + <rbraun_hurd> but i didn't have much trouble with X + <antrik> tried something pushing a lot of data? like, say, glxgears? :-) + <rbraun_hurd> why not + <rbraun_hurd> the problem with tests involving "a lot of data" is that it + can easily degenerate into a livelock + <antrik> yeah, sounds about right + <rbraun_hurd> (with the current patch i mean) + <antrik> the symptoms I got were general jerkiness, with occasional long + hangs + <rbraun_hurd> that applies to about everything on the hurd + <rbraun_hurd> so it didn't alarm me + <antrik> another interesting testcase is freeciv-gtk... it reporducibly + caused a thread explosion after idling for some time -- though I don't + remember the details; and never managed to come up with a way to track + down how this happens... + <rbraun_hurd> dbus is more worthwhile + <rbraun_hurd> pinotree: hwo do i test that ? + <pinotree> eh? + <rbraun_hurd> pinotree: you once mentioned dbus had trouble with non + blocking selects + <pinotree> it does a poll() with a 0s timeout + <rbraun_hurd> that's the non blocking select part, yes + <pinotree> you'll need also fixes for the socket credentials though, + otherwise it won't work ootb + <rbraun_hurd> right but, isn't it already used somehow ? + <antrik> rbraun_hurd: uhm... none of the non-X applications I use expose a + visible jerkiness/long hangs pattern... though that may well be a result + of general load patterns rather than X I guess + <rbraun_hurd> antrik: that's my feeling + <rbraun_hurd> antrik: heavy communication channels, unoptimal scheduling, + lack of scalability, they're clearly responsible for the generally + perceived "jerkiness" of the system + <antrik> again, I can't say I observe "general jerkiness". apart from slow + I/O the system behaves rather normally for the things I do + <antrik> I'm pretty sure the X jerkiness *is* caused by the socket + communication + <antrik> which of course might be a scheduling issue + <antrik> but it seems perfectly possible that it *is* related to the select + implementation + <antrik> at least worth a try I'd say + <rbraun_hurd> sure + <rbraun_hurd> there is still some work to do on it though + <rbraun_hurd> the client side changes i did could be optimized a bit more + <rbraun_hurd> (but i'm afraid it would lead to ugly things like 2 timeout + parameters in the io_select_timeout call, one for the client side, the + other for the servers, eh) + + +## IRC, freenode, #hurd, 2012-08-07 + + <braunr> when running gitk on [darnassus], yesterday, i could push the CPU + to 100% by simply moving the mouse in the window :p + <braunr> (but it may also be caused by the select fix) + <antrik> braunr: that cursor might be "normal" + <rbraunrh> antrik: what do you mean ? + <antrik> the 100% CPU + <rbraunh> antrik: yes i got that, but what would make it normal ? + <rbraunh> antrik: right i get similar behaviour on linux actually + <rbraunh> (not 100% because two threads are spread on different cores, but + their cpu usage add up to 100%) + <rbraunh> antrik: so you think as long as there are events to process, the + x client is running + <rbraunh> thath would mean latencies are small enough to allow that, which + is actually a very good thing + <antrik> hehe... sound kinda funny :-) + <rbraunh> this linear search on dequeue is a real pain :/ + + +## IRC, freenode, #hurd, 2012-08-09 + +`screen` doesn't close a window/hangs after exiting the shell. + + <rbraunh> the screen issue seems linked to select :p + <rbraunh> tschwinge: the term server may not correctly implement it + <rbraunh> tschwinge: the problem looks related to the term consoles not + dying + <rbraunh> http://www.gnu.org/software/hurd/open_issues/term_blocking.html + +[[Term_blocking]]. + + +# IRC, freenode, #hurd, 2012-12-05 + + <braunr> well if i'm unable to build my own packages, i'll send you the one + line patch i wrote that fixes select/poll for the case where there is + only one descriptor + <braunr> (the current code calls mach_msg twice, each time with the same + timeout, doubling the total wait time when there is no event) + + +## IRC, freenode, #hurd, 2012-12-06 + + <braunr> damn, my eglibc patch breaks select :x + <braunr> i guess i'll just simplify the code by using the same path for + both single fd and multiple fd calls + <braunr> at least, the patch does fix the case i wanted it to .. :) + <braunr> htop and ping act at the right regular interval + <braunr> my select patch is : + <braunr> /* Now wait for reply messages. */ + <braunr> - if (!err && got == 0) + <braunr> + if (!err && got == 0 && firstfd != -1 && firstfd != lastfd) + <braunr> basically, when there is a single fd, the code calls io_select + with a timeout + <braunr> and later calls mach_msg with the same timeout + <braunr> effectively making the maximum wait time twice what it should be + <pinotree> ouch + <braunr> which is why htop and ping are "laggy" + <braunr> and perhaps also why fakeroot is when building libc + <braunr> well + <braunr> when building packages + <braunr> my patch avoids entering the mach_msg call if there is only one fd + <braunr> (my failed attempt didn't have the firstfd != -1 check, leading to + the 0 fd case skipping mach_msg too, which is wrong since in that case + there is just no wait, making applications use select/poll for sleeping + consume all cpu) + + <braunr> the second is a fix in select (yet another) for the case where a + single fd is passed + <braunr> in which case there is one timeout directly passed in the + io_select call, but then yet another in the mach_msg call that waits for + replies + <braunr> this can account for the slowness of a bunch of select/poll users + + +## IRC, freenode, #hurd, 2012-12-07 + + <braunr> finally, my select patch works :) + + +## IRC, freenode, #hurd, 2012-12-08 + + <braunr> for those interested, i pushed my eglibc packages that include + this little select/poll timeout fix on my debian repository + <braunr> deb http://ftp.sceen.net/debian-hurd experimental/ + <braunr> reports are welcome, i'm especially interested in potential + regressions + + +## IRC, freenode, #hurd, 2012-12-10 + + <gnu_srs> I have verified your double timeout bug in hurdselect.c. + <gnu_srs> Since I'm also working on hurdselect I have a few questions + about where the timeouts in mach_msg and io_select are implemented. + <gnu_srs> Have a big problem to trace them down to actual code: mig magic + again? + <braunr> yes + <braunr> see hurd/io.defs, io_select includes a waittime timeout: + natural_t; parameter + <braunr> waittime is mig magic that tells the client side not to wait more + than the timeout + <braunr> and in _hurd_select, you can see these lines : + <braunr> err = __io_select (d[i].io_port, d[i].reply_port, + <braunr> /* Poll only if there's a single + descriptor. */ + <braunr> (firstfd == lastfd) ? to : 0, + <braunr> to being the timeout previously computed + <braunr> "to" + <braunr> and later, when waiting for replies : + <braunr> while ((msgerr = __mach_msg (&msg.head, + <braunr> MACH_RCV_MSG | options, + <braunr> 0, sizeof msg, portset, to, + <braunr> MACH_PORT_NULL)) == + MACH_MSG_SUCCESS) + <braunr> the same timeout is used + <braunr> hope it helps + <gnu_srs> Additional stuff on io-select question is at + http://paste.debian.net/215401/ + <gnu_srs> Sorry, should have posted it before you comment, but was + disturbed. + <braunr> 14:13 < braunr> waittime is mig magic that tells the client side + not to wait more than the timeout + <braunr> the waittime argument is a client argument only + <braunr> that's one of the main source of problems with select/poll, and + the one i fixed 6 months ago + <gnu_srs> so there is no relation to the third argument of the client call + and the third argument of the server code? + <braunr> no + <braunr> the 3rd argument at server side is undoubtedly the 4th at client + side here + <gnu_srs> but for the fourth argument there is? + <braunr> i think i've just answered that + <braunr> when in doubt, check the code generated by mig when building glibc + <gnu_srs> as I said before, I have verified the timeout bug you solved. + <gnu_srs> which code to look for RPC_*? + <braunr> should be easy to guess + <gnu_srs> is it the same with mach_msg()? No explicit usage of the timeout + there either. + <gnu_srs> in the code for the function I mean. + <braunr> gnu_srs: mach_msg is a low level system call + <braunr> see + http://www.gnu.org/software/hurd/gnumach-doc/Mach-Message-Call.html#Mach-Message-Call + <gnu_srs> found the definition of __io_select in: RPC_io_select.c, thanks. + <gnu_srs> so the client code to look for wrt RPC_ is in hurd/*.defs? what + about the gnumach/*/include/*.defs? + <gnu_srs> a final question: why use a timeout if there is a single FD for + the __io_select call, not when there are more than one? + <braunr> well, the code is obviously buggy, so don't expect me to justify + wrong code + <braunr> but i suppose the idea was : if there is only one fd, perform a + classical synchronous RPC, whereas if there are more use a heavyweight + portset and additional code to receive replies + + <youpi> exim4 didn't get fixed by the libc patch, unfortunately + <braunr> yes i noticed + <braunr> gdb can't attach correctly to exim, so it's probably something + completely different + <braunr> i'll try the non intrusive mode + + +# See Also + +See also [[select_bogus_fd]] and [[select_vs_signals]]. diff --git a/open_issues/select_bogus_fd.mdwn b/open_issues/select_bogus_fd.mdwn new file mode 100644 index 00000000..17aced4a --- /dev/null +++ b/open_issues/select_bogus_fd.mdwn @@ -0,0 +1,55 @@ +[[!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]] + + +# Python + +IRC, freenode, #hurd, 2011-04-13 + + <abeaumont> ok, cause of first python testsuite failure located, now the + hard part, how to best fix it :) + <abeaumont> how to redesign the code to avoid the problem... that's the + hard part, mostly cause i lack contextual info + <abeaumont> tschwinge: the problem is pretty much summarized by this + comment in _hurd_select (in glibc): /* If one descriptor is bogus, we + fail completely. */ + <pochu> does POSIX say anything about what to do if one fd is invalid? + <pochu> and the other question is why python is calling select() with an + invalid fd + <abeaumont> pochu: yep, it says it should not fail completelly + <pochu> then that's our bug :) + <pinotree> abeaumont: just note that (at least on debian) some tests may + hang forever or cause hurd/mach to die + <pinotree> abeaumont: see in the debian/rules of the packaging of each + pythonX.Y source + <pinotree> ... there's a list of the tests excluded from the test suite run + <abeaumont> well, to be precise, python has a configure check for + 'broken_poll' which hurd fails, and therefore python's select module is + not built, and anything depending on it fails + <abeaumont> broken_poll checks exactly for that posix requirement + <abeaumont> the reason for python using a non-existant + descriptor... unknown :D + <pochu> we should fix select to not fail miserably in that case + <pinotree> abeaumont: we have a patch to fix the broken poll check to + actually disable the poll module + <pochu> pinotree: but the proper fix is to fix select(), which is what + abeaumont is looking at + <abeaumont> pinotree: i'd say that's exactly what python's configure check + does itself -- disable building the select module + <pochu> abeaumont: what pinotree means is that the check is broken, see + http://patch-tracker.debian.org/patch/series/view/python2.6/2.6.6-8/hurd-broken-poll.diff + <pinotree> yes, the configure check for poll does the check, but not + everything of the poll module gets disabled (and you get a build failure) + +--- + +See also [[select]] and [[select_vs_signals]]. diff --git a/open_issues/select_vs_signals.mdwn b/open_issues/select_vs_signals.mdwn new file mode 100644 index 00000000..bbd69d00 --- /dev/null +++ b/open_issues/select_vs_signals.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]] + + +# `sudo` + +`sudo [task]` hands after finishing `[task]`. + +IRC, freenode, #hurd, 2011-04-02 + + <youpi> the sudo bug is select() not being able to get interrupted by + signals + +--- + +See also [[select]] and [[select_bogus_fd]]. diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn new file mode 100644 index 00000000..cf0103df --- /dev/null +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -0,0 +1,101 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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, unknown channel, unknown date. + + <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722 + <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724 + <pinotree> \o/ + <youpi> \o/ + <pinotree> the patch is even short, after all: http://paste.debian.net/54795/ + --- a/sysdeps/mach/hurd/sendmsg.c + +++ b/sysdeps/mach/hurd/sendmsg.c + @@ -18,6 +18,7 @@ + + #include <errno.h> + #include <string.h> + +#include <unistd.h> + #include <sys/socket.h> + #include <sys/un.h> + + @@ -45,6 +46,7 @@ + mach_msg_type_number_t amount; + int dealloc = 0; + int i; + + struct sockaddr_storage sa; + + /* Find the total number of bytes to be written. */ + len = 0; + @@ -122,6 +124,34 @@ + err = EIEIO; + } + + + memset (&sa, 0, sizeof (struct sockaddr_storage)); + + if (addr) + + { + + memcpy (&sa, addr, addr_len); + + } + + else + + { + + getsockname (fd, (struct sockaddr *) &sa, &addr_len); + + } + + addr = (struct sockaddr_un *) &sa; + + if (message && (addr->sun_family == AF_LOCAL)) + + { + + struct cmsghdr *cm; + + struct msghdr *m = (struct msghdr *) message; + + for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm)) + + { + + if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS) + + { + + struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm); + + cred->cmcred_pid = __getpid (); + + cred->cmcred_uid = __getuid (); + + cred->cmcred_euid = __geteuid (); + + cred->cmcred_gid = __getgid (); + + cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups); + + } + + } + + } + + + err = HURD_DPORT_USE (fd, + ({ + if (err) + <youpi> what checks that the pid is correct? + <youpi> and uid, etc. + <pinotree> hm? + <youpi> credential is not only about one claiming to the other his uid & such + <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end + <pinotree> yep + <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side + <youpi> pflocal could as well just request the info from proc + <youpi> it will have to anyway, to check that it's true + <pinotree> hm + <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive) + <youpi> well at least it shows we're able to transmit something :) + <pinotree> well it just manipulates the data which gets send nicely already ;) + <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end + <youpi> the application sender part would be just the RPC authentication calls + <youpi> Mmm, just realizing: so receiver part already exists actually, right? + <youpi> (since it's just about letting the application reading from the message structure) + <pinotree> yep + <youpi> ok, good :) + +/!\ IRC, freenode, #hurd, 2011-08-11 + + < pinotree> (but that patch is lame) + +--- + +See also [[dbus]], [[pflocal_socket_credentials_for_local_sockets]] and +[[pflocal_reauth]]. diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn new file mode 100644 index 00000000..ed6358a2 --- /dev/null +++ b/open_issues/serial_console.mdwn @@ -0,0 +1,52 @@ +[[!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_documentation]] + +IRC, #hurdfr, 2010-09-20 + + <youpi> tu peux compiler ton gnumach pour qu'il utilise la console série, et tu + mets le port série sur la console qemu + <youpi> -AC_DEFINE([RCLINE], [-1], [com port for the remote console]) + <youpi> +AC_DEFINE([RCLINE], [0], [com port for the remote console]) + <youpi> dans i386/configfrag.ac + <manuel> grumpf, peu pratique :) + <youpi> ben après t'auras accès vraiment à ton gnumach + <youpi> messages de noyau etc. + <manuel> oui c'est sûr, mais j'ai aucune idée de comment je configure qemu & + co, ça va être sportif encore + <youpi> -serial vc + <manuel> je lance pas moi-même le qemu, donc j'imagine qqch comme -serial + tcp::qqch,server + <youpi> ben t'as pas accès à la console alors ? + <youpi> mais sinon via tcp ça devrait aller oui + <manuel> si, via telnet + <manuel> youpi: et après, tu fais comment pour envoyer le c-a-D toi ? + <manuel> (question sans doute bête) + <youpi> c'est un code différent via com1 iirc + <manuel> mmmmmmmmmhhhhhh + <youpi> (c'est pas bête: c-a-d c'est pas vraiment défini pour un port série) + <manuel> tu sais où je peux le trouver ? + <youpi> ah tiens non yena pas + <youpi> mais bon spa dur à ajouter + <manuel> bcp trop compliqué pour moi + <youpi> dans i386/i386at/com.c, à la première ligne ttyinput() + <youpi> tu compares c à ce que tu veux + <youpi> et dans ce cas tu appelles kdb_kintr + <youpi> (sans paramètre) + <youpi> mais sinon ya pas vraiment besoin d'appeller explicitement le + débuggueur hein + <manuel> ah ? + <youpi> dès que tu mets debug_all_traps à 1 dans traps.c, il sera invoqué lors + du segv + <manuel> ok + <youpi> pour xen j'ai mis £ comme raccourcis + <manuel> ça me paraît plus simple dans ce cas + <youpi> clin d'œil à la société anglaise :) diff --git a/open_issues/servers_default-pager_permissions.mdwn b/open_issues/servers_default-pager_permissions.mdwn new file mode 100644 index 00000000..58dba1cb --- /dev/null +++ b/open_issues/servers_default-pager_permissions.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2012 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="/servers/default-pager permissions"]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2012-01-14: + + <youpi> antrik: what are the permissions that are supposed to be given to + /servers/default-pager ? + <antrik> olaf@alien:~$ ls -l /servers/default-pager + <antrik> crw-rw-rw- 1 root root 0, 0 Sep 17 2004 /servers/default-pager + <antrik> oh, interesting... in the other system it's different + <antrik> olaf@alien:~$ ls -l /sub/servers/default-pager + <antrik> crw-r--r-- 1 root root 0, 0 Jul 10 2006 + /sub/servers/default-pager + <antrik> both are Debian, the latter installed with crosshurd + <antrik> (and native-install run in a chroot or subhurd, don't remember + which...) diff --git a/open_issues/settrans_directory_symlink.mdwn b/open_issues/settrans_directory_symlink.mdwn new file mode 100644 index 00000000..86148a52 --- /dev/null +++ b/open_issues/settrans_directory_symlink.mdwn @@ -0,0 +1,52 @@ +[[!meta copyright="Copyright © 2012 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]] + +This works: + + $ touch a && settrans a /hurd/symlink b + +This doesn't: + + $ mkdir a && settrans a /hurd/symlink b + settrans: a: Is a directory + +It's the same `file_set_translator` RPC both times, and it's [[translator +short-circuiting|hurd/translator/short-circuiting]] which makes the latter one +fail: + +`libdiskfs/file-set-trans.c`: + + [...] + /* Set passive translator */ + if (passive_flags & FS_TRANS_SET) + { + if (!(passive_flags & FS_TRANS_FORCE)) + { + /* Handle the short-circuited translators */ + mode_t newmode = 0; + + if (diskfs_shortcut_symlink && !strcmp (passive, _HURD_SYMLINK)) + newmode = S_IFLNK; + [...] + + if (newmode) + { + if (S_ISDIR (np->dn_stat.st_mode)) + { + /* We can't allow this, because if the mode of the directory + changes, the links will be lost. Perhaps it might be + allowed for empty directories, but that's too much of a + pain. */ + mutex_unlock (&np->lock); + return EISDIR; + } + [...] diff --git a/open_issues/sigpipe.mdwn b/open_issues/sigpipe.mdwn new file mode 100644 index 00000000..0df3560e --- /dev/null +++ b/open_issues/sigpipe.mdwn @@ -0,0 +1,345 @@ +[[!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_hurd]] + +[[!GNU_Savannah_bug 461]] + +IRC, freenode, #hurd, 2011-04-20 + + <svante_> I found a problem from 2002 by Marcus Brinkmann that I think is + related to my problems: http://savannah.gnu.org/bugs/?461. He has a test + file called pipetest.c that shows that SIGPIPE is not triggered reliably. + <svante_> Cited from the bug report: The attached test program does not + trigger SIGPIPE reliably, because closing the read end of the pipe + happens asynchronously. The write can succeed because the read end might + not have been closed yet. + <svante_> I have debugged this program on both Hurd and Linux, and the + problem in Hurd remains:-( + <svante_> Anybody looked into the almost ten year old + bug:http://savannah.gnu.org/bugs/?461 this one is definitely related to + the build problems of e.g. ghc6 and ruby1.9.1. Should I mention this on + the ML? + <youpi> that could be it indeed + <youpi> does th bug still happen? + <azeem> depends on: new interface io_close + <azeem> which depends on: POSIX record locking + <svante_> youpi: Yes it does, I've tested the pipetest.c file submitted by + Marcus B on both Linux and Hurd + <azeem> that would've maybe been a nice GSOC task + <youpi> azeem: err, the contrary for posix record locking, non ? + <azeem> argh + <azeem> why would POSIX record locking depend on this? + <azeem> well anyway, then have POSIX record locking be a GSOC task :) + <azeem> I wasn't aware that would also fix ruby and ghc building :) + <youpi> http://permalink.gmane.org/gmane.os.hurd.devel.readers/265 + <youpi> (for io_close stuff) + <youpi> http://comments.gmane.org/gmane.os.hurd.devel.readers/63 actually + <azeem> I guess if they didn't implement it/agreed on something back then + it'd be quite hard to do it now + <svante_> azeem: marcus recently showed up here. Maybe he can help out/has + ideas? + <azeem> well yeah + <azeem> but marcus was the junior guy back then + <azeem> <marcus> but it's a very hurdish solution (ie, complex, buggy, and + not implemented) + <azeem> maybe we can go for something simpler + <youpi> azeem: what is this quote about? + <azeem> don't remember + <azeem> not io_close I'd say + +2011-04-21 + + <antrik> svante_: why do you think the problem you see in ruby and ghc is + related to async close() ? + +2011-04-22 + + <svante_> Well: the test case I'm running on ruby is giving me an EBADF + after 8 successful loops, and tracing within eglibc points towards + __mutex_lock_solid or __spin_lock, __spin_lock_solid from + mach/lock-intern.h from cthreads. + +2011-04-23 + + <antrik> srs1: yeah, I saw it... but I still wonder what makes you think + this is related to async FD closing? + <srs1> antrik: Every test case showing the problems are related to fd.h and + the functions there, especially the ones used in the function: + _HURD_FD_H_EXTERN_INLINE struct hurd_fd *_hurd_fd_get (int fd) and so is + the pipetest from Marcus too. + <srs1> I have not yet been able to trace further with gdb since most + variables are optimized out and adding print statements does not work, at + least not yet. Now I'm trying to build eglibc with -O1 to see if the + optimized out variables are there or not. + <youpi> srs1: he means the ghc6 issue + <youpi> (and the ruby issue) + <srs1> youpi: Yes, the ghc6 and ruby ends at the functions I mentioned in + fd,h + <srs1> Both ghc6 and ruby programs are writing to a file when the error + happens. If they are using a pipeline or not I don't know yet, I think it + is a regular file write. + <srs1> I can send your the ruby program if you like: It is a c-file so + debugging is possible. ghc6 is worse, since that program cannot be + debugged directly with gdb. + <antrik> pipetest also results in the program hanging in locking stuff?... + <srs1> pipetest does not hang, but gives no output as it should. Running it + in gdb with single stepping shows the correct behavior, but then gdb + hangs if I try to single stepping further, continue at the right place + works! + <antrik> I haven't looked at the pipetest program. do you have the link + handy? + <antrik> never mind, got it + <antrik> srs1: that sounds like a GDB problem... + <youpi> most probably, yes + <youpi> (and I've always seen issues like this in gdb on hurd) + <antrik> actually I think it's expected... the RPC handling code has some + explicit GDB hooks AIUI; trying to single-step into this code is probably + expected to wreck havoc... + <youpi> well, it should have some sane behavior + <youpi> even if it's "skip to next point where it's debuggable" + <antrik> srs1: note that there is no BADF involved in the pipetest AIUI... + +2011-04-28 + + <antrik> what is the actual problem you are seeing BTW? + <gnu_srs1> antrik: in ruby the problem is: Exception `IOError' at + tool/mkconfig.rb:12 - closed stream + <gnu_srs1> Triggered by ruby:io.c:internal_read_func() calling + sysdeps/mach/hurd/read.c returning a negative number of bytes read. + <abeaumont> gnu_srs1: why do you think that error is locking related? + <gnu_srs1> This happens after 8 iterations of the read loop with 8192 bytes + read each time. + <abeaumont> but that doesn't involve locking at all, does it? + <gnu_srs1> I think it is, if there is a pipepline set up?? + <gnu_srs1> Also the ghc6 hang ends up in hangs in sysdeps/mach/hurd/read.c + traced into fd.h where all things happen (including setting locks and + mutexes) + <braunr> what locking ? + <braunr> stdio locking is different from file locking + <braunr> and a pipe doesn't imply file locking at all + <abeaumont> read may block on pipes, but it's unrelated to flock + <gnu_srs1> Look into the file fd.h, maybe you can describe things + better. I'm not fluent in this stuff. + <gnu_srs1> Has a pipe has a file descriptor associated to it? What about a + file read/write? + <abeaumont> a pipe provides 2 file descriptors, one for reading and another + one for writting + <abeaumont> i may give a look at that if i manage to build glibc + succesfully... + <gnu_srs1> Take a look at the realevant code from fd.h: + http://pastebin.com/kesBpjy4 + <abeaumont> the ruby error happens just trying to build ruby1.9? + <abeaumont> gnu_srs1: from what you said, the error occurs while reading, + so i don't see how it can be related to that code + <abeaumont> you already got a descriptor if you're reading from it + <gnu_srs1> I have not tried anything else than ruby1.9.1. I can send you + the ruby debug setup and files if you are interested. + <abeaumont> gnu_srs1: ok, i'll try to build ruby1.9.1 later... let's see if + i can build glibc first + <gnu_srs1> abeaumont: well, the read suddenly returns -1 bytes read, + resulting in a file descriptor of -1 (instead of +3). + <abeaumont> gnu_srs1: i see + <antrik> gnu_srs1: are you sure the hang really happens in _hurd_fd_get()? + could you give us a backtrace? + <antrik> gnu_srs1: there are many reasons why read() can return -1; errno + should indicate the reason. unfortunately, I can't make much out of + ruby's "translation" of the error :-) + <gnu_srs1> antrik: In the ruby case there is no hang: The steam is closed + by read() giving an error code !=0. This triggers things in the ruby + code: A negative number of bytes read and a negative fd results, and an + error error is triggered in the ruby code. + <gnu_srs1> antrik: See http://pastebin.com/eZmaZQJr + <antrik> gnu_srs1: yes, this all sounds perfectly right. the question is + *why* read() returns an error code. we'd need to know what error it is + exactly, and in what situation it occurs. tracing the libc code is not at + all useful here + <antrik> uhm... 1073741833 is errno?... + <gnu_srs1> BTW: I think the error code is EBADF (badfile descriptor?). The + integer version of it is 1073741833, see the pastebin i linked to. + <antrik> you could use perror() to get something more readable :-) + <antrik> or error() with the right arguments + <gnu_srs1> I used integer when printing, but looking into fd.h I think it + is EBADF (I did get this result once in gdb) + <antrik> fd.h won't tell you anything. most error codes are generated by + the server, not by libc + <antrik> BADF might be generated in libc when ruby tries to read on FD -1 + <antrik> (no idea why it tries to do that... perhaps there is actually + something wrong/stupid in ruby's error handling) + <gnu_srs1> Well I single-stepped in fd.h using gdb and printing err gave + EBADf. err is declared as: error_t err in read.c + <antrik> at which point did you single-step? while fd was still 3? + <gnu_srs1> I don't think the problem is in ruby, it is in mach/hurd! + Similar problems with ghc, python-apt, etc + <gnu_srs1> Yes, fd=3 was not changed. I cannot trace into fd.h from + read.c. That is the problem with all cases! Need to leave for a while + now. + <antrik> sorry, I don't see *anything* similar in the ghc failure. + <antrik> I don't know about python-apt + <antrik> for the ghc case, I'd like to see a GDB backtrace from the point + where it is hanging + <antrik> just to be clear: anything I/O-related will involve fd.h + somewhere. that doesn't in any way indicate the problems are related. in + fact the symptoms you described are very different, and I'm pretty + certain these are completely different issues + <gnu_srs1> antrik: Here is a backtrace, + http://pastebin.com/wvCiXFjB. Numbers 6,7,8 are from the calling Haskell + functions. They cannot be debugged by gdb. Nice to see that somebody is + showing interest at last:-/ + <antrik> hm... I wonder whether the _hurd_intr_rpc_msg_in_trap is a result + of the ^C? + <antrik> if so, it seems to be a "normal" bloking read() operation. so + again probably not related to libc code at all + <gnu_srs1> Where is this blocking read() code located mach/hurd? + <antrik> io_read() is implemented by whatever server handles the FD in + question + <antrik> I guess rpctrace will be more helpful here than GDB... to see what + the program is trying to do here + <gnu_srs1> Why don't I get there with gdb? + <antrik> err... the server is a different process + <antrik> you are only tracing the client code + <gnu_srs1> OK, here is a rpctrace for ruby: + http://pastebin.com/sdPiKGBW.Nice programs you have, no manual pages, and + the program hang + <gnu_srs1> s/http://pastebin.com/sdPiKGBW.Nice + /http://pastebin.com/sdPiKGBW. BTW: Nice/ + <gnu_srs1> antrik: Do you want the rpctrace of the ghc hang too? If that is + the case, do you need the whole file. From the ruby case the last part + looked most interesting: + libpthread/sysdeps/generic/pt-mutex-timedlock.c: assert (mutex->owner != + self); + <antrik> gnu_srs1: hm... you get that assertion only with rpctrace? guess + it doesn't work properly then :-( + <gnu_srs1> Is it visible on the client side? + <antrik> gnu_srs1: that assertion *is* from the client side. I'm just + surprised that apparently it's only triggered when you run it in rpctrace + <antrik> how did you invoke rpctrace? + <gnu_srs1> rpctrace "command with options" > rpctrace.out 2>&1 + <antrik> well, I'd like to know the "command with options" part :-) + <gnu_srs1> OK: for ruby: ./miniruby ./ tool/mkconfig.rb as before. + <antrik> OK, so it just runs the ruby interpreter and no other processes + <gnu_srs1> No other processes involved! + <abeaumont> gnu_srs1: i can reproduce the ruby error, no let's dig in it :D + <antrik> gnu_srs1: rpctrace for ghc could be useful too... but if it's too + long, pasting only the last bit might suffice + <gnu_srs1> antrik: OK, will do that. Do you find anything interesting? + <gnu_srs1> abeaumont: Using gdb: gdb ./miniruby; (gdb) break io.c:569; c8; + break fd.h:72 or break read.c:27 and you are there. Beware of gdb + hanging, so you need another terminal to kill -9 gdb (sometimes a reboot + is needed :-( + <antrik> gnu_srs1: no, the ruby rpctrace is useless; apparently rpctrace + makes it break before reaching the relevant part :-( + <abeaumont> thanks gnu_srs1 + <gnu_srs1> antrik: Hope for better luck with ghc: + http://pastebin.com/dgcrA05t + <antrik> hm... it hangs at proc_dostop() again... whatever that means + +2011-05-07 + + <gnu_srs> One question about ruby: I know where the problems occur in ruby + code. Can I switch to the kernel thread just before in gdb to single step + from there? + <youpi> you can put a breakpoint, can't you? + <antrik> gnu_srs: kernel thread? + <gnu_srs> Yes, but will single stepping from there lead me to the Hurd + code. I have not succeeded to do that yet! + <youpi> you mean the translator code? + <gnu_srs> Well, Roland did call it the signal thread, there are at least + two threads per process, a signal thread and a main (user) thread. + <youpi> then it's a thread in gdb + <youpi> just use the thread gdb commands to access it + <gnu_srs> I do find two threads in gdb, yes. But following only the user + thread does not lead me to the cause of the problems. + <gnu_srs> And following the other (signal thread) has not been successful + so far. + <youpi> multithreading debugging in gdb is painful yes + <youpi> single-step isn't really an option in it + <antrik> gnu_srs: well, as I said before, the cause is probably not in the + libc code anyways. it would be much more relevant to find out what the FD + in question is, and what "special" thing Ruby does to it to trigger the + problematic behaviour... + <youpi> it's simpler to put printfs etc. + <antrik> youpi: well, printf doesn't work in the FD code :-) + <youpi> you can make it work + <youpi> open /dev/mem, write to 0xb8000 + <youpi> I'm not even joking + <gnu_srs> I have printfs in the ruby code. And at some parts in eglibc (but + it is not possible to put them at all places I want, as mentioned before) + <antrik> sure, there are ways to debug this code too... but I don't think + it's useful. so far there is no indication that this will help finding + the actual issue + <gnu_srs> The problem is not file descriptors. It is that an ongoing read + suddenly returns -1 bytes read. And then the ruby code assigns a negative + file descriptor in the exception handling. + <youpi> a *read* ? + <youpi> with errno == 0 ? + <gnu_srs> Yes, a read! + <youpi> how ruby comes to assigning a negative fd from that? + <youpi> does it somehow close the fd? + <gnu_srs> The errno reported from the read is EBADF! + <youpi> did you try to rpctrace it? + <gnu_srs> I don't bother too much about ruby exception handling. The error + has already happened in the read operation. And that lead me to eglibc + code.... and so on... + <youpi> do you know what kind of file this fd was supposed to be on? + <youpi> sure, that's debugging + <gnu_srs> Yes I did rpctrace, but that was not successful. rpctrace just + hang! Buggy code? + <antrik> youpi: I assume that's Ruby's way to indicate that the FD is not + valid anymore, after the previous error + <youpi> does the program fork? + <youpi> antrik: possibly + <youpi> rpctrace has known issues, yes + <youpi> gnu_srs: did you trace close()s by hand with printfs? + <gnu_srs> Ho w to find out if it forks? + <youpi> what does rpctrace stop on ? + <gnu_srs> Well, I don't remember. Antrik? + <antrik> proc_dostop() IIRC + <antrik> or something like that + <gnu_srs> I did not find any close() statements in the code I debugged. + <youpi> ok, proc_dostop() is typically a sign of fork() + <youpi> gnu_srs: that doesn't necessarily mean it's not called + <antrik> gnu_srs: I think his point is that something else might close the + FD, causing the error you see + <youpi> anything can happen in the wild :) + <antrik> gnu_srs: as I said before, the next step is to find out what this + FD is, and what happens to it... + <gnu_srs> antrik: Any ideas how to find out? + <youpi> what is the backtrace? + <gnu_srs> Well I know the fd number, it is either 3 or 5 in my tests. Does + the number matter? + <youpi> yes, it's not std{in,out,err} + <gnu_srs> How to get a backtrace of a program that does not hang? + <youpi> make it hang at the point of failure + <youpi> when read returns -1 + <youpi> so you know who did the read + <gnu_srs> I have to run the loop several times before the number of bytes + read is -1. + <youpi> you mean running the program several times ? + <youpi> or just let the loop continue for some time? + <pinotree> if it's the latter, you can add breakpoints with conditions + <gnu_srs> No the read loop runs for 7 iterations, and fails the 8th time! + <youpi> then make it hang when read() returns -1 + <Mr_Spock> could you paste your code somewhere? + <youpi> when debugging, you're allowed to do all kinds of ugly things, you + know ;) + <gnu_srs> OK, I'll try that. + <gnu_srs> MR_Spock: The easiest way would be to try to build + ruby1.9.1. Then I can help you from where it fails. + <gnu_srs> pinotree: How to give a breakpoint with a condition? + <pinotree> break where if condition + <youpi> see help break + <youpi> oh, there's even a thread condition nowadays, good + <gnu_srs> Thanks for the discussion. I have to get into the real world for + a while now. To be continued. + <antrik> gnu_srs: well, if you already know that the loop runs several + times before the error occurs, you apparently already looked at the + higher-level code that is relevant here... + <youpi> but it may be generic code, and not tell what calls it diff --git a/open_issues/some_todo_list.mdwn b/open_issues/some_todo_list.mdwn index 5f8470b7..1f6f5002 100644 --- a/open_issues/some_todo_list.mdwn +++ b/open_issues/some_todo_list.mdwn @@ -51,7 +51,6 @@ From Marcus, 2002: * Are all inode numbers and link counts correct? * We also should have a "make check" test suite. We can add this once Jeff finished his automake patches * pick up the other things - * pthread, definitely. Now that we are so close * new console is basically done * needs integration of course * X switching support diff --git a/open_issues/strict_aliasing.mdwn b/open_issues/strict_aliasing.mdwn new file mode 100644 index 00000000..b7d39805 --- /dev/null +++ b/open_issues/strict_aliasing.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2012 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_gnumach open_issue_hurd open_issue_mig]] + + +# IRC, freenode, #hurd, 2012-07-04 + + <braunr> we should perhaps build the hurd with -fno-strict-aliasing, + considering the number of warnings i can see during the build :/ + <pinotree> braunr: wouldn't be better to "just" fix the mig-generated stubs + instead? + <braunr> pinotree: if we can rely on gcc for the warnings, yes + <braunr> but i suspect there might be other silent issues in very old code + + +# IRC, freenode, #hurd, 2012-07-12 + + <braunr> btw, i'm building glibc right now, and i can see a few strict + aliasing warnings + <braunr> fixing them will allow us to avoid wasting time on very obscure + issues (if gcc catches them all) + <tschwinge> The strict aliasing things should be fixed, yes. Some might be + from MIG. 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/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn new file mode 100644 index 00000000..eae98077 --- /dev/null +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -0,0 +1,39 @@ +[[!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 +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_hurd]] + +Also filed as [[!GNU_Savannah_bug 29292]]. + +\#hurd, 2010, end of May / beginning of June + + [runnign sync, but sill unclean filesystem at next boot] + <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request + and waits (if the synchronous argument was specified) for a + m_o_lock_completed. But m_o_lock_completed only means that dirty pages + have been sent to the translator, and this one still needs to write them + to the backing storage + <slpz> guillem: there's no problem if sync() returns before actually + writting the changes to disk, but this also happens when shutting down + the translator + <slpz> guillem: in theory, locking mechanisms in libpager should prevent + this from happening by keeping track of write operations, but this seems + to fail in some situations + +It helps a lot to run [[`syncfs --synchronous /`|hurd/syncfs]] before issuing +the `halt` or `reboot` command. This will prevent most of the uncleanliness. +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 filesystems as read-only: +<http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html>. + +A patch was applied, and the sync issue does not seem to happen any more. diff --git a/open_issues/synchronous_ipc.mdwn b/open_issues/synchronous_ipc.mdwn new file mode 100644 index 00000000..53d5d69d --- /dev/null +++ b/open_issues/synchronous_ipc.mdwn @@ -0,0 +1,185 @@ +[[!meta copyright="Copyright © 2012 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, 2012-07-20 + +From [[Genode RPC|microkernel/genode/rpc]]. + + <braunr> assuming synchronous ipc is the way to go (it seems so), there is + still the need for some async ipc (e.g signalling untrusted recipients + without risking blocking on them) + <braunr> 1/ do you agree on that and 2/ how would this low-overhead async + ipc be done ? (and 3/ are there relevant examples ? + <antrik> if you think about this stuff too much you will end up like marcus + and neal ;-) + <braunr> antrik: likely :) + <antrik> the truth is that there are various possible designs all with + their own tradeoffs, and nobody can really tell which one is better + <braunr> the only sensible one i found is qnx :/ + <braunr> but it's still messy + <braunr> they have what they call pulses, with a strictly defined format + <braunr> so it's actually fine because it guarantees low overhead, and can + easily be queued + <braunr> but i'm not sure about the format + <antrik> I must say that Neal's half-sync approach in Viengoos still sounds + most promising to me. it's actually modelled after the needs of a + Hurd-like system; and he thought about it a lot... + <braunr> damn i forgot to reread that + <braunr> stupid me + <antrik> note that you can't come up with a design that allows both a) + delivering reliably and b) never blocking the sender -- unless you cache + in the kernel, which we don't want + <antrik> but I don't think it's really necessary to fulfill both of these + requirements + <antrik> it's up to the receiver to make sure it gets important signals + <braunr> right + <braunr> caching in the kernel is ok as long as the limit allows the + receiver to handle its signals + <antrik> in the Viengoos approach, the receiver can allocate a number of + receive buffers; so it's even possible to do some queuing if desired + <braunr> ah great, limits in the form of resources lent by the receiver + <braunr> one thing i really don't like in mach is the behaviour on full + message queues + <braunr> blocking :/ + <braunr> i bet the libpager deadlock is due to that + +[[libpager_deadlock]]. + + <braunr> it simply means async ipc doesn't prevent at all from deadlocks + <antrik> the sender can set a timeout. blocking only happens when setting + it to infinite... + <braunr> which is commonly the case + <antrik> well, if you see places where blocking is done but failing would + be more appropriate, try changing them I'd say... + <braunr> it's not that easy :/ + + +# IRC, freenode, #hurd, 2012-08-18 + + <lcc> what is the deepest design mistake of the HURD/gnumach? + <braunr> lcc: async ipc + <savask> braunr: You mentioned that moving to L4 will create problems. Can + you name some, please? + <savask> I thought it was going to be faster on L4 + <braunr> the problem is that l4 *only* provides sync ipc + <braunr> so implementing async communication would require one seperated + thread for each instance of async communication + <savask> But you said that the deepest design mistake of Hurd is asynch + ipc. + <braunr> not the hurd, mach + <braunr> and hurd depends on it now + <braunr> i said l4 provides *only* sync ipc + <braunr> systems require async communication tools + <braunr> but they shouldn't be built entirely on top of them + <savask> Hmm, so you mean mach has bad asynch ipc? + <braunr> you can consider mach and l4 as two extremes in os design + <braunr> mach *only* has async ipc + <lcc> what was viengoos trying to explore? + * savask is confused + <braunr> lcc: half-sync ipc :) + <braunr> lcc: i can't tell you more on that, i need to understand it better + myself before any explanation attempt + <savask> You say that mach problem is asynch ipc. And L4's problem is it's + sync ipc. That means problems are in either of them! + <braunr> exactly + <lcc> how did apple resolve issues with mach? + <savask> What is perfect then? A "golden middle"? + <braunr> lcc: they have migrating threads, which make most rpc behave as if + they used sync ipc + <braunr> savask: nothing is perfect :p + <mcsim> braunr: but why async ipc is the problem? + <braunr> mcsim: it requires in-kernel buffering + <savask> braunr: Yes, but we can't have problems everywhere o_O + <braunr> mcsim: this not only reduces communication performance, but + creates many resource usage problems + <braunr> mcsim: and potential denial of service, which is what we + experience most of the time when something in the hurd fails + <braunr> savask: there are problems we can live with + <mcsim> braunr: But this could be replaced by userspace server, isn't it? + <braunr> savask: this is what monolithic kernels do + <braunr> mcsim: what ? + <braunr> mcsim: this would be the same, this central buffering server would + suffer from the same kind of issue + <mcsim> braunr: async ipc. Buffer can hold special server + <mcsim> But there could be created several servers, and queue could have + limit. + <braunr> queue limits are a problem + <braunr> when a queue limit is reached, you either block (= sync ipc) or + lose a message + <braunr> to keep messaging reliable, mach makes senders block + <braunr> the problem is that async ipc is often used to avoid blocking + <braunr> so blocking when you don't expect it can create deadlocks + <braunr> savask: a good compromise is to use sync ipc most of the time, and + async ipc for a few special cases, like signals + <braunr> this is what okl4 does if i'm right + <braunr> i'm not sure of the details, but like many other projects they + realized current systems simply need good support for async ipc, so they + extended l4 or something on top of it to provide it + <braunr> it took years of research for very smart people to get to some + consensus like "sync ipc is better but async is needed too" + <braunr> personaly i don't like l4 :/ + <braunr> really not + <mcsim> braunr: Anyway there is some queue for messaging, but at the moment + if it overflows panics kernel. And with limited queue servers will panic. + <braunr> mcsim: it can't overflow + <braunr> mach blocks senders + <braunr> queuing basically means "block and possible deadlock" or "lose + messages and live with it" + <mcsim> So, deadlocks are still possible? + <braunr> of course + <braunr> have a look at the libpager debian patch and the discussion around + it + <braunr> it's a perfect example + <youpi> braunr: it makes gnu mach slow as hell sometimes, which I guess is + because all threads (which can ben 1000s) wake at the same time + <braunr> youpi: you mean are created ? + <braunr> because they'll have to wake in any case + <braunr> i can understand why creating lots of threads is slower, but + cthreads never destroyes kernel threads + <braunr> doesn't seem to be a mach problem, rather a cthreads one + <braunr> i hope we're able to remove the patch after pthreads are used + +[[libpthread]]. + + <mcsim> braunr: You state that hurd can't move to sync ipc, since it + depends on async ipc. But at the same time async ipc doesn't guarantee + that task wouldn't block. So, I don't understand why limited queues will + lead to more deadlocks? + <braunr> mcsim: async ipc can block because of queue limits + <braunr> mcsim: if you remove the limit, you remove the deadlock problem, + and replace it with denial of service + <braunr> mcsim: i didn't say the hurd can't move to sync ipc + <braunr> mcsim: i said it came to depend on async ipc as provided by mach, + and we would need to change that + <braunr> and it's tricky + <youpi> braunr: no, I really mean are woken. The timeout which gets dropped + by the patch makes threads wake after some time, to realize they should + go away. It's a hell long when all these threads wake at the same time + (because theygot created at the same time) + <braunr> ahh + + <antrik> savask: what is perfect regarding IPC is something nobody can + really answer... there are competing opinions on that matter. but we know + by know that the Mach model is far from ideal, and that the (original) L4 + model is also problematic -- at least for implementing a UNIX-like system + <braunr> personally, if i'd create a system now, i'd use sync ipc for + almost everything, and implement posix-like signals in the kernel + <braunr> that's one solution, it's not perfect + <braunr> savask: actually the real answer may be "noone knows for now and + it still requires work and research" + <braunr> so for now, we're using mach + <antrik> savask: regarding IPC, the path explored by Viengoos (and briefly + Coyotos) seems rather promising to me + <antrik> savask: and yes, I believe that whatever direction we take, we + should do so by incrementally reworking Mach rather than jumping to a + completely new microkernel... diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn new file mode 100644 index 00000000..19cba82e --- /dev/null +++ b/open_issues/syslog.mdwn @@ -0,0 +1,107 @@ +[[!meta copyright="Copyright © 2010, 2011, 2012 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]] + +[[!toc]] + +# IRC, unknown channel, unknown date + + <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 + I see that you intend(ed) to use syslog for logging debug messages. I + thought I'd point you to + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no + idea if that's still an issue or what went wrong at that time. Perhaps + you can have a look? + <scolobb> tschwinge: Thanks for information! Currently I'm logging some + debug messages to a simple file, but I'll now check whether the issue + you've pointed out is still present. + <scolobb> tschwinge: I am getting absolutely abnormal results: when I call + syslog() from a simple C program for the first time, the message goes to + the system log. However, any further calls to syslog() do just + nothing... I am able to send something to syslog only after reboot (it + doesn't help if I restart syslogd). + + +# IRC, freenode, #hurd, 2011-08-08 + + < pinotree> wow, `logger` + a simple C udp server can cause havoc + < pinotree> youpi: ever seen something like + http://paste.debian.net/hidden/72cf4b77/ ? + < pinotree> and then also other servers (like pflocal, pfinet, few more) + start becoming crazy (using 100% cpu) + < youpi> nope + < pinotree> iirc in one of the few tries i got the message "Resource lost." + from the closed ssh connection + < pinotree> i was trying to see why syslog doesn't work, but this basically + surprised me... + < pinotree> oh, i found an apparently working syslog daemon + < pinotree> dsyslog + < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by + default. + < pinotree> yeah, it seems to stop receiving messages are few + < pinotree> gg0: are you using syslog-ng? + < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched + busybox syslog, I don't even know if it works, at least it starts + http://bugs.debian.org/636162 + < pinotree> maintainer said "not really" + < gg0> well, if all other syslogs use shm and sems, they won't work too, + right? + < youpi> shm should work with the latest libc + < youpi> what won't is sysv sem + < youpi> (i.e. semget) + + +IRC, OFTC, #debian-hurd, 2011-11-02: + + * pinotree sighs at #645790 :/ + <tschwinge> pinotree: W.r.t. 645790 -- yeah, ``someone'' should finally + figure out what's going on with syslog. + http://lists.gnu.org/archive/html/bug-hurd/2008-07/msg00152.html + <tschwinge> pinotree: And this... + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html + <pinotree> tschwinge: i did that 20 invocations tests recently, and + basically none of them has been logged + <pinotree> tschwinge: when i started playing with logger more, as result i + had some server that started taking all the cpu, followed by other + servers and in the end my ssh connection were dropped and i had nothing + to do (not even login from console) + <tschwinge> pinotree: Sounds like ``fun''. Hopefully we can manage to + understand (and fix the underlying issue) why a simple syslog() + invocation can make the whole system instable. + <pinotree> tschwinge: to be honest, i got havoc in the system when i told + syslog to manually look for /dev/log (-u /dev/log), possibly alao when + telling to use a datagram socket (-d) + <pinotree> but even if a normal syslog() invocation does not cause havoc, + there's still the "lost messages" issue + <tschwinge> Yep. What I've been doing ever since, is deinstall all + *syslog* packages. + <tschwinge> This ``fixed'' all syslog() hangs. + + +# IRC, freenode, #hurd, 2012-03-28 + + <braunr> i can see lots of CRON processes hanging around + <braunr> pinotree: crontab -l was hanging too when trying to quickly see + what went wrong + <braunr> so it may be an unreleased lock of some kind + <antrik> braunr: do you have syslog installed by any chance?... + <antrik> IIRC that bug has never been fixed :-( + <braunr> yes syslogd is running + <antrik> that's probably the culprit then + <braunr> ok + <braunr> i'll just disable it for now then + <antrik> the error has existed for years + <antrik> was similar for me though: for a long time I have been hearing + about this issue, and only suddenly I started experiencing it myself... + <antrik> it depends on how many things are actually logged. IIRC the hang + happens when some client sends 128 messages to syslog or something like + that diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn new file mode 100644 index 00000000..68418097 --- /dev/null +++ b/open_issues/system_call_mechanism.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2011, 2012 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]] + +[[!toc]] + + +# IRC, freenode, #hurd, 2011-05-07 + + <braunr> very simple examples: system calls use old call gates, which are + the slowest path to kernel space + <braunr> modern processors have dedicated instructions now + + +# IRC, freenode, #hurd, 2012-04-22 + + <braunr> rah: basically, system calls are slower on mach because they use + call gates instead of newer sysenter/sysexit + <youpi> braunr: sysenter/exit is a x86_64 thing + <braunr> rah: apart from that, the code can't get much simpler, and *I* + know, for i have studied it, and wrote a compatible version in a clone + attempt + <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit + <braunr> youpi: no there are 32-bits instructions, i don't remember if + they're called sysenter, it's in my thesis though so i'm sure of it :) + <youpi> braunr: ah, the other part + <youpi> is linux-x86 using them? + <braunr> youpi: yes, glibc uses them + <youpi> and does it really change much nowadays? + <youpi> what is the actual difference between int 80 and sysenter? + <braunr> less checking + <youpi> checking what? + <youpi> the idt? + <braunr> ring levels for example + <youpi> well, checking a ring is fast :) + <braunr> depending on the original and requested levels, there are lookups + in tables + <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit + <youpi> ah, also it assumes things about segments + <youpi> so that indeed makes context things simpler + <braunr> right + <braunr> but mach doesn't uses int 0x80 + <braunr> it uses an lcall + <braunr> which is a bit slower from what I could read some time ago + <braunr> (not sure if it's still relevant) + <youpi> actually in 64bit mode I had to catch lcall from the invalid + instruction trap + <youpi> perhaps it got dropped in 64bit mode 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/system_initialization.mdwn b/open_issues/system_initialization.mdwn new file mode 100644 index 00000000..9048b615 --- /dev/null +++ b/open_issues/system_initialization.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_hurd]] + +IRC, freenode, #hurd, 2011-03-30 + + <kilobug> init=/bin/sh hack doesn't work for GNU/Hurd ? + <antrik> kilobug: I don't think you can override init on Hurd. the init + server is actually involved in bootstrapping part of the system core + <antrik> at some point we discussed the possibility to reduce the Hurd init + server to *only* do that, and then pass on to standard sysv init... with + that it could actually work + +--- + + * [[systemd]], etc. diff --git a/open_issues/system_stats.mdwn b/open_issues/system_stats.mdwn new file mode 100644 index 00000000..9a13b29a --- /dev/null +++ b/open_issues/system_stats.mdwn @@ -0,0 +1,39 @@ +[[!meta copyright="Copyright © 2012 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]]There should be a page listing ways to get +system statistics, how to interpret them, and some example/expected values. + + +# IRC, frenode, #hurd, 2012-11-04 + + <mcsim> Hi, is that normal that memory cache "ipc_port" is 24 Mb already? + Some memory has been already swapped out. + <mcsim> Other caches are big too + <braunr> how many ports ? + <mcsim> 45922 + <braunr> yes it's normal + <braunr> ipc_port 0010 76 4k 50 45937 302050 + 24164k 4240k + <braunr> it's a bug in exim + <braunr> or triggered by exim, from time to time + <braunr> lots of ports are created until the faulty processes are killed + <braunr> the other big caches you have are vm_object and vm_map_entry, + probably because of a big build like glibc + <braunr> and if they remain big, it's because there was no memory pressure + since they got big + <braunr> memory pressure can only be caused by very large files on the + hurd, because of the limited page cache size (4000 objects at most) + <braunr> the reason you have swapped memory is probably because of a glibc + test that allocates a very large (more than 1.5 GiB iirc) block and fills + it + <mcsim> yes + <braunr> (a test that fails with the 2G/2G split of the debian kernel, but + not on your vanilla version btw) diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn new file mode 100644 index 00000000..1d774307 --- /dev/null +++ b/open_issues/systemd.mdwn @@ -0,0 +1,150 @@ +[[!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 +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_porting]] + + * <http://www.freedesktop.org/wiki/Software/systemd> + + * <http://0pointer.de/blog/projects/systemd.html>, + <http://0pointer.de/blog/projects/systemd-update.html> + + * <http://lwn.net/Articles/389149/> + +Will need to have something like Linux' +[*cgroups*](http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/cgroups.txt;hb=HEAD). +Introduction: [*Ressourcen-Verwaltung mit Control Groups (cgroups)* +(german)](http://www.pro-linux.de/artikel/2/1464/ressourcen-verwaltung-mit-control-groups-cgroups.html), +Daniel Gollub, Stefan Seyfried, 2010-10-14. + +Likely there's also some other porting needed. + + +# IRC, OFTC, #debian-hurd, 2011-05-19 + + <pinotree> pochu: http://news.gmane.org/gmane.comp.gnome.desktop - the + "systemd as dependency" and all the messages in it don't give me a bright + future for gnome on hurd... + <pochu> yeah, I've read the thread + <pochu> it's only a proposal so far... hopefully it'll be rejected, or they + will only accept the interfaces that other OSes can implement... + <pochu> we'll see + <pinotree> you can always help me with kde on hurd, would be nice ;) + <pochu> hehe + <pinotree> pochu: well, even if the depenency is rejected, the whole «don't + give a damn about non-linux and only bless linux for the "gnome os"» is a + bit... worrying attitude + <pochu> yeah... it doesn't come from all the community though + <pochu> I'm sure some people have always thought that way + <tschwinge> Or we could get systemd going? :-) + <pochu> good luck with that :p + <guillem> tschwinge: haha!? :) + <tschwinge> That bad? + <guillem> tschwinge: if you mean by that forking indefinitely then maybe + <guillem> tschwinge: upstream has expressely stated multiple times, no + interest whatsoever in any kind of portability to anything non-Linux + <guillem> or even older Linux versions! + <guillem> to the point of rejecting patches, because they "clutter" the + source code... + <tschwinge> Well, then let's ``just'' implement the Linux interfaces. :-) + <guillem> tschwinge: then you'll be always playing catch up + <guillem> tschwinge: for example several of the Linux-only things upstream + makes heavy use of, are pretty recent Linux-only additions to the kernel, + but equivalents have been present on FreeBSD for years + <tschwinge> Yeah. I'm half-serious, half-joking. + <tschwinge> I haven't looked at the systemd code at all. + <guillem> + https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html + for a list of its dependencies + <guillem> some are just glibc extensions though + <guillem> and some are IMO optional and should be conditionalized, but... + <guillem> pochu: I don't think that attitude is that old, there was a time + when Linux was not used widely, or even that functional, I think it has + been taking strength since the Linux Plumbers Cartel started :) + <guillem> as in one thing is not caring about anything non-Linux, the other + is outright rejecting portability fixes + <guillem> tschwinge: in any case, these "recent" events are "pissing me + off" to the point of having considered several times implementing + portable replacements for some of those Utopia projects, the problem as + always is time though :) + <guillem> tschwinge: and the issue is not only with systemd, upstart's + upstream has the same approach to portability, if you want to port it, + you'll have to maintain a fork + <pochu> let's create our own init system, make it better than anyone else, + and when people start switching to it, let's start using hurd-only APIs + :) + <tschwinge> We already had someone work on that. Like ten years ago. DMD. + Daemon Managing Daemons. <http://directory.fsf.org/project/DMD/> + <guillem> the real problem with that attitude is not the lack of care for + portabilty, the real problem is that these people are pushing for their + stuff all over the stack, and most of the time deprecating their own + stuff after a while when they have rewritten it from scratch, leaving the + burden of maintaining the old stuff to the other ports + <guillem> witness HAL, ConsoleKit, etc etc + <guillem> (anyway enough ranting I guess :) + <tschwinge> Yeah, it's true, though. + <pochu> agreed + + +# Requires Interfaces + +In the thread starting +[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a +[message](http://lists.debian.org/debian-devel/2011/07/msg00281.html) has been +posted that contains the following list (no claim for completeness) of +interfaces that are used in (two source code files of) systemd: + + * cgroups + * namespaces + * selinux + * autofs4 + * capabilities + * udev + * oom score adjust + * RLIMIT_RTTIME + * RLIMIT_RTPRIO + * ionice + * SCHED_RESET_ON_FORK + * /proc/$PID/stat + * fanotify + * inotify + * TIOCVHANGUP + * IP_TRANSPORT + * audit + * F_SETPIPE_SZ + * CLONE_xxx + * BTRFS_IOC_DEFRAG + * PR_SET_NAME + * PR_CAPBSET_DROP + * PR_SET_PDEATHSIG + * PR_GET_SECUREBITS + * /proc/$PID/comm + * /proc/$PID/cmdline + * /proc/cmdline + * numerous GNU APIs like asprintf + * SOCK_CLOEXEC, O_CLOEXEC + * /proc/$PID/fd + * /dev/tty0 + * TIOCLINUX + * VT_ACTIVATE + * TIOCNXCL + * KDSKBMODE + * /dev/random + * /dev/char/ + * openat() and friends + * /proc/$PID/root + * waitid() + * /dev/disk/by-label/ + * /dev/disk/by-uuid/ + * /sys/class/tty/console/active + * /sys/class/dmi/id + * /proc/$PID/cgroup + * \033[3J + * /dev/rtc + * settimeofday() and its semantics diff --git a/open_issues/term_blocking.mdwn b/open_issues/term_blocking.mdwn new file mode 100644 index 00000000..0ed0b4df --- /dev/null +++ b/open_issues/term_blocking.mdwn @@ -0,0 +1,318 @@ +[[!meta copyright="Copyright © 2009, 2011, 2012 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]] + +There must be some blocking / dead-locking (?) problem in `term`. + +[[!toc]] + + +# Original Findings + + # w | grep [t]sch + tschwing p1 192.168.10.60: Tue 8PM 0:03 2172 /bin/bash + tschwing p2 192.168.10.60: Tue 4PM 40hrs 689 emacs + tschwing p3 192.168.10.60: 8:52PM 11:37 15307 /bin/bash + tschwing p0 192.168.10.60: 6:42PM 11:47 8104 /bin/bash + tschwing p8 192.168.10.60: 8:27AM 0:02 16510 /bin/bash + +Now open a new screen window, or login shell, or... + + # ps -Af | tail + [...] + tschwinge 16538 676 p6 0:00.08 /bin/bash + root 16554 128 co 0:00.09 ps -Af + root 16555 128 co 0:00.01 tail + +`bash` is started (on `p6`), but newer makes it to the shell promt; doesn't +even start to execute `.bash_profile` / `.bashrc`. The next shell started, on +the next available pseudoterminal, will work without problems. + +The `term` on `p6` has already been running before: + + # ps -Af | grep [t]typ6 + root 6871 3 - 5:45.86 /hurd/term /dev/ptyp6 pty-master /dev/ttyp6 + +In this situation, `w` will sometimes report erroneous values for *IDLE* +for the process using that terminal. + +Killed that `term` instance, and things were fine again. + + +All this reproducible happens while running the [[GDB testsuite|gdb]]. + +--- + +Have a freshly started shell blocking on such a `term` instance. + + $ ps -F hurd-long -p 1766 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 1766 0 3 1 1 6 131M 1.14M 0.0 0:28.85 5:40.91 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:05.76 1:08.48 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:06.40 1:11.52 + 3 0.0 0:05.76 1:09.89 + 4 0.0 0:05.42 1:06.74 + 5 0.0 0:05.50 1:04.25 + +... and after 5:45 h: + + $ ps -F hurd-long -p 21987 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 21987 1001 676 21987 21987 2 148M 2.03M 0.0 0:00.02 0:00.07 /bin/bash + 0 0.0 0:00.02 0:00.07 + 1 0.0 0:00.00 0:00.00 + + $ ps -F hurd-long -p 1766 -T -Q + PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args + 1766 0 3 1 1 6 131M 1.14M 0.0 0:29.04 5:42.38 /hurd/term /dev/ptyp3 pty-master /dev/ttyp3 + 0 0.0 0:05.76 1:08.48 + 1 0.0 0:00.00 0:00.01 + 2 0.0 0:06.41 1:11.90 + 3 0.0 0:05.82 1:10.28 + 4 0.0 0:05.52 1:07.06 + 5 0.0 0:05.52 1:04.63 + + $ sudo gdb /hurd/term 1766 + [sudo] password for tschwinge: + GNU gdb (GDB) 7.0-debian + Copyright (C) 2009 Free Software Foundation, Inc. + License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. Type "show copying" + and "show warranty" for details. + This GDB was configured as "i486-gnu". + For bug reporting instructions, please see: + <http://www.gnu.org/software/gdb/bugs/>... + Reading symbols from /hurd/term...Reading symbols from /usr/lib/debug/hurd/term...done. + (no debugging symbols found)...done. + Attaching to program `/hurd/term', pid 1766 + [New Thread 1766.1] + [New Thread 1766.2] + [New Thread 1766.3] + [New Thread 1766.4] + [New Thread 1766.5] + [New Thread 1766.6] + Reading symbols from /lib/libhurdbugaddr.so.0.3...Reading symbols from /usr/lib/debug/lib/libhurdbugaddr.so.0.3... + [System doesn't respond anymore, but no kernel crash.] + +--- + +The very same behavior is still observable as of 2011-03-24. + +Next: rebooted; on console started root shell, screen, a few spare windows; as +user started GDB test suite, noticed the PTY it's using; in a root shell +started GDB (the system one, for `.debug` stuff) on `/hurd/term`, `set +noninvasive on`, attach to the *term* that GDB is using. + +--- + +[[2011-07-04]]. + +--- + +2012-11-05 + +Log file from a 2011-09-07 run: + + [...] + Running ../../../master/gdb/testsuite/gdb.base/readline.exp ... + spawn [...]/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory + GNU gdb (GDB) 7.3.50.20110906-cvs + Copyright (C) 2011 Free Software Foundation, Inc. + License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. Type "show copying" + and "show warranty" for details. + This GDB was configured as "i686-unknown-gnu0.3". + For bug reporting instructions, please see: + <http://www.gnu.org/software/gdb/bugs/>. + (gdb) set height 0 + (gdb) set width 0 + (gdb) dir + Reinitialize source path to empty? (y or n) y + Source directories searched: $cdir:$cwd + (gdb) dir ../../../master/gdb/testsuite/gdb.base + Source directories searched: [...]/gdb/testsuite/../../../master/gdb/testsuite/gdb.base:$cdir:$cwd + (gdb) p 1 + $1 = 1 + PASS: gdb.base/readline.exp: Simple operate-and-get-next - send p 1 + (gdb) p 2 + $2 = 2 + PASS: gdb.base/readline.exp: Simple operate-and-get-next - send p 2 + (gdb) p 3 + $3 = 3 + PASS: gdb.base/readline.exp: Simple operate-and-get-next - send p 3 + (gdb) p 3(gdb) p 3PASS: gdb.base/readline.exp: Simple operate-and-get-next - C-p to p 3 + ^H2(gdb) p 2PASS: gdb.base/readline.exp: Simple operate-and-get-next - C-p to p 2 + ^H1(gdb) p 1PASS: gdb.base/readline.exp: Simple operate-and-get-next - C-p to p 1 + ^OFAIL: gdb.base/readline.exp: Simple operate-and-get-next - C-o for p 1 + FAIL: gdb.base/readline.exp: operate-and-get-next with secondary prompt - send if 1 > 0 + FAIL: gdb.base/readline.exp: print 42 (timeout) + FAIL: gdb.base/readline.exp: arrow keys with secondary prompt (timeout) + spawn [...]/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory + ERROR: (timeout) GDB never initialized after 10 seconds. + ERROR: no fileid for coulomb + ERROR: no fileid for coulomb + UNRESOLVED: gdb.base/readline.exp: Simple operate-and-get-next - send p 7 + testcase ../../../master/gdb/testsuite/gdb.base/readline.exp completed in 646 seconds + Running ../../../master/gdb/testsuite/gdb.base/wchar.exp ... + Executing on host: gcc -c -g -o [...]/gdb/testsuite/gdb.base/wchar0.o ../../../master/gdb/testsuite/gdb.base/wchar.c (timeout = 300) + spawn gcc -c -g -o [...]/gdb/testsuite/gdb.base/wchar0.o ../../../master/gdb/testsuite/gdb.base/wchar.c + Executing on host: gcc [...]/gdb/testsuite/gdb.base/wchar0.o -g -lm -o [...]/gdb/testsuite/gdb.base/wchar (timeout = 300) + spawn gcc [...]/gdb/testsuite/gdb.base/wchar0.o -g -lm -o [...]/gdb/testsuite/gdb.base/wchar + get_compiler_info: gcc-4-6-1 + spawn [...]/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory [...]/gdb/testsuite/../data-directory + ERROR: (timeout) GDB never initialized after 10 seconds. + ERROR: no fileid for coulomb + ERROR: no fileid for coulomb + ERROR: no fileid for coulomb + ERROR: couldn't load [...]/gdb/testsuite/gdb.base/wchar into [...]/gdb/testsuite/../../gdb/gdb (timed out). + ERROR: no fileid for coulomb + ERROR: Delete all breakpoints in delete_breakpoints (timeout) + ERROR: no fileid for coulomb + UNRESOLVED: gdb.base/wchar.exp: setting breakpoint at wchar.c:34 (timeout) + testcase ../../../master/gdb/testsuite/gdb.base/wchar.exp completed in 797 seconds + [...] + + +# IRC, freenode, #hurd, 2012-08-09 + +In context of the [[select]] issue. + + <braunr> i wonder where the tty allocation is made + <braunr> it could simply be that current applications don't handle old BSD + ptys correctly + <braunr> hm no, allocation is fine + <braunr> does someone know why there is no term instance for /dev/ttypX ? + <braunr> showtrans says "/hurd/term /dev/ttyp0 pty-slave /dev/ptyp0" though + <youpi> braunr: /dev/ttypX share the same translator with /dev/ptypX + <braunr> youpi: but how ? + <youpi> see the main function of term + <youpi> it attaches itself to the other node + <youpi> with file_set_translator + <youpi> just like pfinet can attach itself to /servers/socket/26 too + <braunr> youpi: isn't there a possible race when the same translator tries + to sets itself on several nodes ? + <youpi> I don't know + <tschwinge> There is. + <braunr> i guess it would just faikl + <braunr> fail + <tschwinge> I remember some discussion about this, possibly in context of + the IPv6 project. + <braunr> gdb shows weird traces in term + <braunr> i got this earlier today: http://www.sceen.net/~rbraun/gdb.txt + <braunr> 0x805e008 is the ptyctl, the trivs control for the pty + <tschwinge> braunr: How do you mean »weird«? + <braunr> tschwinge: some peropen (po) are never destroyed + <tschwinge> Well, can't they possibly still be open? + <braunr> they shouldn't + <braunr> that's why term doesn't close cleany, why select still reports + readiness, and why screen loops on it + <braunr> (and why each ssh session uses a different pty) + <tschwinge> ... but only on darnassus, I think? (I think I haven't seen + this anywhere else.) + <braunr> really ? + <braunr> i had it on my virtual machines too + <tschwinge> But perhaps I've always been rebooting systems quickly enough + to not notice. + <tschwinge> OK, I'll have a look next time I boot mine. + <braunr> i suppose it's why you can't login anymore quickly when syslog is + running + +[[syslog]]? + + <braunr> i've traced the problem to ptyio.c, where pty_open_hook returns + EBUSY because ptyopen is still true + <braunr> ptyopen remains true because pty_po_create_hook doesn't get called + <youpi> tschwinge: I've seen the pty issue on exodar too, and on my qemu + image too + <braunr> err, pty_po_destroy_hook + <tschwinge> OK. + <braunr> and pty_po_destroy_hook doesn't get called from users.c because + po->cntl != ptyctl + <braunr> which means, somehow, the pty never gets closed + <youpi> oddly enough it seems to happen on all qemu systems I have, and no + xen system I have + <braunr> Oo + <braunr> are they all (xen and qemu) up to date ? + <braunr> (so we can remove versions as a factor) + <tschwinge> Aha. I only hve Xen and real hardware. + <youpi> braunr: no + <braunr> youpi: do you know any obscur site about ptys ? :) + <youpi> no + <youpi> well, actually yes + <youpi> http://dept-info.labri.fr/~thibault/a (in french) + <braunr> :D + <braunr> http://www.linusakesson.net/programming/tty/index.php looks + interesting + <youpi> indeed + + +## IRC, freenode, #hurdfr, 2012-08-09 + + <braunr> youpi: ce que j'ai le plus de mal à comprendre, c'est ce qu'est un + "controlling tty" + <youpi> c'est le plus obscur d'obscur :) + <braunr> s'il est exclusif à une appli, comment ça doit se comporter sur un + fork, etc.. + <youpi> de manière simple, c'est ce qui permet de faire ^C + <braunr> eh oui, et c'est sûrement là que ça explose + <youpi> c'est pas exclusif, c'est hérité + <braunr> + http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/bernstein-on-ttys/cttys.html + + +## IRC, freenode, #hurd, 2012-08-10 + + <braunr> youpi: and just to be sure about the test procedure, i log on a + system, type tty, see e.g. ttyp0, log out, and in again, then tty returns + ttyp1, etc.. + <youpi> yes + <braunr> youpi: and an open (e.g. cat) on /dev/ptyp0 returns EBUSY + <youpi> indeed + <braunr> so on xen it doesn't + <braunr> grmbl + <youpi> I've never seen it, more precisely + <braunr> i also have the problem with a non-accelerated qemu + <braunr> antrik: do you have the term problems we've seen on your bare + hardware ? + <antrik> I'm not sure what problem you are seeing exactly :-) + <braunr> antrik: when logging through ssh, tty first returns ttyp0, and the + second time (after logging out from the first session) ttyp1 + <braunr> antrik: and term servers that have been used are then stuck in a + busy state + <antrik> braunr: my ptys seem to be reused just fine + <braunr> or perhaps they didn't have the bug + <braunr> antrik: that's so weird + <antrik> (I do *sometimes* get hanging ptys, but that's a different issue + -- these are *not* busy; they just hang when reused...) + <braunr> antrik: yes i saw that too + <antrik> braunr: note though that my hurd package is many months old... + <antrik> (in fact everything on this system) + <braunr> antrik: i didn't see anything relevant about the term server in + years + <braunr> antrik: what shell do you use ? + <antrik> yeah, but such errors could be caused by all kinds of changes in + other parts of the Hurd, glibc, whatever... + <antrik> bash + + +# Formal Verification + +This issue may be a simple programming error, or it may be more complicated. + +Methods of [[formal_verification]] should be applied to confirm that there is +no error in `/hurd/term`'s logic itself. There are tools for formal +verification/[[code_analysis]] that can likely help here. + +There is a [[!FF_project 277]][[!tag bounty]] on this task. diff --git a/open_issues/term_blocking/2011-07-04.mdwn b/open_issues/term_blocking/2011-07-04.mdwn new file mode 100644 index 00000000..0f302409 --- /dev/null +++ b/open_issues/term_blocking/2011-07-04.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]]."]]"""]] + +GDB testsuite makes a term process go bonkers. The testsuite is terminated. +The term process remanins. Next, a new shell (bash) is started that connects +to this term process -- and hangs. + +Hung bash process (27834), term (22634). + + # portinfo -t 22634 27834 + 5 => 58: receive + 11 => 18: receive + 21 => 53: receive + 26 => 51: receive + 27 => 56: receive + 28 => 48: receive + 30 => 54: receive + +GDB on bash: + + #0 0x010ab12c in _hurd_intr_rpc_msg_in_trap (msg=0x102383c, option=3, send_size=44, rcv_size=2092, rcv_name=9, timeout=0, notify=0) at intr-msg.c:134 + err = <value optimized out> + err = <value optimized out> + user_option = 3 + user_timeout = 0 + m = 0x102383c + msgh_bits = 5395 + remote_port = 27 + msgid = 21001 + __PRETTY_FUNCTION__ = "_hurd_intr_rpc_mach_msg" + #1 0x01235195 in __io_read (io_object=27, data=0x1024148, dataCnt=0x102414c, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/hurd/RPC_io_read.c:138 + Mess = {In = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, offsetType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, + msgt_unused = 0}, offset = -1, amountType = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, amount = 1}, Out = {Head = {msgh_bits = 5395, msgh_size = 1768, msgh_remote_port = 27, + msgh_local_port = 9, msgh_seqno = 0, msgh_id = 21001}, RetCodeType = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0}, RetCode = -1, dataType = {msgtl_header = {msgt_name = 255, + msgt_size = 255, msgt_number = 4095, msgt_inline = 1, msgt_longform = 1, msgt_deallocate = 1, msgt_unused = 1}, msgtl_name = 8194, msgtl_size = 4097, msgtl_number = 1}, + data = "# /etc/inputrc - global inputrc for libreadline\n# See readline(3readline) and `info rluserman' for more information.\n\n# Be 8 bit clean.\nset input-meta on\nset output-meta on\n\n# To allow the use of 8bit"...}} + msg_result = <value optimized out> + msgh_size = <value optimized out> + #2 0x010afbb1 in readfd (port=27) at fd-read.c:34 + nbytes = 0x9 + nread = 40 + data = 0x44 <Address 0x44 out of bounds> + offset = 12884901897 + #3 0x010b5de5 in _hurd_ctty_input (port=26, ctty=27, rpc=0x1024154) at ctty-input.c:36 + err = 19156808 + #4 0x010af53e in _hurd_fd_read (fd=0x1244f48, buf=0x102420f, offset=-1) at fd-read.c:39 + __ulink = {resource = {next = 0x0, prevp = 0x1244f4c}, thread = {next = 0x1024160, prevp = 0x1246c5c}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1a} + __ctty_ulink = {resource = {next = 0x0, prevp = 0x1244f5c}, thread = {next = 0x0, prevp = 0x1024180}, cleanup = 0x10b75a0 <_hurd_port_cleanup>, cleanup_data = 0x1b} + ctty = 27 + crit = 0x1246808 + __result = 16925048 + port = <value optimized out> + err = <value optimized out> + data = 0x102420f "" + nbytes = 0x10241f8 + nread = 1 + #5 0x0116c080 in __libc_read (fd=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece. + ) at ../sysdeps/mach/hurd/read.c:27 + descriptor = <error reading variable descriptor (DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.)> + err = <value optimized out> + #6 0x080cdaac in ?? () + No symbol table info available. + #7 0x080cdf88 in ?? () + No symbol table info available. + #8 0x080baff7 in ?? () + No symbol table info available. + #9 0x080bb435 in ?? () + No symbol table info available. + #10 0x080507e7 in ?? () + No symbol table info available. + #11 0x0804fc36 in ?? () + No symbol table info available. + #12 0x08052f22 in ?? () + No symbol table info available. + #13 0x08055dab in ?? () + No symbol table info available. + #14 0x0804d960 in ?? () + No symbol table info available. + #15 0x0804da1f in ?? () + No symbol table info available. + #16 0x0804dc65 in ?? () + No symbol table info available. + #17 0x0804d215 in ?? () + No symbol table info available. + #18 0x010b906b in __libc_start_main (main=0x804c450, argc=1, ubp_av=0x1024dd4, init=0x80d7ff0, fini=0x80d7fe0, rtld_fini=0xf330, stack_end=0x1024dcc) at libc-start.c:257 + result = <value optimized out> + #19 0x0804b281 in ?? () + No symbol table info available. + +GDB on term: + + 5 Thread 22634.5 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 4 Thread 22634.4 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 3 Thread 22634.3 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 2 Thread 22634.2 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + * 1 Thread 22634.1 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + + Thread 5 (Thread 22634.5): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x129bf10, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x129bf10 + reply = 0x129df20 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x8061460) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x80619a8 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 4 (Thread 22634.4): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x128df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x128df20 + reply = 0x128bf10 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x805f800) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805f788 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 3 (Thread 22634.3): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x127df20, option=2050, send_size=0, rcv_size=8192, rcv_name=16, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae24 in __mach_msg_server_timeout (demux=0x125fd1c, max_size=8192, rcv_name=16, option=2048, timeout=0) at msgserver.c:101 + request = 0x127df20 + reply = 0x127bf10 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x01058e45 in thread_function (master=0) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:136 + timeout = 0 + err = <value optimized out> + hook = 0 + global_timeout = 0 + thread_timeout = 0 + bucket = 0x805e1f0 + lock = 0 + totalthreads = 4 + nreqthreads = 3 + #4 0x01052b91 in cthread_body (self=0x805ec30) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805ebb8 + #5 0x00000000 in ?? () + No symbol table info available. + + Thread 2 (Thread 22634.2): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x126df20, option=3, send_size=32, rcv_size=4096, rcv_name=12, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x0108ae99 in __mach_msg_server_timeout (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12, option=0, timeout=0) at msgserver.c:151 + request = 0x126ef30 + reply = 0x126df20 + mr = <value optimized out> + __PRETTY_FUNCTION__ = "__mach_msg_server_timeout" + #3 0x0108af6b in __mach_msg_server (demux=0x109b9d0 <msgport_server>, max_size=4096, rcv_name=12) at msgserver.c:196 + No locals. + #4 0x0109b99f in _hurd_msgport_receive () at msgportdemux.c:68 + No locals. + #5 0x01052b91 in cthread_body (self=0x805da48) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cthreads.c:300 + t = 0x805d9d0 + #6 0x00000000 in ?? () + No symbol table info available. + + Thread 1 (Thread 22634.1): + #0 0x01089f6c in mach_msg_trap () at /home/buildd/build/chroot-sid/home/buildd/byhand/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + No locals. + #1 0x0108a769 in __mach_msg (msg=0x125ba2c, option=2, send_size=0, rcv_size=24, rcv_name=10, timeout=0, notify=0) at msg.c:110 + ret = <value optimized out> + #2 0x010516b8 in cproc_block () at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cprocs.c:638 + msg = {msgh_bits = 17345214, msgh_size = 18972660, msgh_remote_port = 17163428, msgh_local_port = 134764952, msgh_seqno = 19249824, msgh_id = 18935134} + waiter = 0x1240808 + new = <value optimized out> + p = 0x805d988 + #3 0x01053589 in hurd_condition_wait (m=0x805d89c) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libthreads/cancel-cond.c:86 + p = 0x805d988 + cancel = <value optimized out> + __PRETTY_FUNCTION__ = "hurd_condition_wait" + c = 0x805e498 + #4 0x08052abf in trivfs_S_io_read (cred=0x8084b78, reply=32, replytype=18, data=0x125bb44, datalen=0x125bb40, offset=-1, amount=1) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/users.c:695 + cancel = <value optimized out> + i = <value optimized out> + max = <value optimized out> + cp = <value optimized out> + avail = <value optimized out> + #5 0x0104053b in _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:234 + dataCnt = 2048 + msgh_simple = <value optimized out> + io_object = 0x8084b78 + dataP = 0x125bc8c "\350\003" + #6 _Xio_read (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:148 + In0P = 0x125dc70 + OutP = 0x125bc60 + offsetCheck = {msgt_name = 11, msgt_size = 64, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0} + amountCheck = {msgt_name = 2, msgt_size = 32, msgt_number = 1, msgt_inline = 1, msgt_longform = 0, msgt_deallocate = 0, msgt_unused = 0} + #7 0x0104065e in trivfs_io_server (InHeadP=0x125dc70, OutHeadP=0x125bc60) at ioServer.c:2005 + InP = 0x125dc70 + OutP = 0x125bc60 + routine = <value optimized out> + #8 0x01038f17 in trivfs_demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libtrivfs/demuxer.c:32 + No locals. + #9 0x080537a8 in demuxer (inp=0x125dc70, outp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./term/main.c:68 + No locals. + #10 0x01059045 in internal_demuxer (inp=0x125dc70, outheadp=0x125bc60) at /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libports/manage-multithread.c:101 + err = <value optimized out> + spawn = <value optimized out> + status = <value optimized out> + pi = <value optimized out> + link = {thread = 3, next = 0x0, prevp = 0x8084b94, notifies = 0x0, interrupted_next = 0x0} + outp = 0x125bc60 + __PRETTY_FUNCTION__ = "internal_demuxer" + [System crashed.] 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..cf41550d --- /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]] + +[[!debbug 46859]], [[!debbug 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 + diff --git a/open_issues/thread_numbering_of_ps_and_gdb.mdwn b/open_issues/thread_numbering_of_ps_and_gdb.mdwn new file mode 100644 index 00000000..7058cfe2 --- /dev/null +++ b/open_issues/thread_numbering_of_ps_and_gdb.mdwn @@ -0,0 +1,21 @@ +[[!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]]."]]"""]] + +It appears to [[me|tschwinge]] that `ps -T` enumerates thread IDs starting with +zero, and GDB starting with one. This should be unified. + +Or instead of manually allocating numbers, some other handle should be used, +that has a global meaning for the running GNU Mach kernel, or a process-wide +meaning, for example a port number. + +[[!tag open_issue_hurd open_issue_gdb]] + + +Also see [[GDB thread IDs]]. diff --git a/open_issues/threads_issues.mdwn b/open_issues/threads_issues.mdwn new file mode 100644 index 00000000..aec216e0 --- /dev/null +++ b/open_issues/threads_issues.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]]."]]"""]] + +List of issues w.r.t. the Hurd's many-threads paradigm. + +[[!tag open_issue_hurd]] + + * [[fsync]] 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/time.mdwn b/open_issues/time.mdwn new file mode 100644 index 00000000..ab239aef --- /dev/null +++ b/open_issues/time.mdwn @@ -0,0 +1,69 @@ +[[!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 +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_porting]] + +Neither the `time` executable from the GNU time package work completely +correctly, nor does the GNU Bash built-in one. + + tschwinge@flubber:~ $ \time sleep 2 + 0.00user 0.00system 9:38:00elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ \time sleep 4 + 0.00user 0.00system 18:50:25elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ \time sleep 6 + 0.00user 0.00system 28:00:53elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + tschwinge@flubber:~ $ time sleep 2 + + real 0m2.093s + user 0m0.000s + sys 0m0.011s + tschwinge@flubber:~ $ time sleep 4 + + real 0m4.083s + user 0m0.000s + sys 0m0.010s + tschwinge@flubber:~ $ time sleep 6 + + real 0m6.164s + user 0m0.000s + sys 0m0.010s + +GNU time's *elapsed* value is off by some factor. + + $ \time factor 1111111111111111111 + 1111111111111111111: 1111111111111111111 + 0.00user 0.00system 52:39:24elapsed 0%CPU (0avgtext+0avgdata 0maxresident)k + 0inputs+0outputs (0major+0minor)pagefaults 0swaps + $ time factor 1111111111111111111 + 1111111111111111111: 1111111111111111111 + + real 0m11.424s + user 0m0.000s + sys 0m0.010s + +As above; also here all the running time should be attriuted to *user* time. +This is probably a [[!taglink open_issue_gnumach]]. + + +# 2011-09-02 + +Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account +-- I believe flubber has already been Xenified at that time. + + +## IRC, freenode, #hurd, 2011-09-02 + +While testing some [[performance/IPC_virtual_copy]] performance issues: + + <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn new file mode 100644 index 00000000..bd9abcf9 --- /dev/null +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -0,0 +1,87 @@ +[[!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 +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_hurd]] + +[[!toc]] + + +# IRC, freenode, #hurd, June (?) 2010 + + <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? + <marcusb> there is a way + <pochu> marcusb: which one would that be? + <marcusb> I forgot + <marcusb> there is an implementation in libc + <marcusb> realpath has a similar job + <marcusb> but that's not what I mean + <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for + <marcusb> maybe it works only for directories + <marcusb> yeah + <marcusb> pochu: check the getcwd() implementation of libc + <marcusb> sysdeps/mach/hurd/getcwd.c + <marcusb> _hurd_canonicalize_directory_name_internal + * pochu looks + <pochu> marcusb: interesting + <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file + <marcusb> right + <pochu> oh you already said that :) + <marcusb> actually, I am not sure that's correct + <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in + <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that + <marcusb> the hurd is strange + <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) + <marcusb> yep + <pochu> ok. interesting + <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you? + <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip + <marcusb> there you go + <marcusb> or the other way round: would you be surprised if "cat somedir" would work? + <pochu> I think so. if it did, what would it do? + <marcusb> originally, cat dir would list the directory content! + <marcusb> in the old unix times + <pochu> I was surprised the first time I typed `vi somedir` by accident + <marcusb> and some early BSDs + * pochu feels young :-) + <marcusb> he don't worry, I didn't see those times either + <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface + <marcusb> which combines file and directory operations + <marcusb> of course, files and directories implement those functions differently + <antrik> marcusb: do you know why this behavior (cat on directories) was changed? + + +# IRC, freenode, #hurd, 2011-07-13 + +A related issue: + + <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l + <braunr> 1039 + <braunr> any idea why a shell would consume more than 1039 map entries ? + <braunr> (well, not more actually) + <braunr> even the kernel and ext2fs have around 100 + <braunr> (the kernel has actually only 23, which is very good and expected) + <tschwinge> braunr: I agree that having some sort of debugging information + for memory objects et al. would be quite hand. To see where they're + coming from, etc. + <braunr> tschwinge: this would require naming objects at the mach level + <braunr> e.g. when creating an object + <braunr> giving it the path of a file for example + <tschwinge> braunr: I have recently seen something (due to youpi fixing a + bug) that bash is doing its own memory management. Perhaps all these are + such regions? + <tschwinge> braunr: For example, yes. + <braunr> what ? + <braunr> ?! + <tschwinge> braunr: + http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html + <braunr> i see + +Also see email thread starting at [[!message-id +"20110714082216.GA8335@sceen.net"]]. diff --git a/open_issues/translator_environment_variables.mdwn b/open_issues/translator_environment_variables.mdwn new file mode 100644 index 00000000..cae5a494 --- /dev/null +++ b/open_issues/translator_environment_variables.mdwn @@ -0,0 +1,31 @@ +[[!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. + + <cfhammar> BTW, is settrans -a supposed to clear all env variables? + <cfhammar> or can I consider it a bug ;-) + <cfhammar> scolobb: yeah, seems the problem is in libfshelp + <scolobb> cfhammar: Are you talking about fshelp_start_translator_long? + <scolobb> (I can remember that it does something to the environment indeed) + <cfhammar> scolobb: yes, I think it's the culprit + <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones + <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-( + <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong. + <cfhammar> scolobb: yeah, that's my guess also + <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think? + <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs. + <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long + <scolobb> cfhammar: Yeah, that's right + <scolobb> I wonder what could the motivation for not passing the environment to a child process + <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env... + <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-) diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn new file mode 100644 index 00000000..14ea1c6d --- /dev/null +++ b/open_issues/translator_stdout_stderr.mdwn @@ -0,0 +1,53 @@ +[[!meta copyright="Copyright © 2008, 2009, 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 +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]] + +There have been several discussions and proposals already, about adding a +suitable logging mechanism to translators, for example. + + +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. + + +IRC, freenode, #hurd, 2011-11-06 + + <youpi> about CLI_DEBUG, you can use #define CLI_DEBUG(fmt, ...) { + fprintf(stderr, fmt, ## __VA_ARGS__); fflush(stderr); } + <tschwinge> Isn't stderr in auto-flush mode by default? + <tschwinge> man setbuf: The standard error stream stderr is always + unbuffered by default. + <youpi> tschwinge: "by default" is the important thing here + <youpi> in the case of translators iirc stderr is buffered + <tschwinge> youpi: Oh! + <tschwinge> That sounds wrong. + + +IRC, freenode, #hurd, 2011-11-23 + + <braunr> we'd need a special logging task for hurd servers + <pinotree> if syslog would work, that could be used optionally + <braunr> no, it relies on services provided by the hurd + <braunr> i'm thinking of something using merely the mach interface + <braunr> e.g. using mach_msg to send log messages to a special port used to + reference the logging service + <braunr> which would then store the messages in a circular buffer in ram + <braunr> maybe sending to syslog if the service is available + <braunr> the hurd system buffer if you want diff --git a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn new file mode 100644 index 00000000..5d3c3aab --- /dev/null +++ b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn @@ -0,0 +1,148 @@ +[[!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 open_issue_glibc]] + +bug-hurd email from 2010-07-28: *O_NOTRANS & O_NOFOLLOW* + +2010-07-29, #hurd + + <antrik> cfhammar: I think that touches on a rather fundamental problem... it's always hard to decide how to handle translators, as the most useful approach depends a lot on context + <antrik> this was actually part of the idea behind namespace-based translator selection + <cfhammar> or perhaps we should just drop the whole O_NOFOLLOW == O_NOTRANS and only apply it for link like translators + <pochu> cfhammar: from what I read in [glibc]/hurd/lookup-retry.c, the problem is that some translators can lie about that + <antrik> cfhammar: at some point I considered the possibility of adding a couple of special flags describing translators ("link" and "device" being some, but also introducing a few new ones) to decide standard behaviour in various situations + <pochu> so you can't really know whether they are links without O_NOTRANS + <cfhammar> pochu: yeah, this would have to be considered carefully + <pochu> antrik: care to explain what namespace based translator selection means? :) + <antrik> pochu: the basic idea is that you add special suffixes to the file name during a lookup, which change the behaviour of lookups + <antrik> the most basic use would be adding a suffix that automatically runs an annonymous translator on the file + <cfhammar> antrik: doesn't stat cover most of those flags (except for firmlink i guess) + <antrik> (scolobb mostly implemented that part) + <antrik> but the idea was also to selectively activate/deactivate static translators based on patterns + <antrik> (this is implemented partially, but recursion is completely missing so far) + <antrik> cfhammar: some of them, yes. but I think there are some cases where the standard stat information is not enough to decide on useful handling + <antrik> let's take the example of a translator that mangles the underlying file -- like xmlfs, mboxfs etc. + <antrik> these aren't device file nor links, but should not really be handled like "normal" (store) filesystems either + <antrik> hm... is there any information in the stat that indicates mount points? + <antrik> I guess that would be good enough to flag "normal" filesystems + <pochu> I'm not sure I understand. you add a suffix during a lookup, based on what? whatever, including e.g. flags? + <antrik> pochu: well, an exmple would be "cat foo.gz,,u" + <antrik> where "u" would be a shorthand for "unzip" + <antrik> and it would launch a translator that uncompresses the underlying file + <pochu> what if there are a foo.gz and a foo.gz,,u files? + <antrik> (I think storeio with gzip store can do that... though some more generic translator might be useful, to cover other compression/archieve types as well) + <antrik> pochu: than you are SOL ;-) + <antrik> pochu: I chose ",," as the suffix after some careful examination that this is *extremely* unlikely to occur in normal use + <antrik> pochu: actually, we introduced an escaping scheme too, so it is still possible to access files with ",," in the name... but that's of limited use, as programs not aware of this will still break + <cfhammar> hmm i wonder why glibc handles O_NOFOLLOW to begin with, since the test it does presumes trust in the containing directory the fs could do it just as securely + <antrik> cfhammar: the FS could do what? + <pochu> another problem I've found is that an open(symlink, O_RDONLY | O_NOFOLLOW, 0) should fail with ELOOP according to POSIX, but it doesn't fail on Hurd + <antrik> pochu: yeah, saw that + <antrik> shouldn't be too hard to fix I hope?... + <cfhammar> antrik: libc test whether the node is a symlink or a (trusted) root owned translator, which it would follow + <pochu> antrik: probably not, though I haven't looked at it closely + <antrik> cfhammar: in what situation would the filesystem do the test? + <antrik> cfhammar: and what advantage would it have over the current approach? + <antrik> pochu: OK + <cfhammar> antrik: the point of the test is to approximate symlink vs. mount point but the fs seems to be in a better position to answer this + <antrik> cfhammar: why? I think this information should be fully available to glibc... if it's not, I'd consider this a bug, or at least a major omission + <cfhammar> antrik: well take fifos for instance, they should be considered part of the containing filesystem but would not by glibc + <cfhammar> antrik: we could make an exception in glibc for fifos but not for other future situations in new translators + <cfhammar> antrik: i mean, we could but this leaves control at the translators hand and let different translators handle things their own way + <cfhammar> generally, it seems more flexible to leave policy to servers rather than to bake it into the (implicit) protocol (which glibc implements) + <antrik> cfhammar: I don't see though why handling it in the filesystem would help here... if the filesystem has the information about how the translator should be handled, it can pass it to the clients + <antrik> hm... that's actually a tricky point. we have many situations where we have to choose between handling things in the client library or server-side... I'm haven't really formed an opinion yet which is preferable in general + <pochu> with cfhammar's proposal, you wouldn't need O_NOTRANS when you specify O_NOFOLLOW, right? + <cfhammar> pochu: i don't think my proposal would even work with O_NOTRANS + <antrik> cfhammar: hm, perhaps we are talking past each other. do you want the handling to be in the filesystem containing the underlying node, or in the actual translator implementing the node? + <antrik> hrm + <cfhammar> antrik: the containing filesystem + <cfhammar> (since this is a security issue) + <pochu> yeah, otherwise the trust issue would still be there + <antrik> then why wouldn't it work with O_NOTRANS? + <antrik> BTW, what security issue are you talking about? do you mean the fact that a translator can redirect the lookups to another file, but hide the fact that it's a link? + <pochu> antrik: I mean the O_NOTRANS & O_NOFOLLOW comment in [glibc]/hurd/lookup-retry.c + <cfhammar> antrik: because O_NOTRANS means don't follow translators (including symlinks) and O_NOFOLLOW means don't follow (any) link but do follow translators + <antrik> pochu: I must admit that I never fully understood what that one is about :-) + <cfhammar> antrik: i imagine O_NOTRANS|O_NOFOLLOW == O_NOTRANS + <antrik> cfhammar: I see + <antrik> cfhammar: but I guess that's totally orthogonal from handling in glibc vs. handling in the FS?... + <pochu> AFAIU, it's that if you do an open(translator, O_NOFOLLOW, 0), the translator can lie about it being a symlink. So you need to do an O_NOTRANS lookup + <pochu> hence hurd/hurdlookup.c adds O_NOTRANS if O_NOFOLLOW is present in flags + <antrik> ah, OK + <antrik> so the idea here is that instead of doing that, glibc would only pass on O_NOFOLLOW, and the filesystem would handle the O_NOTRANS part itself + <cfhammar> antrik: if you have O_NOTRANS the filesystem will never follow any translators including non-link ones, so it can't really handle O_NOFOLLOW to exclude link translators + <cfhammar> antrik: yeah + <antrik> AIUI the problem is that with the current scheme, using O_NOFOLLOW will also ignore non-link translators? + <cfhammar> antrik: exactly, including fifos + <cfhammar> antrik: of course, there's still the problem of determining that it is a non-link translator + <antrik> cfhammar: but why can't this be fixed keeping the current scheme? wouldn't it suffice for glibc to ask the filesystem whether there is a link (with O_NOTRANS), and if not, do the actual lookup without O_NOTRANS?... + <pochu> antrik: there's still the problem of translators lying about them being symlinks or not, right? so instead of a blacklist (is it a symlink?) you would need a whitelist + <antrik> pochu: sure. I just don't see how an implementation in the filesystem would do any better on that score than one in glibc + <cfhammar> antrik: the fs is better at maintaining the whitelist, e.g. you could have different whitelist for different translators + <cfhammar> antrik: the fs also knows who own the fs, so it could make exeptions for the owner's translators + <cfhammar> like glibc does for the root user, currently + <antrik> I'm not really convinced so far that having these policies in the filesystem is really preferable to having them in the client-side library... + <cfhammar> antrik: we want to put /hurd/fifo in the whitelist for all users but we can't determine whether an active translator on the underlying node is /hurd/fifo or not, but the FS can if it started the translator itself + <cfhammar> antrik: of course, this can also be done by hiding the /hurd/fifo translator so that glibc doesn't do the test in the first place + <cfhammar> antrik: but this isn't pretty, you'd have to proxy it afaics :-/ + <antrik> cfhammar: TBH, I don't like the whole whilelisting idea + <antrik> seems to me this is really just another manifestation of the infamous firmlink problem + <antrik> as I said in past discussions, I tend to think that the only way to fix it *properly* is changing the way authentification is handled + <antrik> we actually discussed this at some point... when crossing translator boundries, the client shouldn't use it's full permissions on the new translator, but rather the intersection of it's own permissions and that of the parent translator + <antrik> this way, "secret" links should cease to be dangerous... + <cfhammar> yeah, but that'll take way too long for poor pochu ;-) + <antrik> cfhammar: true... but I'm not convinced that a whitelisting hack in the meantime is really worthwhile + <cfhammar> antrik: we already have a whitelisting hack (root user's translators), we're just moving it to the filesystem and adding /hurd/fifo + <antrik> cfhammar: nope, allowing all root translators is a general policy, not a whitelisting hack + <antrik> not elegant either, but a very different class + <cfhammar> antrik: i don't remember the details but fixing firmlink problem seemed to require some fundamental changes, it might even turn out to be unfeasible + <antrik> BTW, it's still not clear to my why the filesystem is supposed to have a better idea which translators to whitelist than glibc?... + <cfhammar> antrik: huh, i don't think i've seen that policy elsewhere, only for root clients not servers + <cfhammar> antrik: for one it can keep track of if the current active translator is the current passive one, and thus know which program it runs + <antrik> do I get it right that in the case of fifo, the client can't generally trust the user running the translator, and thus the idea is instead to trust the translator program?... + <cfhammar> O_NOFOLLOW implies that the client does not trust the file not to redirect it anywhere and we know /hurd/fifo will not do this + <antrik> cfhammar: was that a "yes"?... + <cfhammar> antrik: yes + <antrik> hm... I think I already said it in the context of object migration: I really don't like the idea of trust based on the program being executed... + <antrik> this workaround also has other shortcomings: what if the transaltor is started actively? + <cfhammar> hmm the owner of the translator could hijack it and the fs wouldn't know + <antrik> I must admit though that I don't see another short-term solution either :-( + <antrik> oh, right, that's another problem + <cfhammar> seems like the fs must implement the fifo itself (or atleast hide the /hurd/fifo translator behind a proxy) + <antrik> BTW, what is the specific manifestation of the problem with fifos being ignored on NOFOLLOW? + <pochu> there are two problems + <pochu> one is that with O_NOFOLLOW, it's ext2fs who checks the file permissions, and denies it (dunno the reason for that) + <pochu> the other one is that if you stat the fifo with O_NOFOLLOW and without it, the device will look different (and thus cp believes the file has changed and fails) + <pochu> that's because an stat on the fifo will return the fifo translator's PID as the device + <antrik> ah + <pochu> while one with O_NOFOLLOW will return the partition device + <antrik> so the specific problem here is that the stat info is differenet with the fifo translator than without + <pochu> I'm not sure whether it would be correct & possible to return the device of the parent translator in libtrivfs, instead of the PID + <pochu> yes + <pochu> that, and the permission one (they are different) + <pochu> though both would be solved if O_NOFOLLOW didn't imply O_NOTRANS :) + <antrik> what exactly do you mean by "device" here? + <pochu> I mean st_dev in struct stat + <antrik> well, I wonder whether the permission problem shouldn't actually be considered a bug in fifo. i sthere a good reason why the permissions are not propagated to the underlying node, as with most other translators? + <pochu> I don't think that's the problem + <antrik> what else? + <pochu> it's rather that if you open the fifo with O_NOTRANS, you don't get the underlying node, and then it's ext2fs (and so libdiskfs) who checks the permissions, and it denies them for whatever reason + <pochu> antrik: libdiskfs/dir-lookup.c has this: + <pochu> if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR) + <pochu> >------- && (flags & (O_READ|O_WRITE|O_EXEC))) + <pochu> >------- || (type == S_IFLNK && (flags & (O_WRITE|O_EXEC)))) + <pochu> >-------error = EACCES; + <pochu> so it returns EACCES for the fifo + <pochu> I wonder whether there's a good reason (that I'm missing) for that + <cfhammar> pochu: i think the reason might be that ext2fs denies access because it does not implement those file types itself + <cfhammar> i.e. ext2fs expects them to be opened without O_NOTRANS + <cfhammar> (or opened exclusively for non rwx reasons such as stat or settrans) diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn new file mode 100644 index 00000000..1dac130c --- /dev/null +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -0,0 +1,352 @@ +[[!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-07-17 + + <antrik> Reventlov: this is the so-called "firmlink issue" -- though AFAIK + it doesn't actually apply to firmlinks ;-) + <antrik> the problem is that any user can in theory create and set up a + special translator, which will redirect to another directory, without any + indication that it's a link + <braunr> but this doesn't supersede the file system permissions, does it ? + <antrik> as a result, if someone runs rm -r on the directory containing + that translator (which could be a world-writable one such as tmp), the rm + -r will descend into the directory, and thus remove it with the + permissions of the user who ran the rm -- not the one who set up the + translator + <braunr> oh i see, when tmp gets cleared by a script run as root, your home + is deleted ? + <antrik> right + <antrik> of course, the workaround is trivial: just don't follow + translators set up by untrusted users + <antrik> (which is precisely the default policy for FUSE BTW) + <braunr> which is the general policy around memory managers in general + <antrik> it's just nobody cared to implement this change + <youpi> antrik: does rm use O_NOTRANS ? + <antrik> youpi: I'm pretty sure it doesn't + <youpi> so it's still an issue for now + <antrik> yes, it's still an issue. it's just not a really fundamental + problem as macrus claimed it to be... [sigh] + <youpi> well, fix rm and then you can say it's not an issue any more + <braunr> does it only concern rm ? + <antrik> youpi: rm is just an example. the problem is much more generic: a + malicious translator can do all kinds of harm + <youpi> sure + <youpi> it's just about tools not blindly following things + <antrik> the only simple and effective answer is not to follow translators + from untrusted users by default + <youpi> antrik: but then /dev/null can't be non-root + <braunr> depends how "untrusted users" are identified + <antrik> we discussed a more sophisticated solution with cfhammer, that + would change the way reauthentication works in lookups, and should + prevent these kinds of permission escalation without preventing desirable + uses... but it still wouldn't address DOS issues, so it would be only a + partial solution + <antrik> youpi: why should it? + <manuel> (http://lists.gnu.org/archive/html/bug-hurd/2009-11/msg00231.html + for the most sophisticated solution) + <antrik> braunr: well, currently the permission system generally trusts + root and the own user. implementing something else might be tricky... not + sure + <antrik> manuel: yes, that's precisely the discussion I was referring + to... thanks for the link :-) + <youpi> antrik: depends what you mean by "follow" + <youpi> what DOS are you thinking of? + <antrik> youpi: a translator can generate endless amounts of "data"; a + translator can generate endless recursive directory tress; or it can just + never return from RPCs... all things that can do pretty much harm + depending on the situation + <antrik> filesystem clients generally trust filesystem operations to be + safe -- and that's just not true anymore with filesystems run by + untrusted users + <antrik> (be it Hurd translators or FUSE modules) + <antrik> this is a fundamental problem as marcus and neal rightly observed + <antrik> I just don't agree about the seriousness of the consequences + <antrik> I don't think not following untrusted translators really looses us + much + <youpi> EDOOMANYNEGATIONS + <youpi> s/D/T + <youpi> again, what do you mean by "following" ? + <youpi> always use O_NOTRANS ? + <tschwinge> Yes, I think. + <youpi> or never accept a REAUTH ? + <youpi> O_NOTRANS would mean ftpfs running as root, brrr + <youpi> it's not really true that clients always trust filesystem + operations + <youpi> the "not returning" case for instance, also appears with nfs mounts + <antrik> no, not always use O_NOTRANS. just be more selective about what + translators to follow. specifically, don't follow translators set up by + untrusted users. (unless explicitly requested) + <antrik> you can think of it as O_NO_UNTRUSTED_TRANS + <antrik> note that if you run ftpfs under a special user, who is not root + but trusted by root, this would still be fine. I hope it shouldn't be too + hard to implement that... + <antrik> as for NFS: clients generally do *not* try to catch possible + failures. if the NFS server doesn't return, the clients hang forever. but + the NFS server is generally trusted, so this is not much of a problem + <antrik> BTW, I guess not accepting reauth from untrusted translators would + also fix the privilege escalations (similar to the proposed modified + reauth mechanism, only more invasive); but it wouldn't fix the DoS issues + <ArneBab> antrik: would that also be an issue for a run translator, which + runs a command on read? + <ArneBab> youpi: couldn’t ftpfs have root drop priviledges? + <ArneBab> like a runas trans + <ArneBab> essertially su for translators to drop privs + <antrik> ArneBab: hm... if we can make sure that the translator was started + as root, and dropped privileges later, I guess that would be fine... not + sure how hard that is + <antrik> ArneBab: but I think it would be more elegant to start the + translators as trusted non-root users in the first place + <ArneBab> then i ph.avme to trust them + <ArneBab> deper hierarchy + <ArneBab> deeper + <ArneBab> but essertially the same + <ArneBab> if then someone mounted his home himself, would I be able to read + it? + <ArneBab> /home/user + <ArneBab> antrik: if not, that would be really non-nice + <antrik> ArneBab: sorry, but we simply *can't* trust a translator set up by + an untrusted user. if he controls it, he can make it behave maliciously + <antrik> we could in theory try to come up with a proxy that catches + problematic semantics, and presents a "safe" variant to the actual + clients... but that would be not-trivial, and I'm not sure how safe it + can be made + <antrik> ArneBab: of course you should always have the option to explicitly + say that you want to trust the translator, if you think the user doesn't + have malicious intentions :-) + <antrik> (I think nsmux would be a good way to achieve this...) + <braunr> unless it's really really necessary (and i don't see why it would + be), no design should force a process to start with privileges and drop + them + <braunr> having a set of trusted users (e.g. uid < 100) is a nice solution + to the problem imho + <braunr> or part of a group, 100 is a non-hurdish static limit + <ArneBab> What user is running a passive translator? + <braunr> passive translators are a pain for such things :/ + <braunr> a command line and attach point are not enough to persistently + encode the execution context of the tranlator + <ArneBab> What user is running a passive translator? + <ArneBab> sorry + <braunr> the one owning the inode if i'm right + <ArneBab> so actually the orly problem are recursive commands, which also + are a problem with plain symlinks? + <braunr> i'm not sure + <ArneBab> Is thene any havoc a translator can wreak that a symlink can’t? + <braunr> well, as symlinks are translators, if a translator can damage + something, a symlink may too + <ArneBab> but not in Linux? + <braunr> err + <braunr> there are no translator in linux + <ArneBab> → commands could just treat translators as symlinks + <ArneBab> jepp, but it has symlinks + <braunr> no, this would defeat the purpose of translators :p + <braunr> and it's just no doable + <braunr> you would have recursion everywhere + <ArneBab> why? + <braunr> because every file access is sent to a translator + <ArneBab> hm, yes + <braunr> and we don't want to change commands + <braunr> we want to fix the design + <ArneBab> → only untrusted trans + <braunr> rather than considering them as symlinks, just consider them as + untrusted translators + <braunr> this doesn't change the semantics, only the action of accessing a + node or not + <braunr> but as antrik said, this has to be done :) + <braunr> the real problem would simplify to "how do you know if a + translator can be trusted", which is a matter of selecting the righ + identification strategy + <braunr> one strong strategy would be to have a port right copied to each + trusted task + <braunr> i wonder if one of the special ports could be used for that + <braunr> or if we have to add a new one + <ArneBab> so when I login, I would give port rights to trusted uids? + <braunr> no + <braunr> when a trusted translator starts a passive translator attached on + a node owned by root, it would copy its trusted right to the new task + <braunr> much like the device master port is passed to root tasks + <braunr> but i'm not sure this mechanism can be safely used to know if the + translator can be trusted + <braunr> the translator would be able to actively call services requiring + this capability + <braunr> but i guess client tasks would have to ask for the translator to + prove it's trusted + <braunr> which is a problem because the issue is to know if it can be + trusted before asking it anything + <braunr> another way is to register trusted tasks in another server, and + ask this server if the target translator is trusted + <braunr> i"m pretty sure these strategies already exist in some form on the + hurd + <ArneBab> hm + <braunr> does someone here have an idea why BSD-derived VMs account wiring + information at the high level vm_map instead of storing it in lower level + vm_page ? + <ArneBab> braunr: a translator anywhene in the FS can only be there, if the + creator had sufficient rights to the node, right? + <ArneBab> so wouldn’t it suffice to check the access rights? + <braunr> no + <braunr> ismple example: /dev/null is owned by root, but you have read + access to it + <braunr> hm that may not answer your question actually + <braunr> what access right would you check ? + <braunr> if someone creates a node with rights 777, do you still want to + access it ? + <ArneBab> no + <braunr> simple enough i hope :) + <ArneBab> arg… + <ArneBab> if I can write to it, I can give it a translaton + <ArneBab> translator + <braunr> but this doesn't tell you it can be trusted + <ArneBab> well, actually: yes, access, but not recurse + <braunr> the owner sets his own rights, and you can't trust the owner + <braunr> unless it's root, but you don't want all your translators to run + as root + <ArneBab> it can act as its owner? + <ArneBab> yes + <braunr> well, as i told you, a passive translator is started by its parent + translator (the one managing the file systeme node it's attached to) + <braunr> the new translator runs as the user owning the node + <braunr> (if i'm right) + <ArneBab> …and so on, till noot starts the first + <ArneBab> root + <braunr> ? + <ArneBab> root starts /, right? + <braunr> no + <braunr> gnumach starts / + <ArneBab> ah, right + <braunr> gnumach starts somefs.static + <braunr> which attaches at / + <braunr> and runs with root privileges + <braunr> keep in mind that unix permissions are implemented as capabilities + on the hurd + <ArneBab> → root has it / it’s root + <braunr> the rights you have aren't limited to those permissions + <ArneBab> jepp + <braunr> and it's not "until" + <ArneBab> so why should I not access a translator run by someone else? I + just don’t want to do any active command (recurse)… hm… can a translator + turn a read request into a write? + <braunr> that's the only problem + <ArneBab> program with my rights wants to read, but the translator makes it + write instead? + <braunr> no + <braunr> a translator can do pretty much anything with your request + <ArneBab> with my rights? + <braunr> no + <braunr> the most obvious example of DoS is simply not answering + <braunr> your process hangs + <braunr> considering some file system accesses, a translator could return + inconsistent data + <ArneBab> so if the translator tries to make me write instead of read, it + can do so only when the owner of the translaton can write to the file in + question? + <braunr> a well written application shouldn't have too much trouble dealing + with it but some aren't that well written + <braunr> this has *nothing* to do with read/write permissions + <braunr> you should read the critique :p + +[[hurd/critique]] + + <ArneBab> ln -s /home/you /home/me → “why don’t you look into my home?” + <ArneBab> read it again, that is :) + <ArneBab> (has been some time since I read it) + <antrik> braunr: you just described the auth mechanism ;-) + <antrik> ArneBab: symlinks can do considerably less than translators; and + even these caused a lot of trouble when introduced (and still cause + sometimes) + <antrik> we can't make every application aware of translators + <antrik> indeed I believe we can a avoid many problems by presenting + various translators as symlinks -- but this is not approriate for all + translators + <antrik> it is something the translator itself decides, so it's not helpful + to solve security issues at all + <antrik> and as braunr already pointed out, this wouldn't help with DoS + problems + + +# Linux kernel, Symlink/Hardlink Attack + +Even though not directly comparable, the issues described at [Symlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection) +and [Hardlink +Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection) +do bear some similarity with the issue we're discussing here. + +Likewise, Kees Cook, [fs: symlink restrictions on sticky +directories](http://lwn.net/Articles/468215/), 2011-11-18. [2011-12-06 +update](http://lwn.net/Articles/470891/). Jake Edge, [Fixing the symlink race +problem](http://lwn.net/Articles/472071/), 2011-12-14. + + +# IRC, freenode, #hurd, 2011-08-31 + + <antrik> I don't see any problems with following only translators of + trusted users + <youpi> where to store the list of trusted users? + <youpi> is there a way to access the underlying node, which for /dev + entries belongs to root? + <ArneBab> youpi: why a list of trusted users? Does it not suffice to + require /hurd/trust set by root or ourselves? + <youpi> ArneBab: just because that's what antrik suggests, so I ask him for + more details + <ArneBab> ah, ok + <antrik> youpi: probably make them members of a group + <antrik> of course that doesn't allow normal users to add their own trusted + users... but that's not the only limitation of the user-based + authentication mechanism, so I wouldn't consider that an extra problem + <antrik> ArneBab: we can't set a translator on top of another user's + translator in general + <antrik> root could, but that's not very flexible... + <antrik> the group-based solution seems more useful to me + <ArneBab> antrik: why can’t we? + <antrik> also note that you can't set passive translators on top of other + translators + <antrik> ArneBab: because we can only set translators on our own nodes + <ArneBab> active ones, too? + <antrik> yes + <ArneBab> antrik: I always thought I could… + <ArneBab> but did not test it + <ArneBab> antrik: so I need a subhurd to change nodes which do not belong + to me? + * ArneBab in that case finally understands why you like subhurds so much: + That should be my normal right + <antrik> it should be your normal right to change stuff not belonging to + you? that's an odd world view :-) + <antrik> subhurds don't really have anything to do with it + <ArneBab> change it in a way that only I see the changes + <antrik> you need local namespaces to allow making local modifications to + global resources + <youpi> it should be one's normal right to change the view one has of it + <antrik> we discussed that once actually I believe... + <antrik> err... private namespaces I mean + +IRC, freenode, #hurd, 2011-09-10: + + <cjuner_> I am rereading Neal Walfield's and Marcus Brinkman's critique of + the hurd on mach. One of the arguments is that a file system may be + malicious (by DoS its clients with infinitely deep directory + hierarchies). Is there an answer to that that does not require programs + to be programmed defensively against such possibilities? + +IRC, freenode, #hurd, 2011-09-14: + + <antrik> cjuner: regarding malicious filesystems: the answer is to do + exactly the same as FUSE on Linux: don't follow translators set up by + untrusted users by default + <cjuner> antrik, but are legacy programs somehow protected? What about + executing `find`? Or is GNU's find somehow protected from that? + <antrik> cjuner: I'm talking about a global policy + <cjuner> antrik, and who would implement that policy? + <antrik> cjuner: either glibc or the parent translators + +Continued discussion about [[resource_management_problems/pagers]]. diff --git a/open_issues/trust_the_behavior_of_translators.mdwn b/open_issues/trust_the_behavior_of_translators.mdwn new file mode 100644 index 00000000..454c638b --- /dev/null +++ b/open_issues/trust_the_behavior_of_translators.mdwn @@ -0,0 +1,181 @@ +[[!meta copyright="Copyright © 2012 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]] + +Apart from the issue of [[translators_set_up_by_untrusted_users]], here is +another problem described. + + +# IRC, freenode, #hurd, 2012-02-17 + +(Preceded by the [[memory_object_model_vs_block-level_cache]] discussion.) + + <slpz> what should do Mach with a translator that doesn't clean pages in a + reasonable amount of time? + <slpz> (I'm talking about pages flushed to a pager by the pageout daemon) + <braunr> slpz: i don't know what it should do, but currently, it uses the + default pager + +[[default_pager]]. + + <slpz> braunr: I know, but I was thinking about an alternative, for the + case in which a translator in not behaving properly + <slpz> perhaps freeing the page, removing the map, and letting it die in a + segmentation fault could be an option + <braunr> slpz: what if the translator can't do it properly because of + system resource exhaustion ? + <braunr> (i.e. it doesn't have enough cpu time) + <slpz> braunr: that's the biggest question + <slpz> let's suppose that Mach selects a page, sends it to the pager for + cleaning it up, reinjects the page into the active queue, and later it + founds the page again and it's still dirty + <slpz> but it needs to free some pages because memory it's really, really + scarce + <slpz> Linux just sits there waiting for I/O completion for that page + (trusts its own drivers) + <slpz> but we could be dealing with rogue translator... + <braunr> yes + <braunr> we may need some sort of "authentication" mechanism for pagers + <braunr> so that "system pagers" are trusted and others not + <braunr> using something like the device master port but for pagers + <braunr> a special port passed to trusted pagers only + <slpz> hum... that could be used to workaround the untrusted translator + crossing problem while walking a directory tree + +[[translators_set_up_by_untrusted_users]]. + + <slpz> but I think differentiating between trusted and untrusted + translators was rejected for philosophical reasons + <slpz> (but I'm not sure) + <mcsim> slpz: probably there should be something like oom killer? + <mcsim> braunr: even if translator is trusted it could have a bug which + make it ask more and more memory, so system have something to do with + it. Also, this way TCB is increased, so providing port for trusted + translators may hurt security. + <mcsim> I've read that Genode has "guarded allocators" which help resource + accounting by limiting of memory that could be used. Probably something + like this could be used in Hurd to limit translators. + <antrik> I don't remember how Viengoos deals with this :-( + +[[microkernel/Viengoos]]. + + <braunr> mcsim: the main feature lacking in mach is resource accounting :p + +[[resource_management_problems]]. + + <slpz> mcsim: yes, I think there should be a Hurdish oom killer, paying + special attention to external pagers + +[[microkernel/mach/external_pager_mechanism]]. + + <braunr> the oom killer selects untrusted processes by definition (since + pagers are in kernel) + <mcsim> slpz: and what is better: oom killer or resource accounting? + <mcsim> Under resource accounting I mean mechanism when process can't get + more resources than it is allowed. + <braunr> resource accounting of course + <braunr> but it's not just about that + <braunr> really, how does the kernel deal when a pager refuses to honor a + paging request ? + <braunr> whether it is buggy or malicious + <braunr> is it really possible to keep all pagers out of the TCB ? + <antrik> mcsim: we definitely want proper resource accounting in the long + run. the question is how to deal with the situation that resources are + reallocated to other tasks, so some pages have to be freed + <antrik> I really don't remember how Neal proposed to deal with this + <slpz> mcsim: Better: resource accounting (in which resources are accounted + to the user tasks which are requesting them, as in the Viengoos + model). Good enough an realistic: oom killer + <antrik> I'm not sure an OOM killer for non-system pagers is terribly + helpful. in typical use, the vast majority of paging is done by trusted + pagers... + <antrik> and without proper client resource accounting, there are enough + other ways a rogue/broken process can eat system resources -- I'm not + convinced that untrusted pagers have a major impact on the overall + situation + <mcsim> If pager can't free resources because of lack, for example, of cpu + time it's priority could be increased to give it second chance to free + the page. But if it doesn't manage to free resources it could be killed. + <antrik> I think the current approach with default pager taking over is + good enough for dealing with untrusted pagers. the real problem are even + trusted pager frequently failing to deal with the requests + <braunr> i agree with antrik + <braunr> and i'm opposed to an oom killer + <braunr> it's really not a proper fix for our problems + <braunr> mcsim: what if needs 3 attempts before succeeding ? + <braunr> +it + <braunr> and increasing priority without a good reason (e.g. no priority + inversion) leads to unfairness + <braunr> we don't want to deal with tricky problems like malicious pagers + using that to starve other tasks + <mcsim> braunr: this is just temporary decision (for example for half of + second of user time), to increase probability that task was killed not + because of it lacked resources. + <braunr> mcsim: tunables should only affect the efficiency of an operation, + not its success + + +## IRC, freenode, #hurd, 2012-02-19 + + <antrik> neal: the specific question is how to ensure processes free memory + fast enough when their allocation becomes lower due to resource pressure + <neal> antrik: you can't really. + <neal> antrik: the memory manager can act on the application's behalf if + the application marks pages as discardable or pagable. + <neal> antrik: if the memory manager makes an upcall to the application to + free some memory and it doesn't, you have to penalize it. + <neal> antrik: You shouldn't the process like exokernel + <neal> antrik: It's the developers fault, not the user's + <neal> antrik: What you need are controls that ensure that the user stays + in control + <neal> ...shouldn't *kill* the process... + <antrik> neal: well, how can I penalize a process that eats to much + physical memory? + <neal> in the future, you don't give it as much slack memory + <antrik> marking as pagable means a system pager will push them to the swap + partition? + <antrik> ah, OK + <neal> yes + <neal> and you page it more aggressively, i.e., you don't give it a chance + to free memory + <neal> The situation is: + <neal> you have memory pressure + <neal> you choose a victim process and ask it to free memory + <neal> now, you need to wait + <neal> if you wait and it doesn't free memory, you give it bad karma + <neal> if you wait and it frees memory, you're good + <neal> but during that window, a bad process can delay recovery + <neal> so, in the future, we give bad processes less time + <neal> but, we still send a message asking it to free memory + <neal> we just hope it was a bug + <antrik> so the major difference to the approach we have in Mach is that + instead of just redeclaring some pages as anonymous memory that will be + paged to swap by the default pager eventually if the pager in question + fails to handle them properly, we wait some time for the process to free + (any) memory, and only then start paging out some of it's pages to swap + <neal> there's also discardable memory + <antrik> hm... there is some notion of "precious" pages in Mach... I wonder + whether that is also used to decide about discarding pages instead of + pushing them to swap? + <neal> antrik: A precious page is ro data that shouldn't be dropped + <antrik> ah + <antrik> but I guess that means non-precious RO data (such as a cache) can + be dropped without asking the pager, right? + <neal> yes + <antrik> I wonder whether such a karma system can be introduced in Mach as + well to deal with problematic pagers + + +## IRC, freenode, #hurd, 2012-02-21 + + <neal> antrik: One of the main differences between Mach and Viengoos is + that in Mach servers are responsible for managing memory whereas in + Viengoos applications are primarily responsible for managing memory. diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn new file mode 100644 index 00000000..26382d56 --- /dev/null +++ b/open_issues/tty_activitiy_vs_disk_io.mdwn @@ -0,0 +1,81 @@ +[[!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-07-25 + + < youpi> Mmm, typing something on the mach console triggers a write on the + disk + < youpi> because the /dev/console node gets updated + < youpi> I don't really see why + < youpi> (yes, just typing at the bash prompt, not even running something) + < youpi> typing during the sleep command (i.e. mere tty echo) doesn't + trigger it, however + < youpi> running bash's echo does trigger it + < braunr> during sleep, the glibc stream functions handle I/O, while with + bash, its readline takes care of it, right ? + < youpi> /bin/echo too + < youpi> during sleep it's the tty process which handles I/O + < braunr> the write may be due to a write time update on the inode + < braunr> modification* time + < youpi> probably yes, but how so? + < youpi> ext2fs is only supposed to pass the thing to the console + translator + < braunr> not sure + < youpi> actually, ext2fs even isn't supposed to come into play when it's + about typing at the bash prompt + < youpi> once it's opened, isn't the port for /dev/console supposed to be + directly to the translator there? + < braunr> i think so + < youpi> (s/tty/term/ in what I said) + < braunr> well, it's certain + < youpi> so I don't see how ext2fs can be triggered to write an atime or + mtime + < braunr> what does rpctrace say ? + < youpi> io_read_request and io_write_request + < youpi> braunr: it doesn't happen at the login prompt + < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime + < youpi> doesn't happen with dash + < braunr> we should implement relatime and experiment with it + < braunr> it shouldn't be hard + < youpi> well, there's noatime already + < youpi> but my point is that this update shouldn't happen + < youpi> and I believe it's the source of the i_file_acl e2fsck warning + < braunr> i wasn't saying that concerning this problem, it was just a + separate idea (noatime is more problematic than relatime) + < braunr> and i agree, it shouldn't happen :) + < youpi> ok, it's set_node_times which gets called + +IRC, freenode, #hurd, 2011-07-27 + + < antrik> BTW, I'm not sure it's still relevant; but the reason accessing + translators such as the console modifies the underlying node is that most + stat information is generally passed through + < antrik> (in some cases it might be unintentional though, simply using the + default implementation from trivfs carelessly...) + < youpi> I know + < youpi> I've seen that in the code + < antrik> OK + < youpi> it is still relevant: I still find it useless to write it on the + disk + < youpi> though w uses it to show idle time over reboot + < braunr> is it useful to keep the information across reboots ? + < youpi> for some value of "useful" for w + < braunr> i wonder what would break if this was entierly kept in memory + < youpi> nothing, probably + < youpi> note that it doesn't overload ext2fs so much, it just adds a write + every ~5s + < youpi> (at worse, i.e. when keeping showing text, for instance) + < braunr> indeed, the behaviour seems the same on linux + < antrik> ah... that explains why the disk doesn't spin down while IRC is + active... always wondered about that :-) + < youpi> that's not very power-saving, yes + < youpi> well, we might want to put /dev on ram someday diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn new file mode 100644 index 00000000..dd1e465c --- /dev/null +++ b/open_issues/unit_testing.mdwn @@ -0,0 +1,94 @@ +[[!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 +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]]."]]"""]] + +This task may be suitable for [[community/GSoC]]: +[[community/gsoc/project_ideas/testing_framework]] + +--- + +A collection of thoughts with respect to unit testing. + +We definitely want to add unit test suites to our code base. + +We should select a tool that we like to use, and that is supported (not +abandoned). + + * [SC + Test](http://web.archive.org/web/20021204193607/sc-archive.codesourcery.com/sc_test) + + * [DejaGnu](http://www.gnu.org/software/dejagnu/) / + [Expect](http://expect.nist.gov/) + + * used by the [[GCC testsuite|gcc]], [[GDB testsuite|gdb]], + [[binutils testsuite|binutils]], etc. + + * The [[glibc testsuite|glibc]] has a home-grown system (Makefile-based), + likewise does the [[Open_POSIX_Test_Suite]]. + + * [Kyua](http://code.google.com/p/kyua/) (and its predecessor [ATF](http://www.NetBSD.org/~jmmv/atf/)). + + * Primarily used by NetBSD as its testing framework; FreeBSD is in the process of adopting it. + + * Provides bindings to write tests in C, C++ and POSIX shell. Lua is planned. + + * Builds and runs on many different Unix-based operating systems. + + * [check](http://check.sourceforge.net/) + + * used by some GNU packages, for example GNU PDF (Jose E. Marchesi) + + * CodeSourcery's [QMTest](http://www.codesourcery.com/qmtest) + + * useb by? + + * documentation: + + * <http://www.codesourcery.com/public/qmtest/whitepaper.pdf> + + * <http://www.python.org/workshops/2002-02/papers/01/index.htm> + + * <http://gcc.gnu.org/ml/gcc/2002-05/msg01978.html> + + * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/tutorial/index.html> + + * <http://www.codesourcery.com/public/qmtest/qmtest-snapshot/share/doc/qmtest/html/manual/index.html> + + * [Git](http://git-scm.com/) has an elaborate unit testsuite, which is also + used in [Notmuch](http://notmuchmail.org/). + + * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel + Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt, + 2010-10-28. [v2](http://lwn.net/Articles/414064/), 2010-11-08. + + * <http://autotest.kernel.org/wiki/WhitePaper> + + +# Related + + * [[nightly_builds]] + + * [[nightly_builds_deb_packages]] + + * <http://www.phoronix-test-suite.com/> -- ``comprehensive testing and + benchmarking platform''. This one might be useful for [[performance]] + testing, too? + + * <http://ltp.sourceforge.net/> + + * [LaBrea](https://github.com/dustin/labrea/wiki), or similar tools can be + used for modelling certain aspects of system behavior (long response times, + for example). + + +# Discussion + +See the [[GSoC project idea|community/gsoc/project_ideas/testing_framework]]'s +[[discussion +subpage|community/gsoc/project_ideas/testing_framework/discussion]]. diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn new file mode 100644 index 00000000..8cde8281 --- /dev/null +++ b/open_issues/user-space_device_drivers.mdwn @@ -0,0 +1,636 @@ +[[!meta copyright="Copyright © 2009, 2011, 2012 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_hurd]] + +This is a collection of resources concerning *user-space device drivers*. + +Also see [[device drivers and IO systems]]. +[[community/gsoc/project ideas/driver glue code]]. + +[[!toc levels=2]] + + +# Issues + +## IRQs + + * Can be modeled using [[RPC]]s. + + * Security considerations: IRQ sharing. + + * *Omega0* paper defines an interface. + + * As is can be read in the *Mach 3 Kernel Principles*, there is an *event + object* facility in Mach that can be used for having user-space tasks react + to IRQs. However, at least in GNU Mach, that code (`kern/eventcount.c`) + doesn't seem functional at all and isn't integrated properly in the kernel. + + * IRC, freenode, #hurd, 2011-07-29 + + < antrik> regarding performance of userspace drivers, there is one + thing that really adds considerable overhead: interrupt + handling. whether this is relevant very much depends on the hardware + in question. when sending many small packets over gigabit ethernet, + it might be noticable; in most other cases it's irrelevant + < youpi> some cards support interrupt coalescin + < youpi> could be supported by DDE too + +## DMA + + * Security considerations. + + * I/O MMU. + + +### IRC, freenode, #hurd, 2012-08-15 + + <carli2> hi. does hurd support mesa? + <braunr> carli2: software only, but yes + <carli2> :( + <carli2> so you did not solve the problem with the CS checkers and GPU DMA + for microkernels yet, right? + <braunr> cs = ? + <carli2> control stream + <carli2> the data sent to the gpu + <braunr> no + <braunr> and to be honest we're not currently trying to + <carli2> well, a microkernel containing cs checkers for each hardware is + not a microkernel any more + <braunr> the problem is having the ability to check + <braunr> or rather, giving only what's necessary to delegate checking to + mmus + <carli2> but maybe the kernel could have a smaller interface like a + function to check if a memory block is owned by a process + <braunr> i'm not sure what you refer to + <carli2> about DMA-capable devices you can send messages to + <braunr> carli2: dma must be delegated to a trusted server + <carli2> linux checks the data sent to these devices, parses them and + checks all pointers if they are in a memory range that the client is + allowed to read/write from + <braunr> the client ? + <carli2> in linux, 3d drivers are in user space, so the kernel side checks + the pointer sent to the GPU + <youpi> carli2: mach could do that as well + <braunr> well, there is a rather large part in kernel space too + <carli2> so in hurd I trust some drivers to not do evil things? + <braunr> those in the kernel yes + <carli2> what does "in the kernel" mean? afaik a microkernel only has + memory manager and some basic memory sharing and messaging functionality + <braunr> did you read about the hurd ? + <braunr> mach is considered an hybrid kernel, not a true microkernel + <braunr> even with all drivers outside, it's still an hybrid + <youpi> although we're to move some parts into userlands :) + <youpi> braunr: ah, why? + <braunr> youpi: the vm part is too large + <youpi> ok + <braunr> the microkernel dogma is no policy inside the kernel + <braunr> "except scheduling because it's very complicated" + <braunr> but all modern systems have moved memory management outisde the + kernel, leaving just the kernel abstraction inside + <braunr> the adress space kernel abstraction + <braunr> and the two components required to make it work are what l4re + calls region mappers (the rough equivalent of our vm_map), which decides + how to allocate regions in an address space + <braunr> and the pager, like ours, which are already external + <carli2> i'm not a OS developer, i mostly develop games, web services and + sometimes I fix gpu drivers + <braunr> that was just FYI + <braunr> but yes, dma must be considered something privileged + <braunr> and the hurd doesn't have the infrastructure you seem to be + looking for + + +## I/O Ports + + * Security considerations. + +## PCI and other buses + + * Security considerations: sharing. + +## Latency of doing RPCs + + * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when + doing RPC calls. + + +## System Boot + +A similar problem is described in +[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented. + + +### IRC, freenode, #hurd, 2011-07-27 + + < braunr> btw, was there any formulation of the modifications required to + have disk drivers in userspace ? + < braunr> (which would obviously need something like + initrd/initramfs/whatever and may also need the root file system not to + be the first task started) + < braunr> hm actually, we may not need initrd + < braunr> the boot loader could just load more modules + < antrik> braunr: I have described all that in my thesis report... in + German :-( + < braunr> and the boot scripts could be adjusted to pass around the right + ports + < Tekk_> braunr: yeah, we could probably load a module that kciks us into + userspace and starts the disk driver + < braunr> modules are actualy userspace executables + < Tekk_> ah + < Tekk_> so what's the issue? + < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce + < braunr> change the file systems to tell them which underlying disk driver + to use + < Tekk_> mhm + < braunr> s/disk/storage/ + + +### IRC, freenode, #hurd, 2012-04-25 + + <youpi> btw, remember the initrd thing? + <youpi> I just came across task.c in libstore/ :) + + +### IRC, freenode, #hurd, 2012-07-17 + + <bddebian> OK, here is a stupid question I have always had. If you move + PCI and disk drivers in to userspace, how do do initial bootstrap to get + the system booting? + <braunr> that's hard + <braunr> basically you make the boot loader load all the components you + need in ram + <braunr> then you make it give each component something (ports) so they can + communicate + + +### IRC, freenode, #hurd, 2012-08-12 + + <antrik> braunr: so, about booting with userspace disk drivers + <antrik> after rereading the chapter in my thesis, I see that there aren't + really all than many interesting options... + <antrik> I pondered some variants involving a temporary boot filesystem + with handoff to the real root FS; but ultimately concluded with another + option that is slightly less elegant but probably gets a much better + usefulness/complexity ratio: + <antrik> just start the root filesystem as the first process as we used to; + only hack it so that initially it doesn't try to access the disk, but + instead gets the files from GRUB + <antrik> once the disk driver is operational, we flip a switch, and the + root filesystem starts reading stuff from disk normally + <antrik> transparently for all other processes + <bddebian> How does grub access the disk without drivers? + <antrik> bddebian: GRUB obviously has its own drivers... that's how it + loads the kernel and modules + <antrik> bddebian: basically, it would have to load additional modules for + all the components necessary to get the Hurd disk driver going + <bddebian> Right, why wouldn't that be possible? + <antrik> (I have some more crazy ideas too -- but these are mostly + orthogonal :-) ) + <antrik> ? + <antrik> I'm describing this because I'm pretty sure it *is* possible :-) + <bddebian> That grub loads the kernel and whatever server/module gets + access to the disk + <antrik> not sure what you mean + <bddebian> Well as usual I probably don't know the proper terminology but + why could grub load gnumach and the hurd "disk server" that contains the + userspace drivers? + <antrik> disk server? + <bddebian> Oh FFS whatever contains the disk drivers :) + <bddebian> diskdde, whatever :) + <antrik> actually, I never liked the idea of having a big driver blob very + much... ideally each driver should have it's own file + <antrik> but that's admittedly beside the point :-) + <antrik> its + <antrik> so to restate: in addition to gnumach, ext2fs.static, and ld.so, + in the new scenario GRUB will also load exec, the disk driver, any + libraries these two depend upon, and any additional infrastructure + involved in getting the disk driver running (for automatic probing or + whatever) + <antrik> probably some other Hurd core servers too, so we can have a more + complete POSIX environment for the disk driver to run in + <bddebian> There ya go :) + <antrik> the interesting part is modifying ext2fs so it will access only + the GRUB-provided files, until it is told that it's OK now to access the + real disk + <antrik> (and the mechanism how ext2 actually gets at the GRUB-provided + files) + <bddebian> Or write some new really small ext2fs? :) + <antrik> ? + <bddebian> I'm just talking out my butt. Something temporary that gets + disposed of when the real disk is available :) + <antrik> well, I mentioned above that I considered some handoff + schemes... but they would probably be more complex to implement than + doing the switchover internally in ext2 + <bddebian> Ah + <bddebian> boot up in a ramdisk? :) + <antrik> (and the temporary FS would *not* be an ext2 obviously, but rather + some special ramdisk-like filesystem operating from GRUB-loaded files...) + <antrik> again, that would require a complicated handoff-scheme + <bddebian> Bah, what do I know? :) + <antrik> (well, you could of course go with a trivial chroot()... but that + would be ugly and inefficient, as the initial processes would still run + from the ramdisk) + <bddebian> Aren't most things running in memory initially anyway? At what + point must it have access to the real disk? + <braunr> antrik: but doesn't that require that disk drivers be statically + linked ? + <braunr> and having all disk drivers in separate tasks (which is what we + prefer to blobs as you put it) seems to pretty much forbid using static + linking + <braunr> hm actually, i don't see how any solution could work without + static linking, as it would create a recursion + <braunr> and the only one required is the one used by the root file system + <braunr> others can be run from the dynamically linked version + <braunr> antrik: i agree, it's a good approach, requiring only a slightly + more complicated boot script/sequence + <antrik> bddebian: at some point we have to access the real disk so we + don't have to work exclusively with stuff loaded by grub... but there is + no specific point where it *has* to happen. generally speaking, the + sooner the better + <antrik> braunr: why wouldn't that work with a dynamically linked disk + driver? we only need to make sure all required libraries are loaded by + grub too + <braunr> antrik: i have a problem with that approach :p + <braunr> antrik: it would probably require a reboot when those libraries + are upgraded, wouldn't it ? + <antrik> I'd actually wish we could run with a dynamically linked ext2fs as + well... but that would require a separated boot filesystem and some kind + of handoff approach, which would be much more complicated I fear... + <braunr> and if a driver is restarted, would it use those libraries too ? + and if so, how to find them ? + <braunr> but how can you run a dynamically linked root file system ? + <braunr> unless the libraries it uses are provided by something else, as + you said + <antrik> braunr: well, if you upgrade the libraries, *and* want the disk + driver to use the upgraded libraries, you are obviously in a tricky + situation ;-) + <braunr> yes + <antrik> perhaps you could tell ext2 to preload the new libraries before + restarting the disk driver... + <antrik> but that's a minor quibble anyways IMHO + <braunr> but that case isn't that important actually, since upgrading these + libraries usually means we're upgrading the system, which can imply a + reoobt + <braunr> i don't think it is + <braunr> it looks very complicated to me + <braunr> think of restart as after a crash :p + <braunr> you can't preload stuff in that case + <antrik> uh? I don't see anything particularily complicated. but my point + was more that it's not a big thing if that's not implemented IMHO + <braunr> right + <braunr> it's not that important + <braunr> but i still think statically linking is better + <braunr> although i'm not sure about some details + <antrik> oh, you mean how to make the root filesystem use new libraries + without a reboot? that would be tricky indeed... but this is not possible + right now either, so that's not a regression + <braunr> i assume that, when statically linking, only the .o providing the + required symbols are included, right ? + <antrik> making the root filesystem restartable is a whole different epic + story ;-) + <braunr> antrik: not the root file system, but the disk driver + <braunr> but i guess it's the same + <antrik> no, it's not + <braunr> ah + <antrik> for the disk driver it's really not that hard I believe + <antrik> still some extra effort, but definitely doable + <braunr> with the preload you mentioned + <antrik> yes + <braunr> i see + <braunr> i don't think it's worth the trouble actually + <braunr> statically linking looks way simpler and should make for smaller + binaries than if libraries were loaded by grub + <antrik> no, I really don't want statically linked disk drivers + <braunr> why ? + <antrik> again, I'd prefer even ext2fs to be dynamic -- only that would be + much more complicated + <braunr> the point of dynamically linking is sharing + <antrik> while dynamic disk drivers do not require any extra effort beyond + loading the libraries with grub + <braunr> but if it means sharing big files that are seldom used (i assume + there is a lot of code that simply isn't used by hurd servers), i don't + see the point + <antrik> right. and with the approach I proposed that will work just as it + should + <antrik> err... what big files? + <braunr> glibc ? + <antrik> I don't get your point + <antrik> you prefer statically linking everything needed before the disk + driver runs (which BTW is much more than only the disk driver itself) to + using normal shared libraries like the rest of the system?... + <braunr> it's not "like the rest of the system" + <braunr> the libraries loaded by grub wouldn't be back by the ext2fs server + <braunr> they would be wired in memory + <braunr> you'd have two copies of them, the one loaded by grub, and the one + shared by normal executables + <antrik> no + <braunr> i prefer static linking because, if done correctly, the combined + size of the root file system and the disk driver should be smaller than + that of the rootfs+disk driver and libraries loaded by grub + <antrik> apparently I was not quite clear how my approach would work :-( + <braunr> probably not + <antrik> (preventing that is actually the reason why I do *not* want as + simple boot filesystem+chroot approach) + <braunr> and initramfs can be easily freed after init + <braunr> an* + <braunr> it wouldn't be a chroot but something a bit more involved like + switch_root in linux + <antrik> not if various servers use files provided by that init filesystem + <antrik> yes, that's the complex handoff I'm talking about + <braunr> yes + <braunr> that's one approach + <antrik> as I said, that would be a quite elegant approach (allowing a + dynamically linked ext2); but it would be much more complicated to + implement I believe + <braunr> how would it allow a dynamically linked ext2 ? + <braunr> how can the root file system be linked with code backed by itself + ? + <braunr> unless it requires wiring all its memory ? + <antrik> it would be loaded from the init filesystem before the handoff + <braunr> init sn't the problem here + <braunr> i understand how it would boot + <braunr> but then, you need to make sure the root fs is never used to + service page faults on its own address space + <braunr> or any address space it depends on, like the disk driver + <braunr> so this basically requires wiring all the system libraries, glibc + included + <braunr> why not + <antrik> ah. yes, that's something I covered in a separate section in my + thesis ;-) + <braunr> eh :) + <antrik> we have to do that anyways, if we want *any* dynamically linked + components (such as the disk driver) in the paging path + <braunr> yes + <braunr> and it should make swapping more reliable too + <antrik> so that adds a couple MiB of wired memory... I guess we will just + have to live with that + <braunr> yes it seems acceptable + <braunr> thanks + <antrik> (it is actually one reason why I want to avoid static linking as + much as possible... so at least we have to wire these libraries only + *once*) + <antrik> anyways, back to my "simpler" approach + <antrik> the idea is that a (static) ext2fs would still be the first task + running, and immediately able to serve filesystem access requests -- only + it would serve these requests from files preloaded by GRUB rather than + the actual disk driver + <braunr> i understand now + <antrik> until a switch is flipped telling it that now the disk driver (and + anything it depends upon) is operational + <braunr> you still need to make sure all this is wired + <antrik> yes + <antrik> that's orthogonal + <antrik> which is why I have a separate section about it :-) + <braunr> what was the relation with ggi ? + <antrik> none strictly speaking + <braunr> i'll rephrase it: how did it end up in your thesis ? + <antrik> I just covered all aspects of userspace drivers in one of the + "introduction" sections of my thesis + <braunr> ok + <antrik> before going into specifics of KGI + <antrik> (and throwing in along the way that most of the issues described + do not matter for KGI ;-) ) + <braunr> hehe + <braunr> i'm wondering, do we have mlockall on the hurd ? it seems not + <braunr> that's something deeply missing in mach + <antrik> well, bootstrap in general *is* actually relevant for KGI as well, + because of console messages during boot... but the filesystem bootstrap + is mostly irrelevant there ;-) + <antrik> braunr: oh? that's a problem then... I just assumed we have it + <braunr> well, it's possible to implement MCL_CURRENT, but not MCL_FUTURE + <braunr> or at least, it would be a bit difficult + <braunr> every allocation would need to be aware of that property + <braunr> it's better to have it managed by the vm system + <braunr> mach-defpager has its own version of vm_allocate for that + <antrik> braunr: I don't think we care about MCL_FUTURE here + <antrik> hm, wait... MCL_CURRENT is fine for code, but it might indeed be a + problem for dynamically allocated memory :-( + <braunr> yes + + +# Plan + + * Examine what other systems are doing. + + * L4 + + * Hurd on L4: deva, fabrica + + * [[/DDE]] + + * Minix 3 + + * Start with a simple driver and implement the needed infrastructure (see + *Issues* above) as needed. + + * <http://savannah.nongnu.org/projects/user-drivers/> + + Some (unfinished?) code written by Robert Millan in 2003: PC keyboard + and parallel port drivers, using `libtrivfs`. + + +## I/O Server + +### IRC, freenode, #hurd, 2012-08-10 + + <braunr> usually you'd have an I/O server, and serveral device drivers + using it + <bddebian> Well maybe that's my question. Should there be unique servers + for say ISA, PCI, etc or could all of that be served by one "server"? + <braunr> forget about ISA + <bddebian> How? Oh because the ISA bus is now served via a PCI bridge? + <braunr> the I/O server would merely be there to help device drivers map + only what they require, and avoid conflicts + <braunr> because it's a relic of the past :p + <braunr> and because it requires too high privileges + <bddebian> But still exists in several PCs :) + <braunr> so usually, you'd directly ask the kernel for the I/O ports you + need + <mel-> so do floppy drives + <mel-> :) + <braunr> if i'm right, even the l4 guys do it that way + <braunr> he's right, some devices are still considered ISA + <bddebian> But that is where my confusion lies. Something has to figure + out what/where those I/O ports are + <braunr> and that's why i tell you to forget about it + <braunr> ISA has both statically allocated ports (the historical ones) and + others usually detected through PnP, when it works + <braunr> PCI is much cleaner, and memory mapped I/O is both better and much + more popular currently + <bddebian> So let's say I have a PCI SCSI card. I need some device driver + to know how to talk to that, right? + <bddebian> something is going to enumerate all the PCI devices and map them + to and address space + <braunr> bddebian: that would be the I/O server + <braunr> we'll call it the PCI server + <bddebian> OK, that is where I am headed. What if everything isn't PCI? + Is the "I/O server" generic enough? + <youpi> nowadays everything is PCI + <bddebian> So we are completely ignoring legacy hardware? + <braunr> we could have separate servers using a shared library that would + provide allocation routines like resource maps + <braunr> yes + <youpi> for what is not, the translator just needs to be run as root + <youpi> to get i/o perm from the kernel + <braunr> the idea for projects like ours, where the user base is very small + is: don't implement what you can't test + <youpi> bddebian: legacy can not be supported in a nice way, so for them we + can just afford a bad solution + <youpi> i.e. leave the driver in kernel + <braunr> right + <youpi> e.g. the keyboard + <bddebian> Well what if I have a USB keyboard? :-P + <braunr> that's a different matter + <youpi> USB keyboard is not legacy hardware + <youpi> it's usb + <youpi> which can be enumerated like pci + <braunr> and USB uses PCI + <youpi> and pci could be on usb :) + <braunr> so it's just a separate stack on top of the PCI server + <bddebian> Sure so would SCSI in my example above but is still a seperate + bus + <braunr> netbsd has a very nice way of attaching drivers to buses + <youpi> bddebian: also, yes, and it can be enumerated + <bddebian> Which was my original question. This magic I/O server handles + all of the buses? + <youpi> no, just PCI, and then you'd have other servers for other busses + <braunr> i didn't mean that there would be *one* I/O server instance + <bddebian> So then it isn't a generic I/O server is it? + <bddebian> Ahhhh + <youpi> that way you can even put scsi over ppp or other crazy things + <braunr> it's more of an idea + <braunr> there would probably be a generic interface for basic stuff + <braunr> and i assume it could be augmented with specific (e.g. USB) + interfaces for servers that need more detailed communication + <braunr> (well, i'm pretty sure of it) + <bddebian> So the I/O server generalizes all functions, say read and write, + and then the PCI, USB, SCIS, whatever servers are contacted by it? + <braunr> no, not read and write + <braunr> resource allocation rather + <youpi> and enumeration + <braunr> probing perhaps + <braunr> bddebian: the goal of the I/O server is to make it possible for + device drivers to access the resources they need without a chance to + interfere with other device drivers + <braunr> (at least, that's one of the goals) + <braunr> so a driver would request the bus space matching the device(s) and + obtain that through memory mapping + <bddebian> Shouldn't that be in the "global address space"? SOrry if I am + using the wrong terminology + <youpi> well, the i/o server should also trigger the start of that driver + <youpi> bddebian: address space is not a matter for drivers + <braunr> bddebian: i'm not sure what you think of with "global address + space" + <youpi> bddebian: it's just a matter for the pci enumerator when (and if) + it places the BARs in physical address space + <youpi> drivers merely request mapping that, they don't need to know about + actual physical addresses + <braunr> i'm almost sure you lost him at BARs + <braunr> :( + <braunr> youpi: that's what i meant with probing actually + <bddebian> Actually I know BARs I have been reading on PCI :) + <bddebian> I suppose physicall address space is more what I meant when I + used "global address space" + <braunr> i see + <youpi> bddebian: probably, yes + + +# Documentation + + * [An Architecture for Device Drivers Executing as User-Level + Tasks](http://portal.acm.org/citation.cfm?id=665603), 1993, David B. Golub, + Guy G. Sotomayor, Freeman L. Rawson, III + + * [Performance Measurements of the Multimedia Testbed on Mach 3.0: Experience + Writing Real-Time Device Drivers, Servers, and + Applications](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.8685), + 1993, Roger B. Dannenberg, David B. Anderson, Tom Neuendorffer, Dean + Rubine, Jim Zelenka + + * [User Level IPC and Device Management in the Raven + Kernel](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.3733), + 1993, D. Stuart Ritchie, Gerald W. Neufeld + + * [Creating User-Mode Device Drivers with a + Proxy](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.26.3055), + 1997, Galen C. Hunt + + * [The APIC Approach to High Performance Network Interface Design: Protected + DMA and Other + Techniques](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1198), + 1997, Zubin D. Dittia, Guru M. Parulkar, Jerome R. Cox, Jr. + + * [The Fluke Device Driver + Framework](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.4.7927), + 1999, Kevin Thomas Van Maren + + * [Omega0: A portable interface to interrupt hardware for L4 + system](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.21.5958), + 2000, Jork Löser, Michael Hohmuth + + * [Userdev: A Framework For User Level Device Drivers In + Linux](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.4461), + 2000, Hari Krishna Vemuri + + * [User Mode Drivers](http://www.linuxjournal.com/article/5442), 2002, Bryce + Nakatani + + * [Towards Untrusted Device + Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.1725), + 2003, Ben Leslie, Gernot Heiser + + * [Encapsulated User-Level Device Drivers in the Mungi Operating + System](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.1531), + 2004, Ben Leslie Nicholas, Nicholas FitzRoy-Dale, Gernot Heiser + + * [Linux Kernel Infrastructure for User-Level Device + Drivers](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.1408), + 2004, Peter Chubb + + * [Get More Device Drivers out of the + Kernel!](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6333), + 2004, Peter Chubb + + * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> + + * [Initial Evaluation of a User-Level Device + Driver](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.4531), + 2004, Kevin Elphinstone, Stefan Götz + + * [User-level Device Drivers: Achieved + Performance](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6766), + 2005, Ben Leslie, Peter Chubb, Nicholas FitzRoy-Dale, Stefan Götz, Charles + Gray, Luke Macpherson, Daniel Potts, Yueting Shen, Kevin Elphinstone, + Gernot Heiser + + * [Virtualising + PCI](http://www.ice.gelato.org/about/oct06_presentations.php#pres14), 2006, + Myrto Zehnder, Peter Chubb + + * [Microdrivers: A New Architecture for Device + Drivers](http://www.cs.rutgers.edu/~vinodg/papers/hotos2007/), 2007, Vinod + Ganapathy, Arini Balakrishnan, Michael M. Swift, Somesh Jha + + * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.109.2623> + [[!tag open_issue_documentation]] + + * <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.146.2170> + [[!tag open_issue_documentation]] + + +# External Projects + + * [[/DDE]] + + * <http://ertos.nicta.com.au/research/drivers/uldd/> + + * <http://gelato.unsw.edu.au/IA64wiki/UserLevelDrivers> diff --git a/open_issues/usleep.mdwn b/open_issues/usleep.mdwn new file mode 100644 index 00000000..b71cd902 --- /dev/null +++ b/open_issues/usleep.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2012 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, OFTC, #debian-hurd, 2012-07-14 + + <pinotree> eeek, usleep has the issues which i fixed in nanosleep + <bdefreese> pinotree: ? + * pinotree ponders a `mv sysdeps/unix/sysv/linux/usleep.c + sysdeps/mach/usleep.c` + <pinotree> s/mv/cp/ + <bdefreese> What the heck is the point of usleep(0) anyway? Isn't that + basically saying suspend for 0 milliseconds? + <youpi> it's rounded up by the kernel I guess + <youpi> i.e. suspend for the shortest time possible (a clock tick) + <pinotree> posix 2001 says that «If the value of useconds is 0, then the + call has no effect.» diff --git a/open_issues/viengoos_make_clean.mdwn b/open_issues/viengoos_make_clean.mdwn new file mode 100644 index 00000000..af2920e7 --- /dev/null +++ b/open_issues/viengoos_make_clean.mdwn @@ -0,0 +1,22 @@ +[[!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_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge: If I do a make clean n the root directory, follow that with a configure, configure fails with: configure: error: C compiler cannot create executables + <neal> this is in config.log: /home/neal/src/hurd-l4/build/lib/gcc/i686-pc-viengoos-gnu/4.2.2/../../../../i686-pc-viengoos-gnu/bin/ld: cannot find -lc + <neal> rt + <tschwinge> neal: Should make clean also remove srcdir/gcc/gcc and binutils, as you do it with newlib? + <neal> I'd prefer it not to + <neal> as I use make clean to prep the tree for new configure changes + <neal> and build gcc takes a long time + <neal> (as does newlib, but newlib in this case needs to be rebuilt) diff --git a/open_issues/viengoos_tls_gcc.mdwn b/open_issues/viengoos_tls_gcc.mdwn new file mode 100644 index 00000000..92499903 --- /dev/null +++ b/open_issues/viengoos_tls_gcc.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_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge : I'm trying to enable tls for viengoos. This requires compiling gcc with --enable-tls, which enables threading, which pulls in libpthread, which requires newlib headers. + <neal> tschwinge : Unfortunately, I don't see how to install the newlib headers without having gcc + <neal> tschwinge : Have you got any ideas? diff --git a/open_issues/virtual_square_view-os.mdwn b/open_issues/virtual_square_view-os.mdwn new file mode 100644 index 00000000..dcc98785 --- /dev/null +++ b/open_issues/virtual_square_view-os.mdwn @@ -0,0 +1,55 @@ +[[!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]]."]]"""]] + +All the following is based only on a first, and quick glance only. + +We may want to have a look at Virtual Square / View-OS, and evaluate in which +ways this is related / implemented / implementable / usable / useful in a Hurd +environment, and even ;-) strive to collaborate with them. + +[[I|tschwinge]] found this project very much by chance: on LinkedIn, they +posted a proposal for [DevRoom on Virtualization +Technologies](http://www.linkedin.com/groupItem?view=&gid=27213&type=member&item=31720076) +for [[community/meetings/FOSDEM_2011]]. LinkedIn sends out such posts in very +opaque emails from time to time (probably they'd look less opaque with a HTML +mail user agent), and I even bothered to have a look at it, and follow the link +to the web page, and not delete it straightway. + +So, I had a quick look at the project: + +This seems to be an amalgamation / combination of various virtualization +mechanisms / projects / ideas. Virtualization is here meant in a broad sense, +including file system namespaces: our `chroot` / `settrans --chroot`; +networking configurations: our pfinet override stuff; system configuration: +subhurds?; current time, devices: likewise?; executable interpreter: our exec +server override stuff; "stat" virtualization: fakeroot; etc. -- They seem to +do a lot of stuff that we also try to do / could do / can do. + +In fact, this looks a bit like they're trying to bring some more of the Hurd's +[[hurd/concepts]] over to Unix / Linux, more than only the *usual VFS stuff* +(translators / FUSE). + +Perhaps start reading with the *slides* linked below. + + * <http://virtualsquare.org/> + + * <http://wiki.virtualsquare.org/> + + * <http://sourceforge.net/projects/view-os/> + + * Renzo Davoli, [*Virtual + Square*](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.108.9106), + 2005 + + * Renzo Davoli, Michael Goldweber, [*View-OS: Change your View on + Virtualization*](http://www.cs.unibo.it/~renzo/view-os-lk2009.pdf), + Proc. of Linux Kongress, 2009 + + * [slides](http://www.cs.unibo.it/~renzo/view-os-lk2009-slides.pdf) diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn new file mode 100644 index 00000000..d0608b4a --- /dev/null +++ b/open_issues/virtualbox.mdwn @@ -0,0 +1,137 @@ +[[!meta copyright="Copyright © 2011, 2012 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]]."]]"""]] + +[[!toc]] + + +# Running GNU Mach in VirtualBox crashes during initialization. + +[[!tag open_issue_gnumach]] + + +## IRC, freenode, #hurd, 2011-08-15 + + <BlueT_> 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. + + <BlueT_> root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54 + <BlueT_> copyoutmsg + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:1289 + <BlueT_> exec_load + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/elf-load.c:80 + <BlueT_> user_bootstrap + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:756 + + i386/i386/locore.S:1289 is + + movl $USER_DS,%eax /* use user data segment for accesses */ + => mov %ax,%es + + State is + + cs: 0x8 + ds: 0x10 + es: 0x10 + fs: 0 + gs: 0 + ss: 0x10 + eax: 0x1f + ecx: 0x8048000 + edx: 0x15fb7f + ebx: 0x1001000 + esp: 0x75e47e08 + ebp: 0x75e47e6c + esi: 0x1002000 + edi: 0x8048000 + eip: 0x106c93 + efl: 0x10206 + + <youpi> oh, wait, it's not even the data access which poses problem + <youpi> but the use of $USER_DS + <youpi> ew + <youpi> looks like a gdt initialization emulation issue in virtualbox... + + + <BlueT_> just found that at the second crash, the address is different + <BlueT_> 2nd time: + <BlueT_> addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x1068bd 0x152c74 + <BlueT_> _kret_popl_es + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../i386/i386/locore.S:527 + <BlueT_> user_bootstrap + <BlueT_> /home/buildd/build/chroot-sid/home/buildd/byhand/gnumach/build-dbg/../kern/bootstrap.c:765 + + 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: + + cs: 0x8 + ds: 0x10 + es: 0x10 + fs: 0 + gs: 0 + ss: 0x10 + eax: 0x106c95 + ecx: 0x6aab096c + edx: 0x106cec + ebx: 0x75e47f04 + esp: 0x75e47f0c + ebp: 0x75e47fac + esi: 0x75e47f8c + edi: 0x7fffff3c + eip: 0x1068bd + efl: 0x10216 + + <youpi> looks again like a $USER_DS issue + <youpi> what's interesting is that that one means that $USER_DS did load in + %es fine at least once + <youpi> and it's the reload that fails + + +# Slow SCSI probing + +[[!tag open_issue_gnumach]] + + +## IRC, freenode, #hurd, 2012-08-07 + + <braunr> youpi: it seems the slow boot on virtualbox is really because of + scsi (it spends a long time in scsi_init, probing for all the drivers) + <youpi> braunr: we know that + <youpi> isn't it in the io port probe printed at boot? + <youpi> iirc that was that + <braunr> the discussion i found was about eata + <braunr> not the whole scsi group + <youpi> there used to be another in eata, yas + <braunr> oh + <braunr> i must have missed the first discussion then + <youpi> I mean + <youpi> the eata is the first + <braunr> ok + <youpi> and scsi was mentioned later + <youpi> just nobody took the time to track it down + <braunr> ok + <braunr> so it's not just a matter of disabling a single driver :( + <youpi> braunr: I still believe it's a matter of disableing a single driver + <youpi> I don't see why scsi in general should take a lot of time + <braunr> youpi: it doesn't on qemu, it may simply be virtualbox's fault + <youpi> it is, yes + <youpi> and virtualbox people say it's hurd's fault, of course + <braunr> both are possible + <braunr> but we can't expect them to fix it :) + <youpi> that's what I mean diff --git a/open_issues/virtualization.mdwn b/open_issues/virtualization.mdwn new file mode 100644 index 00000000..343f624a --- /dev/null +++ b/open_issues/virtualization.mdwn @@ -0,0 +1,46 @@ +[[!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]] + +An index of things to work on w.r.t. virtualization. + + * [[/virtualization]] + + * [[hurd/virtualization|hurd/virtualization]] + + * [[GSoC project proposal|community/gsoc/project_ideas/virtualization]] + + * [[hurd/subhurd]] / [[hurd/neighborhurd]] + +<!-- + + * There's talking about *collectives* in the Hurd RM, on [[/advantages]] and + [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]). + +--> + + * [[Implementing_Hurd_On_Top_of_Another_System]] + + * Unix / Linux + + * [[Capsicum]] + + * [[Virtual_Square_View-OS]] + + * [Namespace file descriptors](http://lwn.net/Articles/407495/), + 2010-09-29 + + * [Divorcing namespaces from + processes](http://lwn.net/Articles/377109/), 2010-03-03 + + * [[File_Systems]] + + * [[Networking]] diff --git a/open_issues/virtualization/capsicum.mdwn b/open_issues/virtualization/capsicum.mdwn new file mode 100644 index 00000000..44503e34 --- /dev/null +++ b/open_issues/virtualization/capsicum.mdwn @@ -0,0 +1,22 @@ +[[!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]]."]]"""]] + +*Capsicum - practical capabilities for UNIX* + +<http://www.cl.cam.ac.uk/research/security/capsicum/> + +<http://www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/> +(server disappeared; [Google +cache](http://webcache.googleusercontent.com/search?q=cache:cCAqjWOhhksJ:www.lightbluetouchpaper.org/2010/08/12/capsicum-practical-capabilities-for-unix/)) + +<http://lackingrhoticity.blogspot.com/2010/10/process-descriptors-in-freebsd-capsicum.html> + +<http://www.cl.cam.ac.uk/research/security/capsicum/slides/20100811-usenix-capsicum.pdf> +/ <http://www.youtube.com/watch?v=raNx9L4VH2k> diff --git a/open_issues/virtualization/file_systems.mdwn b/open_issues/virtualization/file_systems.mdwn new file mode 100644 index 00000000..a12ea10d --- /dev/null +++ b/open_issues/virtualization/file_systems.mdwn @@ -0,0 +1,24 @@ +[[!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]] + +Of course, it is possible to use commodity file systems on [[virtualized +systems|virtualization]], like [[hurd/translator/ext2fs]] or +[[hurd/translator/nfs]], but there are also other possibilities which ought to +be explored. + + * [[network_file_system_by_just_forwarding_RPCs]] + + * Linux saw a patch for [*generic name to handle and open by handle + syscalls*](http://thread.gmane.org/gmane.linux.file-systems/46648) posted, + which in turn can be beneficial for a [[QEMU]] emulation of a 9P file + system. LWN's Jonathan Corbet covered this [*open by + handle*](http://lwn.net/Articles/375888/) functionality on 2010-02-23. diff --git a/open_issues/virtualization/networking.mdwn b/open_issues/virtualization/networking.mdwn new file mode 100644 index 00000000..7a6474a1 --- /dev/null +++ b/open_issues/virtualization/networking.mdwn @@ -0,0 +1,30 @@ +[[!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]] + +Collection about stuff that is relevant for *virtualization* and *networking*. + + * [[Virtual_Square_View-OS]] + + * [*Virtual Networks*](http://virtualsquare.org/vn.html) + + * [User Level Networking](http://uln.sourceforge.net/) + + * [Virtual Distributed Ethernet](http://vde.sourceforge.net/) + + * [Application Level + Environment4Networking](http://sourceforge.net/projects/ale4net/) + + *Ale4NET used dyn library call diversion to define networking at process + level.* -- what we're doing with our approach for overriding the default + [[hurd/translator/pfinet]] by setting environment variables. + + Project is now part of [[Virtual_Square_View-OS]]. diff --git a/open_issues/vm_map_kernel_bug.mdwn b/open_issues/vm_map_kernel_bug.mdwn new file mode 100644 index 00000000..613c1317 --- /dev/null +++ b/open_issues/vm_map_kernel_bug.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2012 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_gnumach]] + + +# IRC, frenode, #hurd, 2012-11-04 + + <tschwinge> braunr, pinotree, youpi: Has either of you already figured out + what [glibc]/sysdeps/mach/hurd/dl-sysdep.c:fmh »XXX loser kludge for + vm_map kernel bug« is about? + <pinotree> tschwinge: ETOOLOWLEVELFORME :) + <pinotree> tschwinge: 5bf62f2d3a8af353fac661b224fc1604d4de51ea added it + <braunr> tschwinge: no, but that looks interesting + <braunr> i'll have a look later + <tschwinge> Heh, "interesting". ;-) + <tschwinge> It seems related to vm_map's mask + parameter/ELF_MACHINE_USER_ADDRESS_MASK, though the latter in only used + in the mmap implementation in sysdeps/mach/hurd/dl-sysdep.c (in mmap.c, 0 + is passed; perhaps due to the bug?). + <tschwinge> braunr: Anyway, I'd already welcome a patch to simply turn that + into a more comprehensible form. + <braunr> tschwinge: ELF_MACHINE_USER_ADDRESS_MASK is defined as "Mask + identifying addresses reserved for the user program, where the dynamic + linker should not map anything." + <braunr> about the vm_map parameter, which is a mask, it is described by + "Bits asserted in this mask must not be asserted in the address returned" + <braunr> so it's an alignment constraint + <braunr> the kludge disables alignment, apparently because gnumach doesn't + handle them correctly for some cases + <tschwinge> braunr: But ELF_MACHINE_USER_ADDRESS_MASK is 0xf8000000, so I'd + rather assume this means to restrict to addresses lower than 0xf8000000. + (What are whigher ones reserved for?) + <braunr> tschwinge: the linker i suppose + <braunr> tschwinge: sorry, i don't understand what + ELF_MACHINE_USER_ADDRESS_MASK really is used for :/ + <braunr> tschwinge: it looks unused for the other systems + <braunr> tschwinge: i guess it's just one way to partition the address + space, so that the linker knows where to load libraries and mmap can + still allocate large contiguous blocks + <braunr> tschwinge: 0xf8000000 means each "chunk" of linker/other blocks + are 128 MiB large + <tschwinge> braunr: OK, thanks for looking. I guess I'll ask Roland about + it. + <braunr> it could be that gnumach isn't good at aligning to large values + +[[!message-id "87fw4pb4c7.fsf@kepler.schwinge.homeip.net"]] diff --git a/open_issues/wait_errors.mdwn b/open_issues/wait_errors.mdwn new file mode 100644 index 00000000..855b9add --- /dev/null +++ b/open_issues/wait_errors.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2012 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_hurd]] + +# IRC, freenode, #hurd, 2012-07-12 + + <braunr> tschwinge: have you encountered wait() errors ? + <tschwinge> What kind of wait errors? + <braunr> when running htop or watch vmstat, other apparently unrelated + processes calling wait() sometimes fail with an error + <braunr> i saw it mostly during builds, as they spawn lots of children + <braunr> (and used the aforementioned commands to monitor the builds) + <tschwinge> Sounds nasty... No, don't remember seeing that. But I don't + typiclly invoke such commands during builds. + <tschwinge> So this wait thing suggests there's something going wrong in + the proc server? + <braunr> tschwinge: yes diff --git a/open_issues/wayland.mdwn b/open_issues/wayland.mdwn new file mode 100644 index 00000000..67f78b1d --- /dev/null +++ b/open_issues/wayland.mdwn @@ -0,0 +1,33 @@ +[[!meta copyright="Copyright © 2012 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_porting]] + +IRC, freenode, #hurd, 2012-03-18: + + <antrik> Wayland should be very portable. all the system dependencies are + in the infrastructure, such as DRI + <antrik> we have had a DRI task (for X.Org) for years + <antrik> (in fact I would be the right person to implement this, + considering my background -- by quite frankly, I doubt I'll ever do it) + <tschwinge> http://xorg.freedesktop.org/wiki/Hurd_Porting + +IRC, freenode, #hurd, 2012-03-20: + + <youlysses> Is wayland something that will be semi-easy to port to the + hurd? I saw GNOME is heading in this direction. + <pinotree> wayland at the moment is linux only + <tschwinge> youlysses: A DRI implementation will be needed. + <pinotree> that, and libdrm compiling + <youlysses> So it will take some work ... but theres no *HUGE* design + decison that would inhibit it? + <pinotree> i know it uses epoll, for instance + <tschwinge> youlysses: I cannot judge how complex a DRI system is, and how + much needs to be designed vs. implemented. diff --git a/open_issues/whole_system_debugging.mdwn b/open_issues/whole_system_debugging.mdwn new file mode 100644 index 00000000..b438c5cf --- /dev/null +++ b/open_issues/whole_system_debugging.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2012 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_gdb open_issue_gnumach]] + +Given our distributed system structure, it'd be immensely useful then when a +[[RPC]] to another entitiy is made, [[GDB]] followed suit. + +[[GDB]] does have some *multi-process* debugging infrastructure which should +basically be usable for this. + +[[`mach_msg`|microkernel/mach/message]] is the *great barrier*, of course. diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn new file mode 100644 index 00000000..65e6c584 --- /dev/null +++ b/open_issues/wine.mdwn @@ -0,0 +1,69 @@ +[[!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 +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_porting]] + +On 2010-11-28, Austin English contacted us, stating that he's working on +porting [Wine](http://winehq.org/) to the GNU/Hurd. + +It is not yet clear how difficult this is going to be, what sort of +requirements Wine has: only libc / POSIX / etc., or if there are +*advanced* things like [[system_call]] trapping involved, too. + +[[Samuel|samuelthibault]] suspects that *there's some need for LDT table +allocation. There is kernel support for this,* however. + + +IRC, freenode, #hurd, 2011-08-11 + + < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, + and to that end, I've successfully compiled the latest sources from Git + after installing the libc (devel) packages from experimental and + personally patching Wine with http://pastebin.com/rg6dx09G + +[[rg6dx09G.patch]] + + < arethusa> my question is, when trying to launch Wine, I'm seeing "wine + client error:0: sendmsg: (os/kern) invalid address" from the client side, + whereas the wineserver seems to be starting and running correctly, how + could I debug this issue further? using rpctrace doesn't seem to help, as + the trace just hangs when run on the Wine loader instead of yielding + insight + < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when + wine encounters an error or something like that ? + < arethusa> it's too early for that + < kilobug> or least give you a full traceback of the wine code where the + error occur ? + < arethusa> the error is happening during initial connect to the + wineserver, in dlls/ntdll/server.c + < arethusa> but that doesn't help me figure out why sendmsg would error out + in this way + < arethusa> + http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361 + < azeem_> arethusa: probably some of the msghdr entries are not supported + by the Hurd's glib + < azeem_> c + < pinotree> haha, socket credentials, which we don't support yet + < azeem_> yep + < pinotree> youpi: ↑ another case ;) + < azeem_> arethusa: just implement those and it should work + < kilobug> in pflocal ? or glibc ? + < pinotree> pflocal + < arethusa> azeem_: hmm, okay, thanks + < pinotree> arethusa: their lack is a known issue, and makes things like + dbus and gamin not work + < arethusa> it's + https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and + related links I assume? + +[[sendmsg_scm_creds]] + + < youpi> yes + < pinotree> (but that patch is lame) diff --git a/open_issues/wine/rg6dx09G.patch b/open_issues/wine/rg6dx09G.patch new file mode 100644 index 00000000..510ff23f --- /dev/null +++ b/open_issues/wine/rg6dx09G.patch @@ -0,0 +1,116 @@ +diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c
+index 42b3639..7484608 100644
+--- a/dlls/ntdll/directory.c
++++ b/dlls/ntdll/directory.c
+@@ -3145,14 +3145,14 @@ static void WINAPI read_changes_user_apc( void *arg, IO_STATUS_BLOCK *io, ULONG
+ static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc )
+ {
+ struct read_changes_info *info = user;
+- char data[PATH_MAX];
++ char data[4096];
+ NTSTATUS ret;
+ int size;
+
+ SERVER_START_REQ( read_change )
+ {
+ req->handle = wine_server_obj_handle( info->FileHandle );
+- wine_server_set_reply( req, data, PATH_MAX );
++ wine_server_set_reply( req, data, 4096 );
+ ret = wine_server_call( req );
+ size = wine_server_reply_size( reply );
+ }
+diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c
+index 6c8e8e2..e949227 100644
+--- a/dlls/ntdll/signal_i386.c
++++ b/dlls/ntdll/signal_i386.c
+@@ -180,6 +180,36 @@ __ASM_GLOBAL_FUNC(vm86_enter,
+
+ #endif /* linux */
+
++#ifdef __GNU__
++
++typedef ucontext_t SIGCONTEXT;
++
++#define EAX_sig(context) ((context)->uc_mcontext.gregs[REG_EAX])
++#define EBX_sig(context) ((context)->uc_mcontext.gregs[REG_EBX])
++#define ECX_sig(context) ((context)->uc_mcontext.gregs[REG_ECX])
++#define EDX_sig(context) ((context)->uc_mcontext.gregs[REG_EDX])
++#define ESI_sig(context) ((context)->uc_mcontext.gregs[REG_ESI])
++#define EDI_sig(context) ((context)->uc_mcontext.gregs[REG_EDI])
++#define EBP_sig(context) ((context)->uc_mcontext.gregs[REG_EBP])
++#define ESP_sig(context) ((context)->uc_mcontext.gregs[REG_ESP])
++
++#define CS_sig(context) ((context)->uc_mcontext.gregs[REG_CS])
++#define DS_sig(context) ((context)->uc_mcontext.gregs[REG_DS])
++#define ES_sig(context) ((context)->uc_mcontext.gregs[REG_ES])
++#define SS_sig(context) ((context)->uc_mcontext.gregs[REG_SS])
++#define FS_sig(context) ((context)->uc_mcontext.gregs[REG_FS])
++#define GS_sig(context) ((context)->uc_mcontext.gregs[REG_GS])
++
++#define EFL_sig(context) ((context)->uc_mcontext.gregs[REG_EFL])
++#define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP])
++#define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO])
++#define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR])
++
++#define FPU_sig(context) ((FLOATING_SAVE_AREA *)&(context)->uc_mcontext.fpregs.fp_reg_set.fpchip_state)
++#define FPUX_sig(context) NULL
++
++#endif /* __GNU__ */
++
+ #ifdef BSDI
+
+ #include <machine/frame.h>
+diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c
+index 9649df8..cdd1798 100644
+--- a/dlls/shell32/shfldr_unixfs.c
++++ b/dlls/shell32/shfldr_unixfs.c
+@@ -369,7 +369,7 @@ static inline BOOL UNIXFS_is_pidl_of_type(LPCITEMIDLIST pIDL, SHCONTF fFilter) {
+ static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, char *pszCanonicalPath)
+ {
+ char *pPathTail, *pElement, *pCanonicalTail, szPath[FILENAME_MAX], *pszUnixPath, has_failed = 0, mb_path[FILENAME_MAX];
+- WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[PATH_MAX], *dospath_end;
++ WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[MAX_PATH], *dospath_end;
+ int cDriveSymlinkLen;
+ void *redir;
+
+diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c
+index ad8e08b..a8d6329 100644
+--- a/dlls/winex11.drv/xrender.c
++++ b/dlls/winex11.drv/xrender.c
+@@ -2440,8 +2440,8 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev)
+ return;
+ }
+
+-BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc,
+- struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn )
++BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, struct bitblt_coords *dst,
++ X11DRV_PDEVICE *devSrc, struct bitblt_coords *src, BLENDFUNCTION blendfn )
+ {
+ FIXME("not supported - XRENDER headers were missing at compile time\n");
+ return FALSE;
+diff --git a/libs/wine/ldt.c b/libs/wine/ldt.c
+index 3098061..b3fee13 100644
+--- a/libs/wine/ldt.c
++++ b/libs/wine/ldt.c
+@@ -96,6 +96,11 @@ static inline int set_thread_area( struct modify_ldt_s *ptr )
+ #include <i386/user_ldt.h>
+ #endif
+
++#ifdef __GNU__
++#include <mach/i386/mach_i386.h>
++#include <mach/mach_traps.h>
++#endif
++
+ /* local copy of the LDT */
+ #ifdef __APPLE__
+ struct __wine_ldt_copy wine_ldt_copy = { { 0, 0, 0 } };
+@@ -203,6 +208,9 @@ static int internal_set_entry( unsigned short sel, const LDT_ENTRY *entry )
+ #elif defined(__APPLE__)
+ if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) < 0)
+ perror("i386_set_ldt");
++#elif defined(__GNU__)
++ if ((ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry, 1)) != KERN_SUCCESS)
++ perror("i386_set_ldt");
+ #else
+ fprintf( stderr, "No LDT support on this platform\n" );
+ exit(1);
\ No newline at end of file diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn new file mode 100644 index 00000000..558c93b7 --- /dev/null +++ b/open_issues/xattr.mdwn @@ -0,0 +1,45 @@ +[[!meta copyright="Copyright © 2011, 2012 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="xattr: extended attributes"]] + +[[!tag open_issue_glibc open_issue_hurd]] + +This task is listed as a [[Google Summer of Code project +idea|community/gsoc/project_ideas/xattr]]. + +IRC, freenode, #hurd, 2011-06-01: + + <gnu_srs> Another thing: the lsattr and chattr programs seems to be bogus + on Hurd. Are they present since they are part of e2fsprogs? + <youpi> I don't think the Hurd has an interface for it + <tschwinge> gnu_srs, youpi: lsattr/chattr are extended attributes, right? + We do have some patches from years ago for adding some support in glibc, + but they're not yet integrated. And also we do have a plan for using + these instead of our Hurd-specific passive translator information in + inodes. + +If interested in working on this, talk to [[tschwinge]], and see these resources: + + * [[!GNU_Savannah_task 5503]], [[!GNU_Savannah_patch 5126]] + + * <http://lists.gnu.org/archive/html/bug-hurd/2006-02/threads.html#00115>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-01/threads.html#00180>, + <http://lists.gnu.org/archive/html/bug-hurd/2006-05/threads.html#00042> + + * <http://www.spinics.net/lists/linux-ext4/msg07260.html>, + <http://www.spinics.net/lists/linux-ext4/msg07259.html>, + <http://www.spinics.net/lists/linux-ext4/msg07261.html> + + +IRC, OFTC, #debian-hurd, 2012-03-18: + + <pinotree> notes to self: it seems our ext2 driver comes from linux 2.3.42 + or so, and in linux 2.5.46 ext2/ext3 get xattr and acl support diff --git a/open_issues/xen_crash_copy-size_le_page_size.mdwn b/open_issues/xen_crash_copy-size_le_page_size.mdwn new file mode 100644 index 00000000..f2d8081e --- /dev/null +++ b/open_issues/xen_crash_copy-size_le_page_size.mdwn @@ -0,0 +1,104 @@ +[[!meta copyright="Copyright © 2009 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]] + +`/dev/hd2` is 2 GiB in size (backed by LVM), unformatted. + + # mkfs.ext2 -o hurd /dev/hd2 + mke2fs 1.41.7 (29-June-2009) + hd2 count 1 + re-open, hd2 count 2 + ext2fs_check_if_mount: Can't check if filesystem is mounted due to missing mtab file while determining whether /dev/hd2 is mounted. + re-open, hd2 count 3 + re-open, hd2 count 4 + re-open, hd2 count 5 + Filesystem label= + OS type: Hurd + Block size=4096 (log=2) + Fragment size=4096 (log=2) + 131072 inodes, 524288 blocks + 26214 blocks (5.00%) reserved for the super user + First data block=0 + Maximum filesystem blocks=536870912 + 16 block groups + 32768 blocks per group, 32768 fragments per group + 8192 inodes per group + Superblock backups stored on blocks: + 32768, 98304, 163840, 229376, 294912 + + Assertion `copy->size <= PAGE_SIZE' failed in file "../gnumach-1-branch-Xen-branch/xen/block.c", line 536 + Kernel Breakpoint trap, eip 0x20020a77 + Stopped at 0x20020a76: int $3 + db> trace + 0x20020a76(2006abc1,2006ba03,2006782c,218,2e2be8d4) + 0x20020ace(2006ba03,2006782c,218,2e3629a0,32000) + 0x2003e9d5(2de04764,2e2be0b8,12,0,3fff80) + 0x200476e6(2de5ad54,2e2db010,2e30a9a0,2de3a854,2de5ad44) + 0x20021ed4(2de5ad44,2e2bb2e0,2e2bb2a0,0,0) + 0x2005309d(129b8f0,3,38,28,e) + 0x20006838(129b8f0,3,38,28,e) + >>>>> user space <<<<< + + + $ addr2line -i -f -e /boot/gnumach-xen 0x20020a76 0x20020ace 0x2003e9d5 0x200476e6 0x20021ed4 0x2005309d 0x20006838 + Debugger + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/debug.c:105 + Assert + ??:0 + device_write + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/xen/block.c:537 + _Xdevice_write + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/device/device.server.c:253 + ipc_kobject_server + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/kern/ipc_kobject.c:201 + mach_msg_trap + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/ipc/mach_msg.c:1367 + mach_call_call + /home/tschwinge/tmp/gnumach/gnumach-1-branch-Xen-branch.build/../gnumach-1-branch-Xen-branch/i386/i386/locore.S:1083 + +GDB on `mkfs.ext2`: + + raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272 + 272 actual = write(data->dev, buf, size); + (gdb) print size + $4 = 32768 + (gdb) bt + #0 raw_write_blk (channel=0x80829d8, data=0x8082a40, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:272 + #1 0x080635fc in unix_write_blk64 (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:673 + #2 0x0806373c in unix_write_blk (channel=0x80829d8, block=524272, count=8, buf=0x80a0a60) at ../../../git/lib/ext2fs/unix_io.c:705 + #3 0x0805e87d in ext2fs_zero_blocks (fs=0x8082940, blk=524272, num=16, ret_blk=0x15ffb1c, ret_count=0x0) + at ../../../git/lib/ext2fs/mkjournal.c:182 + #4 0x0804ec56 in main (argc=131072, argv=0x80000) at ../../git/misc/mke2fs.c:2032 + +Discussion: + + <tschwinge> I had a look at the code, but unfortunately don't really know + how this data transfers between Xen and the domU work. + <tschwinge> Well, I know how it roughly works, but not the implementation + deatils. + <youpi> well here it's not about the xen/domU transfers + <youpi> it's about copying data to align it + <youpi> i.e. when offset is not aligned, I need to copy it + <tschwinge> Yes- + <youpi> I was lazy, just implemented it for things smaller than a page + <youpi> it just needs to be extended into copying several pages + <tschwinge> youpi: Hmm, do we need to copy all the data to shift away the + offset or is there a better way? + <youpi> the blkbackend needs data to be sector-aligned + <youpi> just aligning on a page makes offset computation simpler + <youpi> as it's rare that's not a problem + <tschwinge> And a sector is the usual 512 bytes there, I assume? + <tschwinge> But then we do need to copy all of it? + <youpi> let me check + <youpi> the sector is the granularity you can't go below + <youpi> sector is the sector_size reported by the backend + <youpi> but for sector_number and first/last_sect it's 512 + <youpi> yes, that's weird diff --git a/open_issues/xen_domu_with_ro_hd.mdwn b/open_issues/xen_domu_with_ro_hd.mdwn new file mode 100644 index 00000000..efbd2d18 --- /dev/null +++ b/open_issues/xen_domu_with_ro_hd.mdwn @@ -0,0 +1,35 @@ +[[!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="Xen domU with a read-only HD"]] + +[[!tag open_issue_xen]] + +read-only hd3 + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 5 + re-open, hd3 count 6 + /dev/hd3 was not cleanly unmounted, check forced. + Pass 1: Checking inodes, blocks, and sizes + Pass 2: Checking directory structure + Pass 3: Checking directory connectivity + Pass 4: Checking reference counts + Pass 5: Checking group summary information + /dev/hd3: 2729/262144 files (0.2% non-contiguous), 34116/524288 blocks + Error writing block 1 (Attempt to write block from filesystem resulted in short write). Ignore error<y>? yes + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 7 + re-open, hd3 count 8 + e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hd3 + Could this be a zero-length partition? diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn new file mode 100644 index 00000000..756abf5e --- /dev/null +++ b/open_issues/xen_lseek.mdwn @@ -0,0 +1,57 @@ +[[!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-09-01: + + <youpi> hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + <youpi> no wonder it's slow + <youpi> unfortunately that's also what it does on linux, the system call is + just less costly + <youpi> apparently gfortran calls io_seek for, like, every token of the + sourced file + <youpi> (fgetpos actually, but that's the same) + <youpi> and it is indeed about 10 times slower under Xen for some reason + +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]]. + +Also see the simple testcases [[test-lseek.c]] and [[test-mach.c]]. + +IRC, freenode, #hurd, 2011-11-05: + + <youpi> [test-mach.c is] mostly as a reference for the trap overhead + <youpi> 0.56µs (xen) vs 0.48µs(kvm) on test-mach + <youpi> 455µs(xen) vs 16µs(kvm) on test-lseek + <youpi> that might simply be an issue in the RPC mechanism, which behaves + badly with the xen memory management + <youpi> yes, about 0.5ms for an lseek, that's quite high :) diff --git a/open_issues/xen_lseek/test-lseek.c b/open_issues/xen_lseek/test-lseek.c new file mode 100644 index 00000000..667dce66 --- /dev/null +++ b/open_issues/xen_lseek/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/xen_lseek/test-mach.c b/open_issues/xen_lseek/test-mach.c new file mode 100644 index 00000000..90337346 --- /dev/null +++ b/open_issues/xen_lseek/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/xorg_porting.mdwn b/open_issues/xorg_porting.mdwn new file mode 100644 index 00000000..5f540e44 --- /dev/null +++ b/open_issues/xorg_porting.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2012 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="X.Org Porting"]] + +[[!tag open_issue_porting]] + +See the list of [Hurd-related X.Org project +ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting). |