On Wednesday, January 8, 2020 at 8:28:12 AM UTC-3, Claudia wrote:
>
> January 8, 2020 12:10 AM, "Guerlan" <[email protected] <javascript:>> 
> wrote:
>
> > On Tuesday, January 7, 2020 at 8:41:31 PM UTC-3, Claudia wrote:
> > 
> >> January 7, 2020 6:08 PM, "Guerlan" <[email protected]> wrote:> On 
> Monday, January 6, 2020 at
> >> 12:43:40 AM UTC-3, Claudia wrote:
> >>> 
> >>>> January 6, 2020 3:14 AM, [email protected] 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. 
>


Ok thanks, here's the new thread 
https://groups.google.com/forum/#!topic/qubes-users/eMWxHSy9h7c 

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4e10bb5b-ac36-49ce-a613-457b6b80013a%40googlegroups.com.

Reply via email to