January 8, 2020 12:10 AM, "Guerlan" <worms....@gmail.com> wrote:
> On Tuesday, January 7, 2020 at 8:41:31 PM UTC-3, Claudia wrote: > >> January 7, 2020 6:08 PM, "Guerlan" <worm...@gmail.com> wrote:> On Monday, >> January 6, 2020 at >> 12:43:40 AM UTC-3, Claudia wrote: >>> >>>> January 6, 2020 3:14 AM, dmoe...@gmail.com wrote:> On Sunday, January 5, >>>> 2020 at 9:49:42 PM >> UTC-5, >>>> Guerlan wrote: >>>>>> can you tell me how you figured this out? I've been trying to fix a >>>>>> suspend bug in mine and >> It'd >>>> be >>>>>> helpful to know how you debugged things >>>>> >>>>> Mostly trial and error, trying all the things listed above. Two little >>>>> tricks to use: >>>>> >>>>> 1. Look at the end of journalctl right before it tries to suspend. This >>>>> is where I saw that it >>>> was >>>>> going into s2idle, which then brought me to this thread: >>>>> >>>> >> https://groups.google.com/forum/#!msg/qubes-users/TmGDlkluJgM/1BFsQZWNDAAJ;context-place=forum/qubes >>>>> users This Dell did not have the lack of S3 that the new Thinkpads have, >>>>> but it did still try >> to >>>>> use s2idle. >>>> >>>> /sys/power/mem_sleep will list supported modes, with the default in >>>> brackets. You can echo to it >> to >>>> set the default at runtime, or use the boot parameter. >>> >>> [lz@dom0 ~]$ cat /sys/power/mem_sleep >>> s2idle [deep] >>> >>> What does this mean? It means that it detected only s2idle or that my >>> system does not support >>> suspend to RAM? I've used Ubuntu and Fedora and lid closing always worked, >>> I just don't know if >> it >>> was idle or to ram or other thing. >> >> This means that s2idle mode and deep mode are the two modes supported by >> your machine, and that >> deep is the mode that will be used for sleep when no specific mode is >> specified, such as using the >> lid switch or the logout menu or systemctl suspend for example. In OP's >> case, deep is manually set >> as default using the kernel parameter mem_sleep_default=deep. Generally the >> kernel chooses the >> deepest mode supported (s2idle -> shallow -> deep) to be the default, but on >> some machines the >> kernel will choose s2idle as the default even if deep is supported. >> >> https://www.kernel.org/doc/html/v4.18/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-sy >> tem-suspend-and-hibernation > > Thanks! I now understand how it works. I've checked and indeed my system > defaults to deep. I tried > s2idle by doing echo freeze > /sys/power/state and the screen turns off but > they keyboard keeps > with lights on. Pressing buttons does nothing. Pressing touchpad, nothing. > Pressing power rapidly, > nothing. Had to reboot by long pressing power. Shouldn't s2idle always work > since it's software > based? I don't know much about s2idle, but yes, in theory it should be the most reliable of the sleep states. It could be a graphics driver issue. However, from your log it looks like it's still entering deep sleep. > I have no other ideas. If someone know a little more on how to debug, I'd be > glad. Remember that I > found this error in ACPI https://github.com/QubesOS/qubes-issues/issues/5555 > on dmesg. It indicates > that ASPM does not work. Maybe this is crucial? Debugging suspend is a long and complicated process. I don't want to get any more off-topic in this thread. Please start a new thread for your machine detailing everything you've tried so far, including logs and any other relevant information, so it's all in one place. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/3a967cec86c0cf40795e6511e062e471%40disroot.org.
