Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   1) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   2) Debugging hibernation and suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   3) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   5) 	(C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   6) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   7) 1. Testing hibernation (aka suspend to disk or STD)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   8) ===================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300   9) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  10) To check if hibernation works, you can try to hibernate in the "reboot" mode::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  11) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  12) 	# echo reboot > /sys/power/disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  13) 	# echo disk > /sys/power/state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  14) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  15) and the system should create a hibernation image, reboot, resume and get back to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  16) the command prompt where you have started the transition.  If that happens,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  17) hibernation is most likely to work correctly.  Still, you need to repeat the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  18) test at least a couple of times in a row for confidence.  [This is necessary,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  19) because some problems only show up on a second attempt at suspending and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  20) resuming the system.]  Moreover, hibernating in the "reboot" and "shutdown"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  21) modes causes the PM core to skip some platform-related callbacks which on ACPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  22) systems might be necessary to make hibernation work.  Thus, if your machine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  23) fails to hibernate or resume in the "reboot" mode, you should try the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  24) "platform" mode::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  25) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  26) 	# echo platform > /sys/power/disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  27) 	# echo disk > /sys/power/state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  28) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  29) which is the default and recommended mode of hibernation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  30) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  31) Unfortunately, the "platform" mode of hibernation does not work on some systems
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  32) with broken BIOSes.  In such cases the "shutdown" mode of hibernation might
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  33) work::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  34) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  35) 	# echo shutdown > /sys/power/disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  36) 	# echo disk > /sys/power/state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  37) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  38) (it is similar to the "reboot" mode, but it requires you to press the power
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  39) button to make the system resume).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  40) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  41) If neither "platform" nor "shutdown" hibernation mode works, you will need to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  42) identify what goes wrong.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  43) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  44) a) Test modes of hibernation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  45) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  46) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  47) To find out why hibernation fails on your system, you can use a special testing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  48) facility available if the kernel is compiled with CONFIG_PM_DEBUG set.  Then,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  49) there is the file /sys/power/pm_test that can be used to make the hibernation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  50) core run in a test mode.  There are 5 test modes available:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  51) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  52) freezer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  53) 	- test the freezing of processes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  54) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  55) devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  56) 	- test the freezing of processes and suspending of devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  57) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  58) platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  59) 	- test the freezing of processes, suspending of devices and platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  60) 	  global control methods [1]_
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  61) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  62) processors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  63) 	- test the freezing of processes, suspending of devices, platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  64) 	  global control methods [1]_ and the disabling of nonboot CPUs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  65) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  66) core
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  67) 	- test the freezing of processes, suspending of devices, platform global
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  68) 	  control methods\ [1]_, the disabling of nonboot CPUs and suspending
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  69) 	  of platform/system devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  70) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  71) .. [1]
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  72) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  73)     the platform global control methods are only available on ACPI systems
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  74)     and are only tested if the hibernation mode is set to "platform"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  75) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  76) To use one of them it is necessary to write the corresponding string to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  77) /sys/power/pm_test (eg. "devices" to test the freezing of processes and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  78) suspending devices) and issue the standard hibernation commands.  For example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  79) to use the "devices" test mode along with the "platform" mode of hibernation,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  80) you should do the following::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  81) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  82) 	# echo devices > /sys/power/pm_test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  83) 	# echo platform > /sys/power/disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  84) 	# echo disk > /sys/power/state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  85) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  86) Then, the kernel will try to freeze processes, suspend devices, wait a few
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  87) seconds (5 by default, but configurable by the suspend.pm_test_delay module
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  88) parameter), resume devices and thaw processes.  If "platform" is written to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  89) /sys/power/pm_test , then after suspending devices the kernel will additionally
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  90) invoke the global control methods (eg. ACPI global control methods) used to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  91) prepare the platform firmware for hibernation.  Next, it will wait a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  92) configurable number of seconds and invoke the platform (eg. ACPI) global
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  93) methods used to cancel hibernation etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  94) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  95) Writing "none" to /sys/power/pm_test causes the kernel to switch to the normal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  96) hibernation/suspend operations.  Also, when open for reading, /sys/power/pm_test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  97) contains a space-separated list of all available tests (including "none" that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  98) represents the normal functionality) in which the current test level is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  99) indicated by square brackets.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) Generally, as you can see, each test level is more "invasive" than the previous
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) one and the "core" level tests the hardware and drivers as deeply as possible
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) without creating a hibernation image.  Obviously, if the "devices" test fails,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) the "platform" test will fail as well and so on.  Thus, as a rule of thumb, you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) should try the test modes starting from "freezer", through "devices", "platform"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) and "processors" up to "core" (repeat the test on each level a couple of times
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) to make sure that any random factors are avoided).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) If the "freezer" test fails, there is a task that cannot be frozen (in that case
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) it usually is possible to identify the offending task by analysing the output of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) dmesg obtained after the failing test).  Failure at this level usually means
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) that there is a problem with the tasks freezer subsystem that should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) reported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) If the "devices" test fails, most likely there is a driver that cannot suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) or resume its device (in the latter case the system may hang or become unstable
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) after the test, so please take that into consideration).  To find this driver,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) you can carry out a binary search according to the rules:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) - if the test fails, unload a half of the drivers currently loaded and repeat
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121)   (that would probably involve rebooting the system, so always note what drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)   have been loaded before the test),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) - if the test succeeds, load a half of the drivers you have unloaded most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124)   recently and repeat.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) Once you have found the failing driver (there can be more than just one of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) them), you have to unload it every time before hibernation.  In that case please
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) make sure to report the problem with the driver.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) It is also possible that the "devices" test will still fail after you have
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) unloaded all modules. In that case, you may want to look in your kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) configuration for the drivers that can be compiled as modules (and test again
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) with these drivers compiled as modules).  You may also try to use some special
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) kernel command line options such as "noapic", "noacpi" or even "acpi=off".
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) If the "platform" test fails, there is a problem with the handling of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) platform (eg. ACPI) firmware on your system.  In that case the "platform" mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) of hibernation is not likely to work.  You can try the "shutdown" mode, but that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) is rather a poor man's workaround.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) If the "processors" test fails, the disabling/enabling of nonboot CPUs does not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) work (of course, this only may be an issue on SMP systems) and the problem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) should be reported.  In that case you can also try to switch the nonboot CPUs
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) off and on using the /sys/devices/system/cpu/cpu*/online sysfs attributes and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) see if that works.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) If the "core" test fails, which means that suspending of the system/platform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) devices has failed (these devices are suspended on one CPU with interrupts off),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) the problem is most probably hardware-related and serious, so it should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) reported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) A failure of any of the "platform", "processors" or "core" tests may cause your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) system to hang or become unstable, so please beware.  Such a failure usually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) indicates a serious problem that very well may be related to the hardware, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) please report it anyway.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) b) Testing minimal configuration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) --------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) If all of the hibernation test modes work, you can boot the system with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) "init=/bin/bash" command line parameter and attempt to hibernate in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) "reboot", "shutdown" and "platform" modes.  If that does not work, there
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) probably is a problem with a driver statically compiled into the kernel and you
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) can try to compile more drivers as modules, so that they can be tested
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) individually.  Otherwise, there is a problem with a modular driver and you can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) find it by loading a half of the modules you normally use and binary searching
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) in accordance with the algorithm:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) - if there are n modules loaded and the attempt to suspend and resume fails,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) unload n/2 of the modules and try again (that would probably involve rebooting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) the system),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) - if there are n modules loaded and the attempt to suspend and resume succeeds,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) load n/2 modules more and try again.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) Again, if you find the offending module(s), it(they) must be unloaded every time
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) before hibernation, and please report the problem with it(them).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) c) Using the "test_resume" hibernation option
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) ---------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) /sys/power/disk generally tells the kernel what to do after creating a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) hibernation image.  One of the available options is "test_resume" which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) causes the just created image to be used for immediate restoration.  Namely,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) after doing::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) 	# echo test_resume > /sys/power/disk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) 	# echo disk > /sys/power/state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) a hibernation image will be created and a resume from it will be triggered
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) immediately without involving the platform firmware in any way.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) That test can be used to check if failures to resume from hibernation are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) related to bad interactions with the platform firmware.  That is, if the above
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) works every time, but resume from actual hibernation does not work or is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) unreliable, the platform firmware may be responsible for the failures.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) On architectures and platforms that support using different kernels to restore
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197) hibernation images (that is, the kernel used to read the image from storage and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) load it into memory is different from the one included in the image) or support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) kernel address space randomization, it also can be used to check if failures
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) to resume may be related to the differences between the restore and image
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) kernels.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) d) Advanced debugging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) ---------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) In case that hibernation does not work on your system even in the minimal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) configuration and compiling more drivers as modules is not practical or some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) modules cannot be unloaded, you can use one of the more advanced debugging
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) techniques to find the problem.  First, if there is a serial port in your box,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) you can boot the kernel with the 'no_console_suspend' parameter and try to log
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) kernel messages using the serial console.  This may provide you with some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212) information about the reasons of the suspend (resume) failure.  Alternatively,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) it may be possible to use a FireWire port for debugging with firescope
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) (http://v3.sk/~lkundrak/firescope/).  On x86 it is also possible to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) use the PM_TRACE mechanism documented in Documentation/power/s2ram.rst .
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) 2. Testing suspend to RAM (STR)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) ===============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) To verify that the STR works, it is generally more convenient to use the s2ram
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) tool available from http://suspend.sf.net and documented at
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222) http://en.opensuse.org/SDB:Suspend_to_RAM (S2RAM_LINK).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) Namely, after writing "freezer", "devices", "platform", "processors", or "core"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) into /sys/power/pm_test (available if the kernel is compiled with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) CONFIG_PM_DEBUG set) the suspend code will work in the test mode corresponding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) to given string.  The STR test modes are defined in the same way as for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) hibernation, so please refer to Section 1 for more information about them.  In
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) particular, the "core" test allows you to test everything except for the actual
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) invocation of the platform firmware in order to put the system into the sleep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) Among other things, the testing with the help of /sys/power/pm_test may allow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) you to identify drivers that fail to suspend or resume their devices.  They
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) should be unloaded every time before an STR transition.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) Next, you can follow the instructions at S2RAM_LINK to test the system, but if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) it does not work "out of the box", you may need to boot it with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) "init=/bin/bash" and test s2ram in the minimal configuration.  In that case,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240) you may be able to search for failing drivers by following the procedure
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) analogous to the one described in section 1.  If you find some failing drivers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) you will have to unload them every time before an STR transition (ie. before
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) you run s2ram), and please report the problems with them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) There is a debugfs entry which shows the suspend to RAM statistics. Here is an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) example of its output::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) 	# mount -t debugfs none /sys/kernel/debug
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) 	# cat /sys/kernel/debug/suspend_stats
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250) 	success: 20
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) 	fail: 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252) 	failed_freeze: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) 	failed_prepare: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) 	failed_suspend: 5
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255) 	failed_suspend_noirq: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256) 	failed_resume: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) 	failed_resume_noirq: 0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) 	failures:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) 	  last_failed_dev:	alarm
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) 				adc
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) 	  last_failed_errno:	-16
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) 				-16
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263) 	  last_failed_step:	suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) 				suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) Field success means the success number of suspend to RAM, and field fail means
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) the failure number. Others are the failure number of different steps of suspend
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268) to RAM. suspend_stats just lists the last 2 failed devices, error number and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) failed step of suspend.