diff --git a/documentation/content/en/books/handbook/config/_index.adoc b/documentation/content/en/books/handbook/config/_index.adoc
--- a/documentation/content/en/books/handbook/config/_index.adoc
+++ b/documentation/content/en/books/handbook/config/_index.adoc
@@ -1406,6 +1406,21 @@
 
 This test emulates the suspend/resume cycle of all device drivers without actually going into `S3` state. In some cases, problems such as losing firmware state, device watchdog time out, and retrying forever, can be captured with this method. Note that the system will not really enter `S3` state, which means devices may not lose power, and many will work fine even if suspend/resume methods are totally missing, unlike real `S3` state.
 
+If the previous test worked, on a laptop it is possible to configure the system
+to suspend into `S3` on lid close and resume when it is open back again:
+
+[source,shell]
+....
+# sysctl hw.acpi.lid_switch_state=S3
+....
+
+This change can be made persistent across reboots:
+
+[source,shell]
+....
+# echo ‘hw.acpi.lid_switch_state=S3’ >> /etc/sysctl.conf
+....
+
 Harder cases require additional hardware, such as a serial port and cable for debugging through a serial console, a Firewire port and cable for using man:dcons[4], and kernel debugging skills.
 
 To help isolate the problem, unload as many drivers as possible. If it works, narrow down which driver is the problem by loading drivers until it fails again. Typically, binary drivers like [.filename]#nvidia.ko#, display drivers, and USB will have the most problems while Ethernet interfaces usually work fine. If drivers can be properly loaded and unloaded, automate this by putting the appropriate commands in [.filename]#/etc/rc.suspend# and [.filename]#/etc/rc.resume#. Try setting `hw.acpi.reset_video` to `1` if the display is messed up after resume. Try setting longer or shorter values for `hw.acpi.sleep_delay` to see if that helps.