diff options
Diffstat (limited to 'faq')
| -rw-r--r-- | faq/2_gib_partition_limit.mdwn | 6 | ||||
| -rw-r--r-- | faq/64-bit.mdwn | 20 | ||||
| -rw-r--r-- | faq/asking_questions.mdwn | 12 | ||||
| -rw-r--r-- | faq/context_switch.mdwn | 78 | ||||
| -rw-r--r-- | faq/dev-rebuild.mdwn | 20 | ||||
| -rw-r--r-- | faq/drivers.mdwn | 7 | ||||
| -rw-r--r-- | faq/fsck.mdwn | 12 | ||||
| -rw-r--r-- | faq/how_many_developers.mdwn | 6 | ||||
| -rw-r--r-- | faq/how_to_switch_microkernels.mdwn | 14 | ||||
| -rw-r--r-- | faq/other_repositories.mdwn | 2 | ||||
| -rw-r--r-- | faq/random_seed_file.mdwn | 19 | ||||
| -rw-r--r-- | faq/smp.mdwn | 31 | ||||
| -rw-r--r-- | faq/x-exit.mdwn | 27 | ||||
| -rw-r--r-- | faq/xserver-hurd-console.mdwn | 19 |
14 files changed, 243 insertions, 30 deletions
diff --git a/faq/2_gib_partition_limit.mdwn b/faq/2_gib_partition_limit.mdwn index 210d8afb..fa5105bd 100644 --- a/faq/2_gib_partition_limit.mdwn +++ b/faq/2_gib_partition_limit.mdwn @@ -13,8 +13,10 @@ License|/fdl]]."]]"""]] [[!meta title="Is there still a 2 GiB ext2fs disk partition limit?"]] -The 2 GiB limit has been removed. +The 2 GiB ext2fs limit has been removed. IDE disk drivers however currently do not support more than 2^28 sectors, i.e. 128GiB. -The AHCI disk driver supports up to 2^32 sectors, i.e. 2TiB. +The gnumach AHCI disk driver supports up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB. + +You can have a bigger disk, you just should not put disk partitions beyond these limits for the drivers to be able to read from them. diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn index 1da375ba..972aafbe 100644 --- a/faq/64-bit.mdwn +++ b/faq/64-bit.mdwn @@ -13,11 +13,21 @@ License|/fdl]]."]]"""]] [[!meta title="Is there a 64-bit version?"]] -There are currently no plan for 64-bit userland, but there are plans for 64-bit -kernelland with 32-bit userland, which will notably permit to efficiently make -use of more than 2 GiB memory and provide 4 GiB userland addressing space. -[[Work on this|open_issues/64-bit_port]] is currently in the master-x86_64 and -port-amd64 branches for GNU Mach. +There are plans for 64-bit kernelland with 32-bit userland, which will notably +permit to efficiently make use of more than 2 GiB memory and provide 4 GiB +userland addressing space. + +A 64-bit GNU/Hurd is also coming soon, +progress is tracked on [[open_issues/64-bit_port]]! +Hurd developers ported GNUMach to +64-bit some time ago. Then they started making significant progress +on the x86_64 userland port in Feb 2023. As of May 2023, the 64-bit +port works well enough to start all the essential Hurd servers, run +/bin/sh, establish TCP/IP connections, and compile C. We are currently building +64-bit packages. We plan on supporting both a 32-bit and 64-bit Debian +GNU/Hurd, only not both at the same time. However, there is no plan to fix the +year 2038 concern on a 32-bit system. That being said, you can always run a 32-bit version on a 64-bit machine, it just works, processes are just limited to a couple GiB available memory. + diff --git a/faq/asking_questions.mdwn b/faq/asking_questions.mdwn index 912c78dc..1ab6b234 100644 --- a/faq/asking_questions.mdwn +++ b/faq/asking_questions.mdwn @@ -15,14 +15,14 @@ License|/fdl]]."]]"""]] Before asking a question, first make an effort to find the answer to your question. A lot of questions have been asked and answered before, so please -spend some time trying to solve the problem on your own (e.g., [search the -web](http://google.com/), search these web pages, etc.), and show us that you +spend some time trying to solve the problem on your own (e.g. [search the +web](http://duckduckgo.com/), search these web pages, etc.), and show us that you did so when you ask your question. -When asking, (1) be details, and (2) demonstrate that you have made an effort, -e.g., "I am having trouble frobbing the foo. I searched the web and only found +When asking, (1) be detailed, and (2) demonstrate that you made an effort, +e.g. "I am having trouble frobbing the foo. I searched the web and only found information regarding how to frob a bar, but that seems unrelated." Provide as -many relevant details as possible reproducing them as exactly as possible. +many relevant details as possible, as well as how to reproduce the issue. -This [document](http://www.catb.org/~esr/faqs/smart-questions.html) may help you +[This document](http://www.catb.org/~esr/faqs/smart-questions.html#intro) may help you understand some developers attitudes and social norms. diff --git a/faq/context_switch.mdwn b/faq/context_switch.mdwn new file mode 100644 index 00000000..2d090c4c --- /dev/null +++ b/faq/context_switch.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 2013, 2016, 2017, 2018 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no 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 faq/support]] + +[[!meta title="I heard that context-switch on Mach is really slow?"]] + +It is not, there is no real reason why it would be particularly slow, it is just +about switching virtual addresses and registers, which all OS have to perform +anyway. + +A quick-and-dirty benchmark: + + #include <fcntl.h> + #include <semaphore.h> + #include <stdio.h> + #include <time.h> + #include <unistd.h> + #include <sys/mman.h> + + sem_t *sem1, *sem2; + + void worker1(void) { + time_t last; + int n = 0; + last = time(NULL); + while(1) { + time_t new = time(NULL); + if (new != last) { + printf("%d\n", n); + n = 0; + last = new; + } + n++; + sem_wait(sem1); + sem_post(sem2); + } + } + + void worker2(void) { + while(1) { + sem_post(sem1); + sem_wait(sem2); + } + } + + int fd; + void get_sems(void) { + void *ptr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0); + sem1 = ptr; + sem2 = sem1+1; + } + + int main(void) { + fd = open("/tmp/foo", O_CREAT|O_TRUNC|O_RDWR, 0666); + ftruncate(fd, 4096); + + get_sems(); + sem_init(sem1, 1, 0); + sem_init(sem2, 1, 0); + + if (fork()) + worker1(); + else { + get_sems(); + worker2(); + } + } + +run on my current Linux system (a Core i5-10210U), gets about 300k switches per second on Linux. Running it on Hurd-in-kvm (which would supposedly be slower) gets about 400k switches per second. diff --git a/faq/dev-rebuild.mdwn b/faq/dev-rebuild.mdwn new file mode 100644 index 00000000..5a4678d1 --- /dev/null +++ b/faq/dev-rebuild.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2021 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no 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 faq/running]] + +[[!meta title="Some ntries in /dev are bogus"]] + +Possibly something broke translators there. You can run + + dpkg-reconfigure hurd + +to rebuild entries there. diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn index 50bd4542..50ba171d 100644 --- a/faq/drivers.mdwn +++ b/faq/drivers.mdwn @@ -16,7 +16,9 @@ License|/fdl]]."]]"""]] Currently, for disks Mach integrates old drivers from Linux through some [[community/gsoc/project_ideas/driver_glue_code]], which provide IDE disk support, and we have an AHCI driver which provides [[SATA -support|faq/sata_disk_drives]]. For network boards, we use the [[DDE]] toolkit +support|faq/sata_disk_drives]]. + +For network boards, we use the [[DDE]] toolkit to run linux 2.6.32 drivers in userland processes, which provides both long-term support for new hardware and safety against driver bugs. Note however that we have of course not tested all drivers, we obviously don't even have all kinds of @@ -24,5 +26,8 @@ hardware. So we can not promise that they will all work. What probably works for sure is what we usually use: the rtl8139 and e1000 drivers for instance. Firmware loading is not implemented yet. +For graphical mode, Xorg is supported, e.g. with the vesa driver. DRM is not +supported yet. + [[microkernel/mach/gnumach/ports/Xen]] is also supported, both blkfront and netfront. diff --git a/faq/fsck.mdwn b/faq/fsck.mdwn index e7496646..5658a799 100644 --- a/faq/fsck.mdwn +++ b/faq/fsck.mdwn @@ -15,6 +15,18 @@ License|/fdl]]."]]"""]] Quite a few of them are actually benign: /dev/hd0s1: Deleted inode 95849 has zero dtime. FIXED. + [...] + Block bitmap differences: -(988160--988163) -(989627--989634) [...] + [...] + Free blocks count wrong for group #30 (16477, counted=16741). + [...] + Free blocks count wrong (2170675, counted=2170956). + [...] + Inode bitmap differences: -244986 -245011 -(245107--245108) [...] + [...] + Free inodes count wrong for group #30 (4632, counted=4649). + [...] + Free inodes count wrong (880891, counted=880909). see [[open_issues/ext2fs_dtime]] diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn index 63756db7..10bd6b7f 100644 --- a/faq/how_many_developers.mdwn +++ b/faq/how_many_developers.mdwn @@ -17,9 +17,9 @@ few?"]] # How Many Developers? -Literally only one handful works on the core of the system in their free time, and another -handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and -[[hurd/running/Arch_Hurd]] packaging. Also, an additional handful of former +Literally only half a handful works on the core of the system in their free time, and another +half of handful helps with [[Debian GNU/Hurd|hurd/running/debian]] and +[[hurd/running/Arch_Hurd]] packaging. Also, an additional half of handful of former developers are still available for answering technical questions, but are not participating in the current development anymore. diff --git a/faq/how_to_switch_microkernels.mdwn b/faq/how_to_switch_microkernels.mdwn index a0e57174..21b276ae 100644 --- a/faq/how_to_switch_microkernels.mdwn +++ b/faq/how_to_switch_microkernels.mdwn @@ -13,6 +13,14 @@ License|/fdl]]."]]"""]] [[!meta title="How difficult would it be to switch to another microkernel?"]] -One would have to reimplement the `mach/` and `sysdeps/mach/` parts of -[[glibc]] and [[libpthread]]. Quite a few other Hurd tools also assume a -[[microkernel/Mach]] kernel and would have to be adapted or rewritten. +The microkernel has to provide memory management and user-level-managed page +faulting, thread scheduling, and IPC. + +One would have to reimplement the `mach/` and `sysdeps/mach/` parts of [[glibc]] +and [[libpthread]]. One would have to rewrite mig to generate the new IPCs. One +would have to rewrite libpager to handle paging. + +All `mach_` calls in glibc and hurd would need to be updated. + +Quite a few other Hurd tools also assume a [[microkernel/Mach]] kernel and +would have to be adapted or rewritten. diff --git a/faq/other_repositories.mdwn b/faq/other_repositories.mdwn index f8ece75f..a55ac1e3 100644 --- a/faq/other_repositories.mdwn +++ b/faq/other_repositories.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag faq/debian]] -If you want to use the `apt-get source` facility, make sure that +If you want to use the `apt source` facility, make sure that `/etc/apt/sources.list` contains a line like deb-src http://ftp.de.debian.org/debian unstable main diff --git a/faq/random_seed_file.mdwn b/faq/random_seed_file.mdwn new file mode 100644 index 00000000..7afe007e --- /dev/null +++ b/faq/random_seed_file.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2021 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no 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 faq/support]] + +[[!meta title="During installation I get Failed to read random seed file"]] + +More precisely, during the Debian installation, around the extraction of the netdde package one gets: + + /hurd/random: Warning: Failed to read random seed file /var/lib/random-seed: (system kern) error with unknown subsystem + +This is a harmless glitch. diff --git a/faq/smp.mdwn b/faq/smp.mdwn index c0133b80..ee0bf53f 100644 --- a/faq/smp.mdwn +++ b/faq/smp.mdwn @@ -13,21 +13,34 @@ License|/fdl]]."]]"""]] [[!meta title="Does GNU/Hurd support SMP/Multicore?"]] -The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following. +The Hurd servers themselves are multithreaded, so they should be able to +benefit of the parallelism brought by SMP/Multicore boxes. +This needs testing as SMP support has recently been added to Mach. [[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia Intel_iPSC/860]], so principally has the required infrastructure. It has -however not yet been enhanced to support nowadays' SMP standards like ACPI, -etc. Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue -code likely isn't SMP-safe. As this glue code layer is not used in the -[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it -in this enviroment first. +recently been enhanced to support nowadays' SMP standards like ACPI. -[[!tag open_issue_gnumach open_issue_xen]] +However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue +code isn't SMP-safe so build with --disable-linux-groups to test SMP and use +rumpdisk to provide disk access. -That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type). +To build an SMP supported gnumach with kdb: +../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups -Once this issue is solved, there are follow-up issues about +This will by default allow you to boot with one core isolated to the default +processor set, and all the other detected cpus will be in the slave processor set. +The slave processors need to be enabled per-task using RPCs to manipulate processor sets. + +See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program +that can enable a task to use the slave processors by calling ./smp /bin/bash for example. + +Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting +to boot a full SMP system, (if you revert the slave processor pinning commit). +This is what needs to be debugged one-by-one by running each translator using ./smp until +we can squash these race condition bugs. + +There are follow-up issues about [[open_issues/multiprocessing]] and [[open_issues/multithreading]]. [[Project idea|open_issues/smp]]. diff --git a/faq/x-exit.mdwn b/faq/x-exit.mdwn new file mode 100644 index 00000000..5806cd11 --- /dev/null +++ b/faq/x-exit.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2021 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no 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 faq/running]] + +[[!meta title="On X session logout, the X server does not exit"]] + +This is due to a missing implementation of a corner case of Posix signaling for non-root processes to root processes. + +One can however use the usual ctrl-alt-backspace shortcut to kill the X server. + +You just need to configure it via the file: +`/etc/X11/xorg.conf.d/xorg-ctrl-backspace.conf` + + Section "InputDevice" + Identifier "Generic KeyBoard" + Driver "kbd" + Option "XkbOptions" "terminate:ctrl_alt_bksp" + EndSection diff --git a/faq/xserver-hurd-console.mdwn b/faq/xserver-hurd-console.mdwn new file mode 100644 index 00000000..ebe2bf31 --- /dev/null +++ b/faq/xserver-hurd-console.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2022 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no 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 faq/running]] + +[[!meta title="Cannot open keyboard (No such file or directory)"]] + +You are apparently not running the Hurd console, only the Mach console, which +Xorg does not know how to read. + +Make sure to enable the Hurd console in `/etc/default/hurd-console` |