git: 5e5b9e25d7 - main - [handbook] Show how to configure sleep on lid closure

The branch main has been updated by fernape:

URL: https://cgit.FreeBSD.org/doc/commit/?id=5e5b9e25d72bb4001933071b41aeaedf932384e9

commit 5e5b9e25d72bb4001933071b41aeaedf932384e9
Author:     Fernando Apesteguía <[email protected]>
AuthorDate: 2021-04-22 07:20:14 +0000
Commit:     Fernando Apesteguía <[email protected]>
CommitDate: 2021-04-22 07:23:42 +0000

    [handbook] Show how to configure sleep on lid closure
    
    Add information about how to make FreeBSD sleep and resume when the lid state
    switches.
    
    Approved By: 0mp (mentor)
    Differential Revision: https://reviews.freebsd.org/D29897
---
 .../content/en/books/handbook/config/_index.adoc          | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/documentation/content/en/books/handbook/config/_index.adoc b/documentation/content/en/books/handbook/config/_index.adoc
index 23640b3584..4b39749713 100644
--- a/documentation/content/en/books/handbook/config/_index.adoc
+++ b/documentation/content/en/books/handbook/config/_index.adoc
@@ -1406,6 +1406,21 @@ A common problem with suspend/resume is that many device drivers do not save, re
 
 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.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/dev-commits-doc-all
To unsubscribe, send any mail to "[email protected]"