diff options
Diffstat (limited to 'open_issues')
25 files changed, 835 insertions, 2600 deletions
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn index d4bfb4a3..aa49e64b 100644 --- a/open_issues/64-bit_port.mdwn +++ b/open_issues/64-bit_port.mdwn @@ -13,78 +13,163 @@ License|/fdl]]."]]"""]] [[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]] -There is some initial support in the master branch. -As of 2012-11-20, it only supports the [[microkernel/mach/gnumach/ports/Xen]] platform for now. - **What is left for initial support (32-on-64) is** - * add 64bit boot support from grub's multiboot - * implement 32/64 RPC compatibility for RPCs served by kernel. - -See [[http://lists.gnu.org/archive/html/bug-hurd/2012-04/msg00000.html]] + * Fixing bugs :) **For pure 64bit support, we need to** - * add 64bit definitions in binutils - * add 64bit definitions in gcc - * implement 64bit variants of code in glibc/sysdeps/mach/i386 and glibc/sysdeps/mach/hurd/i386 - * implement 64bit variants of code in libpthread/sysdeps/i386, libpthread/sysdeps/mach/i386, libpthread/sysdeps/mach/hurd/i386 - * fetch from Linux 64bit variant of code in ./pfinet/linux-src/arch/i386 and ./pfinet/linux-src/include/asm-i386 - * define the mig ABI - * bootstrap a distrib, e.g. Debian hurd-amd64 (see [[https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_hurd-amd64_gcc8/]] ) - -# 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 - -[[mig_portable_rpc_declarations]]. - - -# 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 :) - - -## IRC, freenode, #hurd, 2013-07-02 - -In context of [[mondriaan_memory_protection]]. - - <xscript> BTW, it's not like I have an infinite amount of time for this, - but having 64-bit support would be valuable for me, so I might contribute - that back if it's not a too monumental task - <xscript> I saw some discussions about 32bit apps on top of 64bit mach, but - I'd like a full 64bit system - <xscript> any clues? - <xscript> I suppose the compiler support is all there already - <xscript> is MIG (and mach) the only piece missing? - <braunr> the problem is the interfaces themselves - <braunr> type widths - <braunr> as passed between userspace and kernel - - -## IRC, OFTC, #debian-hurd, 2013-10-05 - - <dharc> and what about 64 bit support, almost done? - <youpi> kernel part is done - <youpi> MIG 32/64 trnaslation missing - -[[mig_portable_rpc_declarations]]. + * bootstrap a distrib + * port gdb + * Fix bugs :) + * Notably it seems to be requiring at least 2G memory to boot. + +**Installing a 64bit chroot** + +You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz and boot that. + +Make sure to have `debootstrap >= 1.0.128+nmu2+hurd.1` + + debootstrap --foreign --verbose --arch hurd-amd64 --include=debian-keyring,wget,curl,inetutils-ping,openssh-server,openssh-client,nano,less --keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64 https://people.debian.org/~sthibault/tmp/hurd-amd64 + mkdir chroot-hurd-amd64/etc/apt/trusted.gpg.d + ln -s /usr/share/keyrings/debian-keyring.gpg chroot-hurd-amd64/etc/apt/trusted.gpg.d/ + +Then boot it, it will drop you into a shell. You'll probably want to use a nicer shell: + + bash + +You need to make / writable: + + fsysopts / --writable + +and then run the second stage of the deboostrap (and clear debs): + + /debootstrap/debootstrap --second-stage + apt clean + +set a root password: + + passwd + +Avoid core dumpings for now (not supported and hangs): + + rm -f /servers/crash + ln -s crash-kill /servers/crash + +Disable the Hurd console, buggy for now: + + export TERM=mach + nano /etc/default/hurd + # set ENABLE to 'false' + +And reboot: + + reboot-hurd + +After reboot, you'll probably want to setup network: + + vi /etc/network/interfaces + # put there this: + auto /dev/eth0 + iface /dev/eth0 inet static + address 10.0.2.15/16 + gateway 10.0.2.2 + +**Creating a 64bit disk image** + +You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/disk-amd64.img.gz and boot that. + +To make a bootable system we really better make the disk image partitioned, and mount the partition: + + dd < /dev/zero > disk.img bs=1M count=1 seek=1000 + fdisk disk.img + # create a new primary partition spanning the whole disk: n p and just accept the defaults, and finish with w + settrans -ca disk /hurd/storeio -T typed file:disk.img + settrans -ca disk1 /hurd/storeio -T typed part:1:file:disk.img + mke2fs disk1 + settrans -ca chroot-hurd-amd64 /hurd/ext2fs disk1 + +(here we assume that fdisk puts the partition at sector 2048, that's indeed the +current default behavior) + +Then run the same debootstrap command as above. + +You can then make the disk bootable: + + mkdir chroot-hurd-amd64/boot/grub + tee chroot-hurd-amd64/boot/grub/grub.cfg << 'EOF' + set default="0" + set timeout=5 + menuentry "Debian GNU/Hurd amd64" { + insmod ext2 + set root=(hd0,1) + multiboot /boot/gnumach-1.8-486.gz root=part:1:device:wd0 + module /hurd/pci-arbiter.static pci-arbiter \ + --host-priv-port='${host-port}' --device-master-port='${device-port}' \ + --next-task='${disk-task}' \ + '$(pci-task=task-create)' '$(task-resume)' + module /hurd/rumpdisk.static rumpdisk \ + --next-task='${fs-task}' \ + '$(disk-task=task-create)' + module /hurd/ext2fs.static ext2fs --readonly \ + --multiboot-command-line='${kernel-command-line}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(fs-task=task-create)' + module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' + } + EOF + grub-install --modules="part_msdos ext2" --boot-directory chroot-hurd-amd64/boot disk + settrans -ga chroot-hurd-amd64 + settrans -ga disk + settrans -ga disk1 + +Then boot it, and proceed like for the chroot case. + +**Creating a pbuilder chroot** + +Here is a sample `/etc/pbuilderrc`: + + MIRRORSITE=https://people.debian.org/~sthibault/tmp/hurd-amd64 + AUTOCLEANAPTCACHE=yes + EXTRAPACKAGES="eatmydata" + if [ -z "$LD_PRELOAD" ]; then + LD_PRELOAD=libeatmydata.so + else + LD_PRELOAD="$LD_PRELOAD":libeatmydata.so + fi + export LD_PRELOAD + DEBOOTSTRAPOPTS=( + '--variant=buildd' + '--force-check-gpg' + '--keyring=/usr/share/keyrings/debian-keyring.gpg' + ) + APTKEYRINGS=(/usr/share/keyrings/debian-keyring.gpg) + +And this is needed until we get the `aptitude` package built: + + sudo ln -sf pbuilder-satisfydepends-apt /usr/lib/pbuilder/pbuilder-satisfydepends + +And then you can run `sudo pbuilder create` , `sudo pbuilder login` , `pdebuild` + +**Installing from the debian-ports archive** + +For now it's quite empty (not even gcc), but it can be debootstrapped. That will be used to build packages on the buildds. + + debootstrap --foreign --verbose --arch hurd-amd64 --extra-suites=unreleased --include=debian-ports-archive-keyring --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid chroot-hurd-amd64 https://deb.debian.org/debian-ports/ + +**Installing proper & more packages** + +The `people.debian.org` repository is only for bootstraping the distribution. Proper packages are getting uploaded on the usual mirror: + +``` +deb http://deb.debian.org/debian-ports sid main +deb http://deb.debian.org/debian-ports unreleased main +``` + +**Installing a 64bit system** + +In principle crosshurd should be working, one however should add this source to get more packages for now: + + deb http://people.debian.org/~sthibault/tmp/hurd-amd64 unstable + +into /etc/crosshurd/sources.list/gnu diff --git a/open_issues/Upstart.mdwn b/open_issues/Upstart.mdwn deleted file mode 100644 index 1972e197..00000000 --- a/open_issues/Upstart.mdwn +++ /dev/null @@ -1,69 +0,0 @@ -[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - - -[[!template id=highlight text="""/!\ Obsolete /!\ - ---- - -[[systemd|Systemd]] has almost universally replaced upstart."""]] - -Upstart is an event based init system that is GPL licensed, however upstream -contributions are under a CLA that permits proprietary relicensing. - -Most major GNU/Linux distributions are choosing systemd as their init system -instead of upstart. The original upstart developers seem to have stopped -developing it. - -The following are the words of Colin Watson on the debian-ctte@lists.debian.org -mailing list and list the requirements of a potential HURD port: - ->I haven't looked at this in much detail, and I suspect Dimitri hasn't -yet although IIRC he did express some interest in doing so. But I -haven't seen anyone else try to outline the scope of a port, so let me -try to do so for the sake of general understanding. As far as I know, -the hardest parts would be inotify, ptrace, and prctl -(PR_SET_CHILD_SUBREAPER). - ->inotify is used to notice changes to configuration files. This is -certainly helpful for users, but it isn't critical as "initctl -reload-configuration" works without it. We could probably do without -this with the aid of a dpkg trigger. - ->ptrace is used for "expect fork" and "expect daemon"; as I indicated in -another post, I think it would be preferable to avoid these in Debian -and quite possibly to compile them out. (This would mean we wouldn't be -able to translate Ubuntu jobs quite as directly, and a number of -important jobs would definitely need to be changed, but the conversion -isn't usually particularly difficult.) - ->prctl (PR_SET_CHILD_SUBREAPER) is used to make SIGCHLD notification work -properly when Upstart is supervising a user session. This isn't a -required feature and could easily be compiled out until suitable kernel -support is available (this actually seems like the sort of thing that -could be done in the Hurd without too much difficulty, but I haven't -looked into it). If absent, it might well impede the ability to do an -advanced desktop port, but it wouldn't get in the way of porting the -bulk of services. - ->There might also be odds and ends around the details of wait status -handling. - -inotify seems to be a feature that is often used in GNU/Linux programs, and -implementing the feature in the HURD seems like a better and more rewarding -option than porting the code in Upstart. - -Although many daemons double fork, that behavior seems to be dying out, and -one can comfortably ignore the "expect fork/daemon" functionality of Upstart -(and compile it out). - -[[!tag open_issue_porting]] - -See also the discussion about upstart on the [[systemd]] page. diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn index a1c8a7d3..5f121ca6 100644 --- a/open_issues/alarm_setitimer.mdwn +++ b/open_issues/alarm_setitimer.mdwn @@ -58,7 +58,7 @@ This issue was recently fixed (around January 2013). (e19a2fad70b187e5efe79768f86a1f05cb5e0390, Tue Feb 21 02:41:18 2012) <braunr> yes, fixed :) <braunr> patch committed at - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix <youpi> and pushed to the debian package diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 82f2333c..9232186f 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1050,12 +1050,12 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <teythoon> as I said, the wire format is specified, the semantics only in written form in the source <teythoon> this is an example of the ipc specification for the proc server - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs <crocket> teythoon, how file server interacts with file clients should be defined as a formal protocol, too. <teythoon> do you consider the ipc description a kind of formal protocol ? <crocket> - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/process.defs can be considered as a formal protocol. <crocket> However, the file server protocol should be defined on top of IPC protocol. diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index 26e0b770..8a2bc27f 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -9,56 +9,152 @@ Sections, no 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. +Several people have expressed interested in a port of GNU/Hurd for the +ARM architecture. Luckily a userspace port of the Hurd servers and +glibc is underway. As early as January 1, 2024 an AArch64 port is +making some progress. Sergey did some hacking on glibc, binutils, +GCC, and added some headers to GNU Mach. He was able to build the +core Hurd servers: ext2fs, proc, exec, and auth. +One would think that he would need to port GNU Mach to run the +binaries, but Sergey ran a statically linked hello world executable on +GNU/Linux, under GDB, being careful to skip over and emulate syscalls +and RPCs. The glibc port has the TLS setup, hwcaps / cpu-features, +and ifuncs. -# IRC, freenode, #hurd, 2012-07-28 +Now to some of the more technical things: - <mcsim> Has anyone heard about porting hurd and gnu/mach to arm - architecture? - <braunr> mcsim: i think so - <braunr> mcsim: why are you asking ? - <mcsim> I found an article where author stated that he has ported hurd to - arm, but I have never met this information before. - <mcsim> He wrote ethernet driver and managed to use ping command - <mcsim> author's name is Sartakov Vasily - <braunr> well that's possible, a long time ago - <braunr> and it was probably not complete enough to be merged upstream - <braunr> like many other attempts at many other things - <mcsim> Not so long. Article is dated by June 2011. - <braunr> do you have a link ? - <mcsim> Yes, but it is in Russian. - <braunr> oh - <braunr> well i don't remember him sharing that with us - <antrik> mcsim: he did some work on porting Mach, but AIUI never got it - nearly finished - <antrik> nowadays he does L4 stuff - <antrik> was also at FOSDEM +- The TLS implementation is basically complete and working. We're +using `tpidr_el0` for the thread pointer (as can be seen in the listing +above), like GNU/Linux and unlike Windows (which uses x18, apparently) +and macOS (which uses `tpidrro_el0`). We're using "Variant I" layout, as +described in "ELF Handling for Thread-Local Storage", again same as +GNU/Linux, and unlike what we do on both x86 targets. This actually +ends up being simpler than what we had for x86! The other cool thing +is that we can do `msr tpidr_el0, x0` from userspace without any +gnumach involvement, so that part of the implementation is quite a bit +simpler too. +- Conversely, while on x86 it is possible to perform "cpuid" and +identify CPU features entirely in user space, on AArch64 this requires +access to some EL1-only registers. On Linux and the BSDs, the kernel +exposes info about the CPU features via `AT_HWCAP` (and more recently, +`AT_HWCAP2`) auxval entries. Moreover, Linux allows userland to read +some otherwise EL1-only registers (notably for us, `midr_el1`) by +catching the trap that results from the EL0 code trying to do that, +and emulating its effect. Also, Linux exposes `midr_el1` and +`revidr_el1` values through procfs. -## IRC, freenode, #hurd, 2012-10-09 +- The Hurd does not use `auxval`, nor is gnumach involved in `execve` anyway. +So I thought the natural way to expose this info would be with an RPC, +and so in `mach_aarch64.defs` I have an `aarch64_get_hwcaps` routine that +returns the two hwcaps values (using the same bits as `AT_HWCAP{,2}`) and +the values of `midr_el1`/`revidr_el1`. This is hooked to `init_cpu_features` +in glibc, and used to initialize `GLRO(dl_hwcap)` / `GLRO(dl_hwcap2)` and +eventually to pick the appropriate ifunc implementations. - <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. +- The page size (or rather, paging granularity) is notoriously not +necessarily 4096 on ARM, and the best practice is for userland not to +assume any specific page size and always query it dynamically. GNU +Mach will (probably) have to be built support for some specific page +size, but I've cleaned up a few places in glibc where things were +relying on a statically defined page size. +- There are a number of hardware hardening features available on AArch64 +(PAC, BTI, MTE — why do people keep adding more and more workarounds, +including hardware ones, instead of rewriting software in a properly +memory-safe language...). Those are not really supported right now; all +of them would require some support form gnumach side; we'll probably +need new protection flags (`VM_PROT_BTI`, `VM_PROT_MTE`), for one thing. -## IRC, freenode, #hurd, 2012-10-10 +We would need to come up with a design for how we want these to work +Hurd-wide. For example I imagine it's the userland that will be +generating PAC keys (and settings them for a newly exec'ed task), +since gnumach does not contain the functionality to generate random +values (nor should it); but this leaves an open question of what +should happen to the early bootstrap tasks and whether they can start +using PAC after initial startup. - <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... +- Unlike on x86, I believe it is not possible to fully restore +execution context (the values of all registers, including `pc` and +`cpsr`) purely in userland; one of the reasons for that being that we +can apparently no longer do a load from memory straight into `pc`, +like it was possible in previous ARM revisions. So the way `sigreturn +()` works on Linux is of course they have it as a syscall that takes a +`struct sigcontext`, and writes it over the saved thread state, which +is similiar to `thread_set_state ()` in Mach-speak. The difference +being that `thread_set_state ()` explicitly disallows you to set the +calling thread's state, which makes it impossible to use for +implementing `sigreturn ()`. So I'm thinking we should lift that +restriction; there's no reason why `thread_set_state ()` cannot be +made to work on the calling thread; it only requires some careful +coding to make sure the return register (`%eax`/`%rax`/`x0`) is *not* +rewritten with `mach_msg_trap`'s return code, unlike normally. +But other than that, I do have an AArch64 versions of `trampoline.c` +and `intr-msg.h` (complete with `SYSCALL_EXAMINE` & +`MSG_EXAMINE`). Whether they work, we'll only learn once we have +enough of the Hurd running to have the proc server. -## IRC, freenode, #hurd, 2012-10-17 +MIG seems to just work (thanks to all the Flávio's work!). We are +using the `x86_64` ABI, and I have not seen any issues so far — +neither compiler errors / failed static assertions (about struct sizes +and such), nor hardware errors from misaligned accesses. - <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. +To bootstrap gnumach someone must fix the console, set up the virtual +memory, thread states, context switches, irqs and userspace entry +points, etc. + +Also, there is a bunch of design work to do. + +Will/can AArch64 use the same mechanism for letting userland handle +interrupts? Do we have all the mechanisms required for userland to +poke at specific addresses in memory (to replace I/O ports)? — I +believe we do, but I haven't looked closely. + +AFAIK there are no I/O ports in ARM, the usual way to configure things +is with memory-mapped registers, so this might be easy. About IRQs, +probably it needs to be arch-specific anyway. + +What should the API for manipulating PAC keys look like? Perhaps it +should be another flavor of thread state, but then it is really +supposed to be per-task, not per-thread. Alternatively, we could add a +few aarch64-specific RPCs in `mach_arrch64.defs` to read and write the +PAC keys. But also AFAICS Mach currently has no notion of per-task +arch-specific data (unlike for threads, and other than the VM map), so +it'd be interesting to add one. Could it be useful for something +else? + +What are the debugging facilities available on ARM / AArch64? Should +we expose them as more flavors of thread state, or something else? +What would GDB need? + +Should gnumach accept tagged addresses (like `PR_SET_TAGGED_ADDR_CTRL` +on Linux)? + +Can we make Linux code (in-Mach drivers, pfinet, netdde, ...) work on +AArch64? + +One can trivially port pfinet to AArch64. Eventually, we should fix +any remaining issues with lwip. That way we can stop spending time +maintaining pfinet, which is Linux's old abandoned networking stack. + +Developers will have a difficult time porting the in-Mach drivers +(arm64 was probably not even a thing at the time). We can perhaps +port Netdde, but we should instead get our userspace drivers from a +rumpkernel. + +Starting the kernel itself should be easy, thanks to GRUB, but it +shouldn't be too hard to add support for U-Boot either if needed. + +I think more issues might come out setting up the various pieces of +the system. For example, some chips have heterogeneous cores, +(e.g. mine has two A72 cores and four A53 cores) so SMP will be more +complicated. + +Also, about the serial console, it might be useful at some point to +use a driver from userspace, if we can reuse some drivers from netbsd +or linux, to avoid embedding all of them in gnumach. # IRC, freenode, #hurd, 2012-11-15 diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn deleted file mode 100644 index df7294e9..00000000 --- a/open_issues/automatic_backtraces_when_assertions_hit.mdwn +++ /dev/null @@ -1,79 +0,0 @@ -[[!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/bash.mdwn b/open_issues/bash.mdwn index f6b14a08..a8a71810 100644 --- a/open_issues/bash.mdwn +++ b/open_issues/bash.mdwn @@ -46,14 +46,3 @@ After having noticed that this error doesn't occur if starting *bash* with bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID So, there's something different with stdout in / after the SIGINT handler. - - -# IRC, freenode, #hurd, 2013-01-13 - -Perhaps completely unrelated to the issue above, perhaps not. - - <tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot - allocate 261 bytes (323584 bytes allocated) - <tschwinge> 1.5 GiB RAM were free. - <tschwinge> This happened when I did a rever history search (C-r [...]), - and then pressed C-c. diff --git a/open_issues/bcachefs.mdwn b/open_issues/bcachefs.mdwn new file mode 100644 index 00000000..aa39bce0 --- /dev/null +++ b/open_issues/bcachefs.mdwn @@ -0,0 +1,326 @@ +[[!meta copyright="Copyright © 2007, 2008, 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]] + +The Hurd's primary filesystem is ext2, which works but lacks modern +features. With ext2, Hurd users reguarly deal with filesystem +corruption. Ext2 does not have a journal, so Hurd users occasionally +have to deal with filesystem corruption. `fsck` can fix most of the +issues (with loss of random data), but without a proper journal the +Hurd currently is not a good a OS for long-term data storage. + +Bcachefs is a modern COW (copy-on-write) open source filesystem for +Linux, which intends to replace Btrfs and ZFS while having the +performance of ext4 or XFS. It is almost 100,000 lines of code. +Btrfs is 150,000 lines of code. Bcachefs is structured as a +filesystem built on top of a database. There is a clean small +database transaction layer. That core database library is maybe +25,000 lines of code. + +Some Hurd developers recently [[talked with +Bcachefs|https://youtube.com/watch?v=bcWsrYvc5Fg]] author Kent +Overstreat about porting bcachefs to the Hurd. There are currently no +concrete plans to do so due to lack of developer man power. + +90% of the Bcachefs filesystem code builds and runs in userspace. It +uses a shim layer that makes maps kernel locking primatives to +pthreads, the kernel io API is mapped to AIO, etc. Bcachefs does +intend to eventually rewrite most or all of its current codebase into +rust. + +Kent is ok with us merging a shim layer for libstore that maps to the +Unix filesystem API. That would be a header file that goes into the +bcachefs code. + +There is a somewhat working FUSE port of bcachefs, but Kent is not +certain that is a good way to run bcachefs in userspace. Kent wants +to use the FUSE port to help in debbugging. Suppose bcachefs starts +acting up, then you could switch to running it in userspace and attach +GDB to the running process. This is currently not possible. + +We could port bcachefs to the Hurd's native filesystem API: libdiskfs. + +One interesting aspect of the conversation was Kent's goal of re-using +kernel code in userspace. The Linux kernel hashtable code is high +performance, resizeable, lockless, and builds and runs in userspace. +As long as you have liburcu, then you can use the kernel hashtable in +userspace on the Hurd. This might be useful to use on the Hurd. + +Bcachefs is liscensed as GPLv2, and many of Kent's previous employers +own the patents, including Google. Kent is ok with potentially making +the license GPLv2+, as long as there was not a promise to keep +bcachefs GPLv2 only. + +# IRC logs + +https://logs.guix.gnu.org/hurd/2023-09-26.log + + <solid_black> maybe I'm wrong though, do you know much about fuse? or file systems? + <damo22> no i dont know much about filesystems + <damo22> what is bcachefs? + <solid_black> see? :D + <azert> I agree that someone intimate in the Mach pager api, libdiskfs and fuse would be great at that meeting + <solid_black> I do kind of understand Mach VM / paging, I must say + <solid_black> from the looks of it, I even understand it best among those who have looked at it recently + <solid_black> and I mostly understand libdiskfs + <damo22> so go to the meeting + <damo22> what is fuse? do we even need it for hurd? + <damo22> file systems in userspace + <solid_black> FUSE is "filesystem in user space", it's both the name for the concept, and the name of Linux's specific mechanism, of offloading fs to userland + <damo22> yeah, i think it may be unneeded for filesystem on hurd + <solid_black> it's basically a giant hack that pretends to be a fileystem implementation to the rest of the kernel, and then sends requests and receives responses from a userland program that _actually_ implements the fs + <solid_black> on the Hurd, *of course* filesystems are implemented in userland, that's the only and tnhe natural way everything works + <solid_black> but that's where the similarities end + <solid_black> you cannot just take a linux fuse fs, using libfuse, and run it on the Hurd + <solid_black> there has been a project make a library that would have the same API as libfuse, but act as a Hurd translator, specifically to facilitate porting linux filesystems + <damo22> i imagine fuse has an api + <solid_black> last I heard, it was never completed, but who knows + <solid_black> it has a kerne <->userland protocol and a userspace library (libfuse) for implementing that protocol, yes + <damo22> solid_black: you seem to know more about fuse than you admitted + <solid_black> https://www.gnu.org/software/hurd/hurd/libfuse.html + <solid_black> I know the basics, around as much as I have just told you + <azert> I think that gnucode idea was that this would be the easiest to port bcachefs to the Hurd, but I doubt it would be the best + <solid_black> I have also hacked on a C++ fuse fs (darling-dmg), though I don't think I interacted with the fuse parts of it much + <azert> Or even the easier + <solid_black> yeah, I don't think it'd be the best or the easiest one either + <damo22> if someone implemented libfuse api and made it as a hurd translator, surely it would work natively? + <damo22> <braunr> zacts: the main problem seems to be the interactions between the fuse file system and virtual memory (including caching) + <braunr> something the hurd doesn't excel at + <braunr> it *may* be possible to find existing userspace implementations that don't use the system cache (e.g. implement their own) + <azert> Yes, that’s a possibility that needs to be kept open for discussion + <nikolar> Sounds interesting + <solid_black> youpi: ping + <youpi> pong + <solid_black> hello! + <solid_black> any thoughts on the above discussion? are you going to participate in the call that's being set up? + <youpi> I don't have time for it + <youpi> (AFAIK the fuse hurd implementation does work to some extent) + <solid_black> I should at least try out Hurd's fuse before the call, good idea + <solid_black> maybe read up on the Linux's fuse + <solid_black> thoughts on using fuse vs libdiskfs for bcachefs? + <youpi> using fuse would probably be less work + <youpi> and it'd probably mean fixing things in libfuse, which can benefit many other FS anyway + <solid_black> is it true that the "low level" API of libfuse is unimplemented and unimplementable? + <youpi> I don't know what that "low level" API is + <solid_black> this IIUC https://github.com/libfuse/libfuse/blob/master/include/fuse_lowlevel.h + <solid_black> > libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be se + <solid_black> nt explicitly using a separate set of API functions. + <youpi> where did you read that it'd be unimplementable ? + <solid_black> https://git.savannah.gnu.org/cgit/hurd/incubator.git/tree/README?h=libfuse/master + <solid_black> > This is simply because it is to specific to the Linux kernel and (besides that) it is not farly used now. + <youpi> In case the latter should change in the future, we might want to re-think about that issue though. + <solid_black> so, sounds like it's perhaps implementable in theory, but that'd require additional work and design + <youpi> see the sentence below... + <solid_black> the low-level API is what bcachefs uses + <youpi> well, additional work and design, of course + <solid_black> seems to, at least, from a quick glance + <youpi> any async API needs some + <youpi> but I don't see why it would not be possible + <youpi> mig precisely supports asynchronous stubs + <solid_black> bcachefs-tools/cmd_fusermount.c is just 1274 lines, which inspires some hope + <solid_black> asynchrony is not the problem, I imagine (but I haven't looked), but being too tied to Linux might be + <youpi> it's not really tied, as in it doesn't seem to use linux-specific functions + <youpi> but it uses linux-like notions, which indeed need to be translated to the hurdish notions + <youpi> but that's not something really tough + <youpi> just needs to be worked on + +https://logs.guix.gnu.org/hurd/2023-09-27.log#103329 + + <solid_black> libfuse as shipped as Debian doesn't seem very + functional, I can't even build a simple program against it: + 'i386-gnu/libfuse.so: undefined reference to `assert'' + + <solid_black> (assert is of course a macro in glibc) + <solid_black> and it segfaults in fuse_main_real + <solid_black> lowleve fuse ops do seem to map to netfs concept nicely, as far as I can see so far + <solid_black> and (again, so far) I don't see any asynchrony in how bcachefs uses fuse, i.e. they always fuse_reply() inside the method implementation + + <solid_black> but if we had to implement low-level fuse API, this would be an issue + <solid_black> because netfs is syncronous + <solid_black> this is again a place where I don't think netfs is actually that useful + <solid_black> libfuse should be its own standalone tranlator library, a peer to lib{disk,net,triv}fs + <solid_black> yell at me if you disagree + <youpi> or perhaps make it use libdiskfs ? + <youpi> there's significant code in libdiskfs that you'd probably not want to reimplement in libfuse + <solid_black> like what? + <youpi> starting a translator + <youpi> all the posix semantic bits + <solid_black> (this is another thing, I don't believe there is a significant difference that explains libdiskfs and libnetfs being two separate libraries. but it's too late to merge them, and I'm not an fs dev) + + <solid_black> starting a translator is abstracted into libfshelp specifically so it can be easily reused? + <solid_black> is libdiskfs synchronous? + <youpi> I'm just saying things out of my memory + <solid_black> scratch that, diskfs does not work like that at all + <youpi> piece of it is in fshelp yes + <solid_black> it works on pagers, always + <youpi> but significant pieces are in libdiskfs too + <youpi> and you are saying you are not an FS person :) + <youpi> you do know libdiskfs etc. well beyond the average + <youpi> perhaps not the ext2 FS structure, but that's not really important here + <youpi> see e.g. the short-circuits in file-get-trans.c + <solid_black> I may understand how the Hurd's translator libraries work, somewhat better than the avergae person :) + <youpi> and the code around fshelp_fetch_root + <solid_black> but I don't know about how filesystems are actually organized, on-disk (beyond the basics that there any inodes and superblocks and journaled writes and btrees etc) + <youpi> you don't really need to know more about that + <solid_black> nor do I know the million little things about how filesystem code should be written to be robust and performant + <solid_black> yeah so as I was saying, libdiskfs expects files to be mappable (diskfs_get_filemap_pager_struct), and then all I/O is implemented on top of that + <solid_black> e.g. to read, libdiskfs queries that pager from the impl, maps it into memory, and copies data from there to the reply message + <solid_black> I must have mentioned that already, I'd like to rewrite that code path some day to do less copying + <solid_black> I imagine this might speed up I/O heavy workloads + <youpi> ? it doesn't copy into the reply + <youpi> it transfers map + <solid_black> it does, let me find the code + <youpi> in some corner cases yes + <youpi> but not normal case + <youpi> https://darnassus.sceen.net/~hurd-web/hurd/io_path/ + <solid_black> libdiskfs/rdwr-internal.c, it does pager_memcpy, which is a glorified memcpy + fault handling + <solid_black> don't trust that wiki page + <youpi> why not ? + <youpi> not, pager_memcpy is not just a memcpy + <youpi> it's using vm_copy whenever it can + <youpi> i.e. map transfer + <solid_black> well yes, but doesn't the regular memcpy also attempt to do that? + <youpi> it happens to do so indeed + <youpi> but that' doesn't matter: I do mean it's trying *not* copying + <youpi> by going through the mm + <youpi> note: if a wiki page is bogus, propose a fix + <solid_black> I think there was another copy on the path somewhere (in the server, there's yet another in the client of course), but I can't quite remember where + <solid_black> and I wouldn't rely on that vm_copy optimization + <solid_black> it's may be useful when it working, but we have to design for there to not be a need to make a copy in the first place + <solid_black> ah well, pager_read_page does the other copy + <youpi> when things are not aligned etC. you'll have to do a copy anyway + <solid_black> but then again, this is all my idle observations, I'm not an fs person, I haven't done any profiling, and perhaps indeed all these copies are optimized away with vm_copy + <youpi> where in pager_read_page do you see a copy? + <youpi> it should be doing a store_read + <youpi> passing the pointer to the driver + <solid_black> ext2fs/pager.c:file_pager_read_page (at line 220 here, but I haven't pulled in a while) + <solid_black> it does do a store_read, and that returns a buffer, and then it may have to copy that into the buffer it's trying to return + <solid_black> though in the common case hopefully it'll read everything in a single read op + <youpi> it's in the new_buf != *buf + offs case + <youpi> which is not supposed to be the usual case + <solid_black> but now imagine how much overhead this all is + <youpi> what? the ifs? + <solid_black> we're inside io_read, we already have a buffer where we should put the data into + <youpi> I have to go give a course, gotta go + <solid_black> we could just device_read() into there + <youpi> you also want to use a cache + <youpi> otherwise it'll be the disk that'll kill yiour performance + <youpi> so at some point you do have to copy from the cache to the application + <youpi> that's unavoidable + <youpi> or if it's large, you can vm_copy + copy-on-write + <youpi> but basically, the presence of the cache means you can have to do copies + <youpi> and that's far less costly than re-reading from the disk + <solid_black> why can't you return the cache page directly from io_read RPC? + <youpi> that's vm_copy, yes + <youpi> but then if the app modifies the piece, you have to copy-on-write + <youpi> anywauy, really gottago + <solid_black> that part is handled by Mach + <solid_black> right, so once you're back: my conclusion from looking at libfuse is that it should be rewritten, and should not be using netfs (nor diskfs), but be its own independent translator framework + <solid_black> and it just sounds like I'm going to be the one who is going to do it + <solid_black> and we could indeed use bcachefs as a testbed for the low level api, and darling-dmg for the high level api + <solid_black> I installed avfs from Debian (one of the few packages that depend on libfuse), and sure enough: avfs: symbol lookup error: /lib/i386-gnu/libfuse.so.1: undefined symbol: assert_perror + <solid_black> upstream fuse is built with Meson 🤩️ + <solid_black> I'm wondering whether this would be better done as a port in the upstream libfuse, or as a Hurd-specific libfuse lookalike that borrows some code from the upstream one (as now) + <damo22> solid_black: what is your argument to rewrite a translator framework for fuse? + <damo22> i dont understand + <solid_black> hi + <damo22> hi + <solid_black> basically, 1. while the concepts of libfuse *lowlevel* api seem to match that of hurd / netfs, they seem sufficiently different to not be easily implementable on top of netfs + <solid_black> particularly, the async-ness of it, while netfs expects you to do everything synchronously + <damo22> is that a bug in netfs? + <solid_black> this could be maybe made to work, by putting the netfs thread doing the request to sleep on a condition variable that would get signalled once the answer is provided via the fuse api... but I don't think that's going to be any nicer than designing for the asynchrony from the start + <solid_black> it's not a bug, it's just a design decision, most Hurd tranalators are structured that way + <damo22> maybe you can rewrite netfs to be asynchronous and replace it + <solid_black> i.e.: it's rare that translators use MIG_NO_REPLY + explicit reply, it's much more common to just block the thread + <solid_black> 2. the current state is not "somewhat working", it's "clearly broken" + <damo22> why not start by trying to implement rumpdisk async + <damo22> and see what parts are missing + <solid_black> wdym rumpdisk async? + <damo22> rumpdisk has a todo to make it asynchronous + <damo22> let me find the stub + <damo22> * FIXME: + <damo22> * Long term strategy: + <damo22> * + <damo22> * Call rump_sys_aio_read/write and return MIG_NO_REPLY from + <damo22> * device_read/write, and send the mig reply once the aio request has + <damo22> * completed. That way, only the aio request will be kept in rumpdisk + <damo22> * memory instead of a whole thread structure. + <solid_black> ah right, that reminds me: we still don't have proper mig support for returning errors asynchronously + <damo22> if the disk driver is not asynchronous, what is the point of making the filesystem asynchronous? + <solid_black> the way this works, being asynchronous or not is an implementatin detail of a server + <solid_black> it doesn't matter to others, the RPC format is the same + <solid_black> there's probably not much point in asynchrony for a real disk fs like bcachefs, which must be why they don't use it and reply immediately + <solid_black> but imagine you're implementing an over-the-network fs with fuse, then you'd want asynchrony + <damo22> what is your goal here? do you want to fix libfuse? + <solid_black> I don't know + <solid_black> I'm preparing for the call with Kent + <solid_black> but it looks like I'm going to have to rewrite libfuse, yes + <damo22> possibly the caching is important + <damo22> ie, where does it happen + <solid_black> maybe, yes + <solid_black> does fuse support mmap? + <damo22> idk + <damo22> good q for kent + <solid_black> one essential fs property is coherence between mmap and r/w + <solid_black> so it you change a byte in an mmaped file area, a read() of that byte after that should already return the new value + <solid_black> same for write() + read from memory + <solid_black> this is why libdiskfs insists on reading/writing files via the pager and not via callbacks + <solid_black> I wonder how fuse deals with this + <damo22> good point, no idea + <solid_black> does fuse really make the kernel handle O_CREAT / O_EXCL? I can't imagine how that would work without racing + <solid_black> guess it could be done by trying opening/creating in a loop, if creation itself is atomic, but this is not nice + <damo22> something is still slowing down smp + <damo22> it cant possibly be executing as fast as possible on all cores + <damo22> if more cores are available to run threads, it should boot faster not slower + <azert> Hi damo22, your reasoning would hold if the kernel wouldn’t be “wasting” most of its time running in kernel mode tasks + <azert> If replacing CPU_NUMBER by a better implementation gave you a two digits improvement, that kind of implies that the kernel is indeed taking most of the cpu + <damo22> yes i mean, something in the kernel is slowing down smp + <azert> What about vm_map and all thread tasks synchronization + <azert> ? + <damo22> i dont understand how the scheduler can halt the APs in machine_idle() and not end up wasting time + <damo22> how does anything ever run after HLT + <damo22> in that code path + <damo22> if the idle thread halts the processor the only way it can wake up is with an interrupt + <damo22> but then, does MARK_CPU_ACTIVE() ever run? + <damo22> hmm it does + <azert> I think that normally the cpu would be running scheduler code and get a thread by itself. + <damo22> thats not how it works + <damo22> most of the cpus are in idle_continue + <damo22> then on a clock interrupt or ast interrupt, they are woken to choose a thread i think + <damo22> s/choose/run + <azert> If they are in cpu_idle then that’s what happens, yea + <azert> But normally they wouldn’t be in cpu idle but running the schedule and just a thread on their own + <azert> Cpu_idle basically turns off the cpu + <azert> To save power + <damo22> every time i interrupt the kernel debugger, its in cpu-idle + <damo22> i dont know if it waits until it is in that state so maybe thats why + <azert> That means that there is nothing to schedule + <azert> Or yea that’s another explanation + <damo22> yes, exactly i think it is seemingly running out of threads to schedule + <azert> A bug in the debugger + <damo22> i need to print the number of threads in the queue + <youpi> adding a show subcommand for the scheduler state would probably be useful + <youpi> solid_black: btw, about copies, there's a todo in rumpdisk's rumpdisk_device_read : /* directly write at *data when it is aligned */ + <solid_black> youpi: indeed, that looks relevant, and wouldn't be hard to do + <solid_black> ideally, it should all be zero-copy (or: minimal number of copies), from the device buffer (DMA? idk how this works, can dma pages be then used as regular vm pages?) all the way to the data a unix process receives from read() or something like that + <solid_black> without "slow" memcpies, and ideally with little vm_copies too, though transferring ages in Mach messages is ok + <solid_black> s/ages/pages/ + <solid_black> read() requires ones copy purely because it writes into the provided buffer (and not returns a new one), and we don't have mach_msg_overwrite + <solid_black> though again one would hope vm_copy would help there + <solid_black> ...I do think that it'd be easier to port bcachefs over to netfs than to rewrite libfuse though + <solid_black> but then nothing is going to motivate me to work on libfuse + <azert> solid_black: I never work on things that don’t motivate me somehow + <azert> Btw, if you want zerocopy for IO, I think you need to do asynchronous io + <azert> At least that’s the only way for me to make sense of zerocopy + <solid_black> I don't think sync vs async has much to do with zero-copy-ness? w + + diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index 407a104c..d9f05999 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -95,7 +95,7 @@ In context of [[select]]. ## IRC, freenode, #hurd, 2013-02-12 <braunr> pinotree: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a + https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a <pinotree> uh nice <pinotree> will need two small inline functions to convert time_data_t <-> timespec, but that's it diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn index e00c3d4e..21661f02 100644 --- a/open_issues/emacs.mdwn +++ b/open_issues/emacs.mdwn @@ -12,1531 +12,30 @@ License|/fdl]]."]]"""]] [[!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]] - +GNU Emacs works pretty well. It works beautifully in X. --- -# 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 /dev/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? +# 2024-01-14 -This is stock GNU Mach from Git, no patches, configured for Xen domU usage. +Emacs version 29.1 runs on Debian GNU/Hurd. Joshua Branson uses it in +X without issue. He use org-mode, gnus, erc, calc, markdown-mode, etc. +In fact he, edits this wiki via Debian GNU/Hurd (running on a T43) +using Emacs. He is able to make changes to the wiki, render the wiki, +look at the resulting webpage with the +[[netsurf|https://www.netsurf-browser.org/]] web browser, commit the +changes, and send a patch to `bug-hurd@gnu.org`, all while using the +Hurd. :) +Also since the Hurd ported rust, you can now use +[[treesitter|https://www.masteringemacs.org/article/how-to-get-started-tree-sitter]] +with Emacs! Joshua got +[[html-ts-mode|https://github.com/mickeynp/html-ts-mode]] working. -# IRC, freenode, #hurd, 2013-10-04 - <pinotree> given you are an emacs user: could you please pick the build - patch from deb#725099, recompile emacs24 and test it with your daily - work? +You can easily install many Emacs packages with apt: + # apt install elpa-zenburn-theme -## IRC, freenode, #hurd, 2013-10-07 +Or you can use `use-package`. - <gnu_srs> Wow! emacs24 runs in X:-D - <gnu_srs> pinotree: I've now built and installed emacs 24.3. So far so good - ^ - <pinotree> good, keep testing and stressing diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn deleted file mode 100644 index 05deaa7a..00000000 --- a/open_issues/exec.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no 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. - - <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 - -Justus: This doesn't seem to be an issue anymore (2013-09-08): - - % touch empty - % chmod +x empty - % ./empty - zsh: exec format error: ./empty - % bash - $ ./empty - $ - -Also I've never encountered a problem with apt. - - -## IRC, freenode, #hurd, 2013-08-01 - - <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code - all over it and it looks like that isn't even used anymore - <teythoon> that's too bad actually, I figured out how to get the values - from BFD, not so for the other elf parser that is used instead - - -## IRC, freenode, #hurd, 2013-08-05 - - <teythoon> btw, there is a Debian bug concerning zipped executables. now - I'm not sure if I understood the problem, but gziped and bzip2ed - executables work for me - <teythoon> (not that I'm a big fan of that particular feature) - <youpi> iirc these somehow got fixed yes - <youpi> something like a previous out of bound access - <teythoon> the exec server contains lot's of code that is unused and - probably bit rot (#ifdef BFD) or otherwise ignored (#if 0) - <youpi> yes :/ - <teythoon> and there's gunzipping and bunzip2ing, which we probably don't - want anyway - <pinotree> why not? - <teythoon> we should strip all that from exec and start adding features - <teythoon> pinotree: b/c it's slow and the gain is questionable - <teythoon> it breaks mmapping the code in - <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an - essential server - <teythoon> and I wonder if the unzipping is done securely, e. g. if it's - not possible to crash exec with an maliciously compressed executable - - -## IRC, freenode, #hurd, 2013-09-12 - - <rekado> The zip code in hurd/exec/ looks really complicated; does it - really just unpack zipped files in memory (which could be replaced by - library calls) or is there something else going on? - <braunr> rekado: - http://lists.gnu.org/archive/html/bug-hurd/2013-08/msg00049.html - <rekado> braunr: interesting. Thanks. - <rekado> Does this mean that the "small hack entry" on the contributing - page to use libz and libbz2 in exec is no longer valid? - <braunr> probably - ---- - -May want to have a look at using BFD / libiberty/simpleobject. - -Justus: The BFD code has been removed from the exec server. diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn deleted file mode 100644 index 1fc5a928..00000000 --- a/open_issues/exec_memory_leaks.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no 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]]. - -[[!toc]] - - -# 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 - - -# 2012-11-25 - -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 - - -# 2012-12-20 - -After running the libtool testsuite for some time: - - PID TH# UID PPID PGrp Sess TH Vmem RSS %CPU User System Args - 4 0 3 1 1 11 334M 203M 60.8 3:19.73 4hrs /hurd/exec - 0 0.0 0:20.33 27:02.47 - 1 0.0 0:31.10 32:21.13 - 2 0.0 0:25.68 27:42.33 - 3 0.0 0:00.00 0:00.00 - 4 5.1 0:34.93 34:07.59 - 5 0.0 0:19.56 28:44.15 - 6 3.4 0:18.73 28:17.89 - 7 0.0 0:20.47 34:42.51 - 8 39.5 0:15.60 28:48.57 - 9 0.0 0:04.49 10:24.12 - 10 12.8 0:08.84 19:34.45 - - -# IRC, freenode, #hurd, 2013-10-08 - - * braunr hunting the exec leak - <braunr> and i think i found it - <braunr> yes :> - <braunr> testing a bit more and committing the fix later tonight - <braunr> pinotree: i've been building glibc for 40 mins and exec is still - consuming around 1m memory - <pinotree> wow nice - <pinotree> i've been noticing exec leaking quite some time ago, then forgot - to pay more attention to that - <braunr> it's been more annoying since darnassus provides web access to - cgis - <braunr> automated tools make requests every seconds - <braunr> the leak occurred when starting a shell script or using system() - <braunr> youpi: not sure you saw it, i fixed the exec leak - - -## IRC, freenode, #hurd, 2013-10-10 - - <gg0> braunr: http://postimg.org/image/jd764wfpp/ - <braunr> exec 797M - <braunr> this should be fixed with the release of the next hurd packages diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index 7739f4d1..b34bd61e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -10,6 +10,193 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] +Mach is not always able to merge/coalesce mappings (VM entries) that +are made next to each other, leading to potentially very large numbers +of VM entries, which may slow down the VM functionality. This is said +to particularly affect ext2fs and bash. + +The basic idea of Mach designers is that entry coalescing is only an +optimization anyway, not a hard guarantee. We can apply it in the +common simple case, and just refuse to do it in any remotely complex +cases (copies, shadows, multiply referenced objects, pageout in +progress, ...). + +Suppose you define a special test program that intentionally maps +parts of a file next to each other and watches the resulting VM map +entries, and just ran a full Hurd system and observed results. + +One can stress test ext2fs in particular to check for VM entry +merging: + + # grep NR -r /usr &> /dev/null + # vminfo 8 | wc -l + +That grep opens and reads lots of files to simulate a long-running +machine (perhaps a build server); then one can look at the number of +mappings in ext2fs afterwards. Depending on how much your /usr is +populated, you will get different numbers. An older Hurd from say +2022, the above comand would result in 5,000-20,000 entries depending +on the machine! In June 2023, GNUMach gained some forward merging +functinality, which lowered the number of mappings down to 93 entries! + +(It is a separate question of why ext2fs makes that many mappings in +the first place. There could possible by a leak in ext2fs that would +be responsible for this, but none have been found so far. Possibly +another problem is that we have an unbounded node cache in libdiskfs +and Mach caching VM objects, which also keeps the node alive.) + +These are the simple forward merging cases that GNUMach now supports: + +- Forward merging: in `vm_map_enter`, merging with the next entry, in + addition to merging with the previous entry that was already there; + +- For forward merging, a `VM_OBJECT_NULL` can be merged in front of a + non-null VM object, provided the second entry has large enough + offset into the object to 'mount' the the first entry in front of + it; + +- A VM object can always be merged with itself (provded offsets/sizes + match) -- this allows merging entries referencing non-anonymous VM + objects too, such a file mappings; + +- Operations such as `vm_protect` do "clipping", which means splitting + up VM map entries, in case the specified region lands in the middle + of an entry -- but they were never "gluing" (merging, coalescing) + entries back together if the region is later vm_protect'ed back. Now + this is done (and we try to coalesce in some other cases too). This + should particularly help with "program break" (brk) in glibc, which + vm_protect's the pages allocated for the brk back and forth all the + time. + +- As another optimization, throw away unmapped physical pages when + there are no other references to the object (provided there is no + pager). Previously the pages would remain in core until the object + was either unmapped completely, or until another mapping was to be + created in place of the unmapped one and coalescing kicked in. + +- Also shrink the size of `struct vm_page` somewhat. This was a low + hanging fruit. + +`vm_map_coalesce_entry()` is analogous to `vm_map_simplify_entry()` in +other versions of Mach, but different enough to warrant a different +name. The same "coalesce" wording was used as in +`vm_object_coalesce()`, which is appropriate given that the former is +a wrapper for the latter. + +### The following provides clarifies some inaccuracies in old IRC logs: + + any request, be it e.g. `mmap()`, or `mprotect()`, can easily split + entries + +`mmap ()` cannot split entries to my knowledge, unless we're talking about +`MAP_FIXED` and unampping parts of the existing mappings. + + my ext2fs has ~6500 entries, but I guess this is related to + mapping blocks from the filesystem, right? + +No. Neither libdiskfs nor ext2fs ever map the store contents into memory +(arguably maybe they should); they just read them with `store_read ()`, +and then dispose of the the read buffers properly. The excessive number +of VM map entries, as far as I can see, is just heap memory. + + (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?) + + 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? + +`mem_obj` in `vminfo` output is the VM object *name* port, not the +pager port (arguably `vminfo` should name it something other than +`mem_obj`). The name port is basically useful for seeing if two VM +regions have the exact same VM object mapped, and not much +else. Previously, it was also possible, as a GNU Mach extension, to +pass the name port into `vm_map ()`, but this was dropped for security +reasons. When Mach is built with `MACH_VM_DEBUG`, a name port can also +be used to query information about a VM object. + +Mach can't merge two memory objects. Mach doesn't merge *memory objects* +at all, it only merges/coalesces *VM objects*. The difference is subtle, +but important in certain contexts like this one: a "VM object" refers to +Mach's internal representation (`struct vm_object`), and a "memory object" +refers to the memory manager's implementation. There is normally a +1-to-1 correspondence between the two, but this is not always the case: +internal VM objects start without a memory object (pager) port at all, +and only get one created if/when they're paged out. There can be +multiple VM objects referencing the same backing memory object due to +copying and shadowing. + +So what Mach could do is merge the internal VM objects, by altering +page offsets to paste pages of one of the objects after the pager of +the other. But this is not implemented yet. What Mach actually does is +it avoids creating those internal VM objects and entries in the first +place, instead extending an already existing VM object and entry to +cover the new mapping. + + 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 + +That never ever happens. There can only be a single `vm_object` for a +memory object. (In a single instance of Mach, that is -- if multiple +Machs access the same memory object over network-transparent IPC, each +is going to have its own `vm_object` representing the memory object.) + +See `vm_object_enter()` function, which looks up an existing VM object for +a memory object, and creates one if it doesn't yet exist. + + 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 ? + + yes + +No. The entries shown are VM map entries (`struct vm_map_entry`). There +can be entries that reference no VM object at all (`VM_OBJECT_NULL`), or +multiple entries that reference the same VM object. In fact this is +visible in the example above, the two entries mapped at `0x1311000` and at +`0x1314000` reference the same VM object, whose name port is 586. + +`mem_obj` listed is a send right to the *name* port of the VM object, not +to the memory object. Letting a task get the memory object port would be +disastrous for security (see the "No read-only mappings" vulnerability). + + i'm not sure about the type of the integer showed (port name or simply + an index) + +It is a port name (in vminfo's IPC name space) of the VM object name +port. + + if every `vm_allocate` request implies the creation of a memory object + from the default pager + +Not immediately, no. Only if the memory has to be paged out. Otherwise +an internal VM object is created without a memory object. + + and a `vm_object` is not a capability, but just an internal kernel + structure used to record the composition of the address space + +It is a kernel structure, but it also is a capability in the same way as +a task or a thread is a capability -- it is exposed as a port. +Specifically, a `memory_object_control_t` port is directly converted to a +`struct vm_object` by MIG. This would perhaps be clearer if +`memory_object_control_t` was instead named `vm_object_t`. The VM object +name port is also converted to a VM object, but this is only used in the +`MACH_VM_DEBUG RPCs`. + + i wonder when `vm_map_enter()` gets null objects though :/ + +Whenever you do `vm_map ()` with `MACH_PORT_NULL` for the object, or on +`vm_allocate ()` which is a shortcut for the same. + + the default pager backs `vm_objects` providing zero filled memory + +If that was the case, there would not be a need for a pager, Mach could +just hand out zero-filled pages. The anonymous mappings do start out +zero-filled, that is true. The default pager gets involved when the +pages are dirtied (so they no longer zero-filled) and there's memory +shortage so the pages have to paged out. + # IRC, freenode, #hurd, 2011-07-20 diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 1a06897b..3da5e558 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1163,7 +1163,7 @@ License|/fdl]]."]]"""]] ## 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 + https://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=master-pthreads <braunr> tschwinge: please tell me if you consider it ok for merging @@ -1646,13 +1646,13 @@ See also [[open_issues/libpthread/fix_have_kernel_resources]]. 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 + https://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 + https://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 diff --git a/open_issues/nice_changes_priority_of_parent_shell.mdwn b/open_issues/nice_changes_priority_of_parent_shell.mdwn deleted file mode 100644 index a8a08f90..00000000 --- a/open_issues/nice_changes_priority_of_parent_shell.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!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 deleted file mode 100644 index 1f4c6ab8..00000000 --- a/open_issues/nice_vs_mach_thread_priorities.mdwn +++ /dev/null @@ -1,429 +0,0 @@ -[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no 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, freenode, #hurd, 2010-08 - - <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 - - -## IRC, freenode, #hurd, 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 - - -# IRC, freenode, #hurd, 2012-12-29 - - <braunr> and, for a reason that i can't understand, there are less - priorities than nice levels, despite the fact mach was designed to run - unix systems on top of it .. - <youpi> btw, didn't we have a plan to increase that number? - <braunr> i have no idea - <braunr> but we should :) - <youpi> I remember some discussion about it on the list - - -## IRC, freenode, #hurd, 2012-12-31 - - <youpi> braunr: btw, we *do* have fixed the nice granularity - <youpi> +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20) - <youpi> in the debian package at least - <youpi> ah, no - <youpi> it's not applied yet - <youpi> so I have the patch under hand, just not applied :) - <braunr> but that's a simple shift - <braunr> the real problem is that there aren't as many mach priorities as - there are nice levels - <youpi> that's not really a problem - <youpi> we can raise that in the kernel - <youpi> the problem is the change from shifted to unshifted - <youpi> that brings odd nice values during the upgrade - <braunr> ok - <braunr> i hope the scheduler code isn't allergic to more priorities :) - - -## IRC, freenode, #hurd, 2013-01-02 - - <braunr> pochu: i see you were working on nice levels and scheduling code - some time ago - <braunr> pochu: anything new since then ? - <pochu> braunr: nope - <braunr> pochu: were you preparing it for the gsoc ? - <pochu> braunr: can't remember right now, either that or to fix a ftbfs in - debian - <youpi> iirc it's coreutils which wants proper nice levels - - -# IRC, OFTC, #debian-hurd, 2013-03-04 - - <Steap> Is it not possible to set the priority of a process to 1 ? - <Steap> these macros: - <Steap> #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12)) - <Steap> #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2)) - <Steap> are used in the setpriority() implementation of Hurd - <Steap> so setting a process' priority to 1 is just like setting it to 0 - <youpi> Steap: that has already been discussed to drop the *2 - <youpi> the issue is mach not supporting enough sched levels - <youpi> can be fixed, of course - <youpi> just nobody did yet - -GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit -6fe36b76f7983ec9a2e8a70420e431d54252442e). - - -## IRC, OFTC, #debian-hurd, 2013-03-07 - - <braunr> youpi: btw, why did you increase the number of priorites to 50 ? - <youpi> for the nice levels - <braunr> and probably something more, there are only 40 nice levels - <youpi> yes, the current computation leaves some margin - <youpi> so I preferred to keep a margin too - <braunr> ok - <youpi> e.g. for the idle thread, etc. - <braunr> or interrupt threads - <youpi> yep - <braunr> i see the point, thanks - <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that - a Linuxism? - <braunr> good question - <braunr> posix is weird when it comes to such old unixisms - <braunr> there is a NZERO value, but i don't remember how it's specified - <youpi> it's at least 20 - <tschwinge> (I don't object to the change; just wondered. And if practice, - you probably wouldn't really need more than a handful. But if that - change (plus some follow-up in glibc (?) improves something while not - adding a lot of overhead, then that's entirely fine, of course.) - <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0 - shall be imposed by the system" - <braunr> NZERO being 20 by default - <youpi> and 20 is the minimum for NZERO too - <braunr> hm, not the default, the minimul - <braunr> minimum - <braunr> yes that's it - <braunr> ok so it's actually well specified - <tschwinge> Aha, I see (just read it, too). So before that change we - simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20, - and allowing for step-1 increments. Alright. - <youpi> yep - <youpi> thus failing in coreutils testsuite diff --git a/open_issues/pci_arbiter.mdwn b/open_issues/pci_arbiter.mdwn index 7fdb4323..a6f8c893 100644 --- a/open_issues/pci_arbiter.mdwn +++ b/open_issues/pci_arbiter.mdwn @@ -25,7 +25,7 @@ sequential: gnumach, netdde, and then Xorg. The PCI Arbiter will eventually allo concurrent access to the PCI config space. The Hurd now has a PCI Arbiter, but it could use some more polishing. You can find -its TODO file [[here|http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/TODO]]. +its TODO file [[here|https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/TODO]]. Samuel also gave a presentation explaining some of the awesome possibilities that the PCI Arbiter can provide. You can watch his fosdem talk diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn deleted file mode 100644 index d386e5c0..00000000 --- a/open_issues/pthread_atfork.mdwn +++ /dev/null @@ -1,111 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no 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]] - -`pthread_atfork` is not actually implemented, making some programs fail. Code -can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`. - - -# IRC, OFTC, #debian-hurd, 2013-08-21 - - <pinotree> SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning: - pthread_atfork is not implemented and will always fail - - -# Samuel's implementation - -TODO. - - -## IRC, OFTC, #debian-hurd, 2013-10-08 - - <pinotree> youpi: if you need/want to test your pthread_atfork - implementation, you can check libposix-atfork-perl and its test suite - (whose test 004 hangs now, with eglibc -93) - <youpi> while it failed previously indeed - <youpi> we might simply need to rebuild perl against it - <youpi> (I see ifdef pthread_atfork in perl) - - -## undefined reference to `__start__hurd_atfork_prepare_hook' - -### IRC, freenode, #hurd, 2013-10-16 - - <teythoon> tschwinge: I'd love to try your cross-gnu tool, the wiki page - suggests that the list of required source packages is outdated. can you - give me some hints? - <teythoon> tschwinge: I got this error running cross-gnu: - http://paste.debian.net/58303/ - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/setjmp' - make subdir=string -C ../string ..=../ objdir=/home/teythoon/repos/hurd/cross/obj/glibc -f Makefile -f ../elf/rtld-Rules rtld-all rtld-modules='rtld-strchr.os rtld-strcmp.os rtld-strcpy.os rtld-strlen.os rtld-strnlen.os rtld-memchr.os rtld-memcmp.os rtld-memmove.os rtld-memset.os rtld-mempcpy.os rtld-stpcpy.os rtld-memcpy.os rtld-rawmemchr.os rtld-argz-count.os rtld-argz-extract.os rtld-stpncpy.os' - make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Entering directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[4]: Nothing to be done for `rtld-all'. - make[4]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/string' - make[3]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' - i686-pc-gnu-gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs -Wl,-dynamic-linker=/lib/ld.so.1 -B/home/teythoon/repos/hurd/cross/obj/glibc/csu/ -Wl,--version-script=/home/teythoon/repos/hurd/cross/obj/glibc/libc.map -Wl,-soname=libc.so.0.3 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both -nostdlib -nostartfiles -e __libc_main -L/home/teythoon/repos/hurd/cross/obj/glibc -L/home/teythoon/repos/hurd/cross/obj/glibc/math -L/home/teythoon/repos/hurd/cross/obj/glibc/elf -L/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn -L/home/teythoon/repos/hurd/cross/obj/glibc/nss -L/home/teythoon/repos/hurd/cross/obj/glibc/nis -L/home/teythoon/repos/hurd/cross/obj/glibc/rt -L/home/teythoon/repos/hurd/cross/obj/glibc/resolv -L/home/teythoon/repos/hurd/cross/obj/glibc/crypt -L/home/teythoon/repos/hurd/cross/obj/glibc/mach -L/home/teythoon/repos/hurd/cross/obj/glibc/hurd -Wl,-rpath-link=/home/teythoon/repos/hurd/cross/obj/glibc:/home/teythoon/repos/hurd/cross/obj/glibc/math:/home/teythoon/repos/hurd/cross/obj/glibc/elf:/home/teythoon/repos/hurd/cross/obj/glibc/dlfcn:/home/teythoon/repos/hurd/cross/obj/glibc/nss:/home/teythoon/repos/hurd/cross/obj/glibc/nis:/home/teythoon/repos/hurd/cross/obj/glibc/rt:/home/teythoon/repos/hurd/cross/obj/glibc/resolv:/home/teythoon/repos/hurd/cross/obj/glibc/crypt:/home/teythoon/repos/hurd/cross/obj/glibc/mach:/home/teythoon/repos/hurd/cross/obj/glibc/hurd -o /home/teythoon/repos/hurd/cross/obj/glibc/libc.so -T /home/teythoon/repos/hurd/cross/obj/glibc/shlib.lds /home/teythoon/repos/hurd/cross/obj/glibc/csu/abi-note.o /home/teythoon/repos/hurd/cross/obj/glibc/elf/soinit.os /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/sofini.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/interp.os /home/teythoon/repos/hurd/cross/obj/glibc/elf/ld.so /home/teythoon/repos/hurd/cross/obj/glibc/mach/libmachuser-link.so /home/teythoon/repos/hurd/cross/obj/glibc/hurd/libhurduser-link.so -lgcc - /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: In function `__fork': - /home/teythoon/repos/hurd/cross/src/glibc/posix/../sysdeps/mach/hurd/fork.c:70: undefined reference to `__start__hurd_atfork_prepare_hook' - /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: /home/teythoon/repos/hurd/cross/obj/glibc/libc_pic.os: relocation R_386_GOTOFF against undefined hidden symbol `__start__hurd_atfork_prepare_hook' can not be used when making a shared object - /home/teythoon/repos/hurd/cross/lib/gcc/i686-pc-gnu/4.8.1/../../../../i686-pc-gnu/bin/ld: final link failed: Bad value - collect2: error: ld returned 1 exit status - make[2]: *** [/home/teythoon/repos/hurd/cross/obj/glibc/libc.so] Error 1 - make[2]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc/elf' - make[1]: *** [elf/subdir_lib] Error 2 - make[1]: Leaving directory `/home/teythoon/repos/hurd/cross/src/glibc' - make: *** [all] Error 2 - + rm -f /home/teythoon/repos/hurd/cross/sys_root/lib/ld.so - + exit 100 - - binutils-2.23.2, - gcc-4.8.1, - everything else is from git as specified in the wiki. - - -### IRC, freenode, #hurd, 2013-10-24 - - <AliciaC> in recent glibc commits (tschwinge/Roger_Whittaker branch) there - are references to _hurd_atfork_* symbols in sysdeps/mach/hurd/fork.c, and - some _hurd_fork_* symbols, some of the _hurd_fork_* symbols seem to be - defined in Hurd's boot/frankemul.ld (mostly guessing by their names being - mentioned, I don't know linker script syntax), but those _hurd_atfork_* - symbols don't seem to be defined there, are they supposed to be defined - elsewhere or is th - <AliciaC> does anyone know where the _hurd_atfork_* group of symbols - referenced in glibc are defined (if anywhere)? - <youpi> AliciaC: it's the DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); - in glibc/sysdeps/mach/hurd/fork.c - <AliciaC> hm, is that not just a declaration? - <youpi> no, it's a definition, as its name suggests : - <AliciaC> (despite the macro name) - <youpi> :) - <AliciaC> ok - <AliciaC> I should look into it more, I could have sworn I was getting - undefined references, but maybe the symbol names used are different from - those defined, but that'd be odd as well, in the same file and all - <AliciaC> I mean, I do get undefined references, but question is if it's to - things that should have been defined or not - <youpi> what undefined references do you gaT? - <youpi> s/gaT/get - <AliciaC> I'll get back to you once I have that system up again - <AliciaC> youpi: sysdeps/mach/hurd/fork.c:70: undefined reference to - `__start__hurd_atfork_prepare_hook' - <AliciaC> fork.c:70: 'RUN_HOOK (_hurd_atfork_prepare_hook, ());' - <AliciaC> DEFINE_HOOK (_hurd_atfork_prepare_hook, (void)); is higher up in - the file - <AliciaC> though there is also this message: build/libc_pic.os: relocation - R_386_GOTOFF against undefined hidden symbol - `__start__hurd_atfork_prepare_hook' can not be used when making a shared - object - - -### [[!message-id "878uvfmwvs.fsf@kepler.schwinge.homeip.net"]] diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn index d4622d67..26511d3b 100644 --- a/open_issues/rpc_stub_generator.mdwn +++ b/open_issues/rpc_stub_generator.mdwn @@ -122,7 +122,7 @@ License|/fdl]]."]]"""]] <neal> the first are a burden <neal> the latter is a pain <neal> - http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal + https://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal <neal> in the same directory, you there are headers that use it <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05 <braunr> tschwinge: why do you recommend an IDL ? diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn index caecc437..19468d90 100644 --- a/open_issues/select.mdwn +++ b/open_issues/select.mdwn @@ -1103,7 +1103,7 @@ IRC, unknown channel, unknown date: <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) + (https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d) #### IRC, freenode, #hurd, 2012-08-01 @@ -1660,7 +1660,7 @@ IRC, unknown channel, unknown date: #### IRC, freenode, #hurd, 2012-12-17 <braunr> tschwinge: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd <braunr> gnu_srs: talking about that, can you explain : <braunr> "- The pure delay case is much faster now, making it necessary to <braunr> introduce a delay of 1 msec when the timeout parameter is set to diff --git a/open_issues/serial_console.mdwn b/open_issues/serial_console.mdwn index 827fd211..3100d60c 100644 --- a/open_issues/serial_console.mdwn +++ b/open_issues/serial_console.mdwn @@ -67,7 +67,7 @@ License|/fdl]]."]]"""]] <braunr> we definitely want it to work with 8N1 <gg0> never had problems with _virtual_ serial consoles <gg0> never = during last 2 years = since - http://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 + https://git.savannah.gnu.org/gitweb/?p=hurd/gnumach.git;a=commitdiff;h=2a603e88f86bee88e013c2451eacf076fbcaed81 <gg0> but i don't think i was on real hardware at that time diff --git a/open_issues/smp.mdwn b/open_issues/smp.mdwn index 6496f388..b0287a48 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -289,7 +289,7 @@ maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00048.html) - [Initial thread in bug-hurd maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-06/msg00048.html) - [SMP in GNU/Hurd FAQ](https://www.gnu.org/software/hurd/faq/smp.html) -- [GNU Mach git repository](http://git.savannah.gnu.org/cgit/hurd/gnumach.git) +- [GNU Mach git repository](https://git.savannah.gnu.org/cgit/hurd/gnumach.git) - [GNU Mach reference manual](https://www.gnu.org/software/hurd/gnumach-doc/) - [**MultiProcessor Specification**](https://pdos.csail.mit.edu/6.828/2011/readings/ia32/MPspec.pdf) - [**ACPI Specification**](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf) diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn deleted file mode 100644 index eae98077..00000000 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ /dev/null @@ -1,39 +0,0 @@ -[[!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/time.mdwn b/open_issues/time.mdwn index 99c2cbe9..425a7a82 100644 --- a/open_issues/time.mdwn +++ b/open_issues/time.mdwn @@ -180,7 +180,7 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. <braunr> keep in mind rpctrace doesn't behave like ptrace at all <braunr> it acts as a proxy <braunr> nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 + https://git.savannah.gnu.org/cgit/hurd/glibc.git/commit/?h=rbraun/getclktck_100_hz&id=90404d6d1aa01f6ce1557841f5a675bb6a30f508 <braunr> nalaginrut: you need to add it to the debian eglibc patch list, rebuild the packages, and install the resulting .debs <braunr> if you have trouble doing it, i'll make packages when i have time @@ -786,7 +786,7 @@ not get a define for `HZ`, which is then defined with a fallback value of 60. <braunr> 04:53 < nalaginrut> braunr: BTW, where is the patch/ <braunr> there is hardly anyone here at 5am <braunr> nalaginrut: - http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds + https://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/clock_t_centiseconds <nalaginrut> braunr: thanks for that, but why not use a constant for 100? <braunr> nalaginrut: i don't know where to define it <braunr> it's glibc, you don't define new stuff mindlessly diff --git a/open_issues/todo.mdwn b/open_issues/todo.mdwn index 00eb12d0..0ea5967a 100644 --- a/open_issues/todo.mdwn +++ b/open_issues/todo.mdwn @@ -14,5 +14,5 @@ is included in the section entitled [[!tag open_issue_hurd]] The canonical [TODO -file](http://git.savannah.gnu.org/cgit/hurd/hurd.git/plain/TODO) +file](https://git.savannah.gnu.org/cgit/hurd/hurd.git/plain/TODO) from the git archive. |