21 files changed, 393 insertions, 57 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..d3d6d046 100644
--- a/faq/64-bit.mdwn
+++ b/faq/64-bit.mdwn
@@ -13,11 +13,18 @@ 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.
+64-bit kernelland is supported with 32-bit userland, which notably
+permits to efficiently make use of more than 2 GiB memory and provide 4 GiB
+userland addressing space.
+
+A 64-bit GNU/Hurd is also available, progress is tracked on [[open_issues/64-bit_port]]!
+As of April 2025, the Debian hurd-amd64 port works just like the hurd-i386, except for
+some bugs, namely swapping issues with rumpdisk and dumping core files.
+
+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 38e844ad..1ab6b234 100644
--- a/faq/asking_questions.mdwn
+++ b/faq/asking_questions.mdwn
@@ -24,5 +24,5 @@ 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, 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..55d20429
--- /dev/null
+++ b/faq/context_switch.mdwn
@@ -0,0 +1,84 @@
+[[!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.
+
+You can build this file with:
+
+        gcc -pthread -rt -o context-switch context-switch.c
+
+In `context-switch.c` write:
+
+        #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/debugging_inside_glibc.mdwn b/faq/debugging_inside_glibc.mdwn
index 2a75a1a7..8577dce3 100644
--- a/faq/debugging_inside_glibc.mdwn
+++ b/faq/debugging_inside_glibc.mdwn
@@ -13,9 +13,7 @@ License|/fdl]]."]]"""]]
 
 In Debian, to get [[debugging]] information for glibc, you need to install the
 `libc0.3-dbg` package.  At the place [[debugging/GDB]] looks for debugging
-symbols by default (`/usr/lib/debug/lib/`), Debian's `libc0.3-dbg` stores only
-the frame unwind information used for backtracing.  If you want to step into
-glibc while debugging, you need to add `LD_LIBRARY_PATH=/usr/lib/debug` to
-debugged program's environment (`set env VAR value` from the GDB command line).
-If that still does not work, try `LD_PRELOAD=/usr/lib/debug/libc.so.0.3`
-instead.
+symbols by default (`/usr/lib/debug/.build-id`), Debian's `libc0.3-dbg` stores only
+the frame unwind information used for backtracing.
+
+You also need to download the source code with `apt source glibc` and `cd` into it for `gdb` to be able to find and show it, or use `set directories` inside gdb, or put it in your `.gdbinit`
diff --git a/faq/debugging_translators.mdwn b/faq/debugging_translators.mdwn
index 1bd0deec..031b5778 100644
--- a/faq/debugging_translators.mdwn
+++ b/faq/debugging_translators.mdwn
@@ -11,12 +11,4 @@ License|/fdl]]."]]"""]]
 
 [[!tag faq/development]]
 
-In order to [[debug|debugging]] translators and being able to step into glibc
-during it, on Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed.
-If you need to debug the initialization of the translator, start the translator
-like
-
-    $ settrans -Pa /foo /usr/bin/env LD_LIBRARY_PATH=/usr/lib/debug /hurd/foofs
-
-The `-P` option will make it
-pause and you will be able to attach [[debugging/GDB]] to the process.
+See [[/hurd/debugging/translator]].
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..16d60a9a 100644
--- a/faq/drivers.mdwn
+++ b/faq/drivers.mdwn
@@ -13,16 +13,58 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="what hardware is supported? What drivers does GNU/Hurd have?"]]
 
-Currently, for disks Mach integrates old drivers from Linux through some
-[[community/gsoc/project_ideas/driver_glue_code]], which provide
+As of September 2024, the Hurd runs well on old Thinkpads.  We
+recommend the Thinkpad T60, which supports a maximum of 4GB of RAM,
+and you can use an [[SSD|hurd/rump/rumpdisk]].  If you have difficulty
+installing the Hurd, then try setting your harddrive mode to "legacy"
+in the BIOS.  A cheaper option is the T43 (2GB max RAM).
+
+Other working Thinkpads include the X200, T400, 
+[[T410|https://logs.guix.gnu.org/hurd/2025-04-25.log#103752]] or T500 Thinkpads,
+which support internet connectivity via the ethernet port.  You can
+use an [[SSD|hurd/rump/rumpdisk]] on these laptops, which support a
+maximum of 8GB of RAM.  The Debian installer images from 2023 fail to
+boot these machines, but you can install the Hurd via [[Debian's
+CrossInstall|hurd/running/debian/CrossInstall]] or 
+[[mmdebstrap|https://lists.debian.org/debian-hurd/2024/12/msg00003.html]].  
+
+_While the [[64 bit port|faq/64-bit]] is about as stable as the 32-bit 
+port, the rumpdisk support needed for it is still relatively experimental.
+For this reason we recommend casual Hurd users to use the 32 bit port._
+
+Other hardware that is known to work includes the [[Dell Inspiron
+1750|https://logs.guix.gnu.org/hurd/2024-09-28.log]] on i386
+Debian/Hurd.  It won't boot with the current installer (June 2023
+debian-hurd i386 net-install) because of an FPU issue (fixed
+upstream). I had to remove the optical drive. It hangs for one minute
+during boot on ACPI init, but otherwise fine when disabling full tree
+parsing.  The touchpad, keyboard, display, ethernet, and the hard
+drive works (in legacy mode).
+
+The Hurd can run on more recent Intel machines, but with [[no internet
+connectivity|hurd/running/debian/DebianAptOffline]]!  You can always
+use the Hurd via [[qemu|hurd/running/qemu]].
+
+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
-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
-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.
+support|faq/sata_disk_drives]].  [[Rumpdisk|hurd/rump/rumpdisk]] lets
+us use modern hard drives, like SSDs.
+
+For network boards, we curently use the [[DDE]] toolkit to run linux
+2.6.32 drivers in userland processes, which we may eventually replace
+with [[rump drivers|hurd/rump]].  Note however that we have of course
+not tested all drivers. We obviously don't even have all kinds of
+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.  To run X then, you must use the proprietary
+BIOS, since coreboot/libreboot do not include a working vesa driver.
+
+Hurd developers are working on adding USB support with
+[[rumpusbdisk|hurd/rump/rumpusbdisk]].
 
 [[microkernel/mach/gnumach/ports/Xen]] is also supported, both blkfront and
 netfront.
diff --git a/faq/foo_max.mdwn b/faq/foo_max.mdwn
new file mode 100644
index 00000000..ccd09904
--- /dev/null
+++ b/faq/foo_max.mdwn
@@ -0,0 +1,76 @@
+[[!meta copyright="Copyright © 2025 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no 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/general]]
+
+[[!meta title="Why not just defining `PATH_MAX`, `MAXPATHLEN`, ... `FOO_MAX` and be done?"]]
+
+More technical details are described in [`PATH_MAX` Is Tricky](https://eklitzke.org/path-max-is-tricky)
+
+For porting guidelines, see [[hurd/porting/guidelines#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL]]
+
+# Is it really standard not to define them?
+
+These macros are indeed optional in Posix, so not defining them remains
+standard-compliant. Quoting the standard:
+
+    A definition of one of the symbolic constants in the following list shall be
+    omitted from <limits.h> on specific implementations where the corresponding
+    value is equal to or greater than the stated minimum, but is unspecified.
+
+Their definition was actually not completely clear, Posix 1990 was ambiguous
+about it including `\0` or not, it was made clear later on that it does include
+it, but some software still add `+1`. Sometimes `PATH_MAX` is even understood as
+the filename sections of paths, which is actually `NAME_MAX`, which *is* indeed
+limited by filesystems constraints, but then it is filesystem-dependent, and
+even depend on its revision, so to be rather queried at runtime with `pathconf`.
+
+# But it's really convenient! Isn't allocating dynamically much more complex?
+
+`FOO_MAX` constants are most often used as “reasonable size to allocate a
+path”. On Linux `PATH_MAX` is typically 4096, which is not that reasonable (a whole
+memory page, thus a TLB lookup) when manipulating a lot of paths. Allocating
+dynamically would use much less memory.
+
+Most often interfaces can be made to properly allocate dynamically. Notably,
+since Posix 2008 `realpath(path, NULL)` allocates the path dynamically.
+Posix 2008 does not say that `getcwd(NULL, 0)` allocates the path dynamically,
+but BSD, Linux, and even windows do.
+
+In general, using `FOO_MAX` in source code (with a large value) leads to code
+that is not actually checking against overflows. `PATH_MAX` being 4096 is
+actually "wrong" on Linux:
+
+    $ printf '#include <limits.h>\nPATH_MAX' | cpp -P
+    $ d=0123456789; for i in `seq 1 1000`; do mkdir $d; cd $d 2>/dev/null; done
+    $ pwd | wc -c
+
+Using such paths lead to various broken software, we could for instance notice:
+
+* nautilus crashes because of unhandled signal 8, arithmetic exception
+* tar can create an archive containing such paths, but cannot untar it
+* filelight just ignores the path
+* gdb refuses to work
+
+Using a large `PATH_MAX` value just *hides* these bugs under the
+carpet. Attackers will happily try to exploit them.
+
+# Can't it just be defined to `PTRDIFF_MAX`?
+
+A lot of programs which blindly use `FOO_MAX` as allocation size would then just
+at best either not compile or at worse compile but fail or segfault at execution.
+
+# These also imply ABI problems
+
+Exposing a hardcoded limitation like `FOO_MAX` also means hard-defining them
+into binaries, making them part of the ABI, and then a hell to change. See for
+instance Windows which has been stuck with `MAX_PATH` being 260. Some libraries
+(e.g. libusb1) even expose them in their own ABI, thus making the increase a
+very nasty flag-day.
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/reporting_bugs.mdwn b/faq/reporting_bugs.mdwn
index 25be02ef..0e556cc1 100644
--- a/faq/reporting_bugs.mdwn
+++ b/faq/reporting_bugs.mdwn
@@ -14,9 +14,12 @@ License|/fdl]]."]]"""]]
 Please try to reproduce bugs which are not obviously Hurd-specific on Debian
 GNU/Linux and then file them there.
 
-If you find a genuine issue in Debian GNU/Hurd, please file it in our Alioth
-bug tracker at
-<http://alioth.debian.org/tracker/?atid=411594&group_id=30628&func=browse>
+If you find a genuine issue in Debian GNU/Hurd, please read this
+[[debian page|https://www.debian.org/Bugs/Reporting]] to learn how to
+submit report a bug.  If you are running Debian, then its much easier
+to use the
+[[reportbug|https://packages.debian.org/stable/utils/reportbug]] package.
+
 If you find a bug in the Hurd or GNU Mach themselves, either file a bug against
 the respective Debian packages, or directly at
 <http://savannah.gnu.org/bugs/?group=hurd>
diff --git a/faq/sata_disk_drives.mdwn b/faq/sata_disk_drives.mdwn
index 4864e35b..81e2a01a 100644
--- a/faq/sata_disk_drives.mdwn
+++ b/faq/sata_disk_drives.mdwn
@@ -15,3 +15,7 @@ License|/fdl]]."]]"""]]
 Until recently, GNU Mach did not support SATA disk drives (`/dev/sda` etc. in GNU/Linux) natively, the only way to get those drives to work used to be to put them into compatibility mode in the BIOS, if such an option exists.  GNU Mach will then recognize them as hd etc.
 
 An AHCI driver has been added on 10th May 2013, which should bring support for a wide range of SATA controlers. Please however make sure to configure the BIOS in AHCI mode (as opposed to RAID mode).
+
+Damien Zammit ported a rump kernel to the Hurd to use SSD devices.  We
+call it [[rumpdisk|hurd/rump/rumpdisk]].  With rumpdisk you can have a
+[[2TB partition!|faq/2_gib_partition_limit]]
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/still_useful.mdwn b/faq/still_useful.mdwn
index d08d2df7..575781a1 100644
--- a/faq/still_useful.mdwn
+++ b/faq/still_useful.mdwn
@@ -39,7 +39,7 @@ various servers are designed for this sort of modification.
 > personal filesystem
 > 
 >     $ dd < /dev/zero > myspace.img bs=1M count=1024
->     $ mke2fs myspace.img
+>     $ /sbin/mke2fs -E root_owner=$UID:0 myspace.img
 >     $ settrans myspace /hurd/ext2fs myspace.img
 >     $ cd myspace
 
diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn
index ca96697c..9c47ca6c 100644
--- a/faq/system_port.mdwn
+++ b/faq/system_port.mdwn
@@ -21,7 +21,9 @@ system functionality is usually accessed through the
 [[/libpthread]].
 
 A whole-system port involves touching all these components, with varying
-degree, of course.
+degree, of course.  In 2024, Sergey Bugaev completed an experimental
+system port to AArch64, so be sure to consult him, if you are
+considering a system port.
 
 For a CPU architecture port, the microkernel is the most involved part,
 followed by glibc and the threading library.
@@ -30,10 +32,18 @@ The original [[microkernel/Mach]] microkernel was portable to a number of
 architectures which were a lot more popular at the beginning of the 1990s than
 they are now.
 
-The GNU/Hurd system is currently available for the x86 architecture.  This
-includes emulators such as [[hurd/running/QEMU]] (or KVM), or
-[[hurd/running/VirtualBox]].  Besides this, there is a port for the [[Xen
-domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*.
+The Debian GNU/Hurd system is currently available for the x86 and
+X86_64 architectures and it is probably the most up-to-date with about
+70% of Debian's packages available. There also exists an experimental
+GNU/Hurd AArch64 port. Contact Sergey if you are interested in running
+the Hurd on AArch64. You can also run the Hurd with emulators such as
+[[hurd/running/QEMU]] (or KVM), or [[hurd/running/VirtualBox]].
+Besides this, there is a port for the [[Xen
+domU|microkernel/mach/gnumach/ports/xen]] *sub-architecture*.  With
+Xen, you can run the Hurd and GNU/Linux in parallel.  If you are
+already running Guix System, then
+[[childhurds|https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services]]
+are probably the easiest way to try out the Hurd.
 
 Further on, there are some [[unfinished porting
 attempts|microkernel/mach/gnumach/ports]] for the Alpha, MIPS and PowerPC
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`