3 files changed, 34 insertions, 25 deletions
diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn
index 57ed7ea9..50bd4542 100644
--- a/faq/drivers.mdwn
+++ b/faq/drivers.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2013, 2015 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -10,18 +11,18 @@ License|/fdl]]."]]"""]]
 
 [[!tag faq/support faq/_important]]
 
-[[!meta title="What drivers does GNU/Hurd have?"]]
+[[!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
+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.
 
-Currently, for disks Mach integrates drivers from Linux 2.0 through some
-[[community/gsoc/project_ideas/driver_glue_code]].  As it's very old, that
-limits hardware support a lot, of course.  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.  Firmware loading is however not implemented yet.
 [[microkernel/mach/gnumach/ports/Xen]] is also supported, both blkfront and
 netfront.
-
-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 or e1000
-drivers for instance.
diff --git a/faq/off.mdwn b/faq/fsck.mdwn
index 4777d066..b50d6953 100644
--- a/faq/off.mdwn
+++ b/faq/fsck.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2013 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -8,11 +9,16 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-[[!tag faq/running]]
+[[!tag faq/open_issues]]
 
-[[!meta title="how am I supposed to shut my Hurd system down?"]]
+[[!meta title="fsck shows a lot of errors"]]
 
-[[!tag open_issue_gnumach]]
-GNU Mach does not have APM or ACPI support, so it will just stop with
-`In tight loop: hit ctl-alt-del to reboot`, and you can switch off the
-system.
+Quite a few of them are actually benign:
+
+    /dev/hd0s1: Deleted inode 95849 has zero dtime.  FIXED.
+
+see [[open_issues/ext2fs_dtime]]
+
+    /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0.
+
+see [[open_issues/e2fsck_i_file_acl_hi]]
diff --git a/faq/libpthread_dlopen.mdwn b/faq/libpthread_dlopen.mdwn
index 94d091a4..3b365fad 100644
--- a/faq/libpthread_dlopen.mdwn
+++ b/faq/libpthread_dlopen.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2013, 2014, 2015 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -14,12 +15,13 @@ License|/fdl]]."]]"""]]
 
 Some applications don't themselves link against libpthread, but then load
 plugins which do link against libpthread.  This means internally switching from
-single-threading to multi-threading, which is [[not yet
-supported|open_issues/libpthread_dlopen]] by our [[/libpthread]], and results
-in errors such as:
+single-threading to multi-threading, which is only supported since libc0.3
+2.19-16~2. Previously, it would result in errors such as:
 
     ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70: __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
 
-This can be worked around by making the application link against libpthread (i.e. not only the plugin, but also the main binary), or without recompiling by explicitly pre-loading libpthread, for example:
+This could be worked around by making the application link against libpthread (i.e. not only the plugin, but also the main binary), or without recompiling by explicitly pre-loading libpthread, for example:
 
     $ LD_PRELOAD=/lib/i386-gnu/libpthread.so.0.3 [application]
+
+But it should now be gone, simply upgrade libc0.3.