Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
On Wednesday, January 8, 2020 at 8:28:12 AM UTC-3, Claudia wrote: > > January 8, 2020 12:10 AM, "Guerlan" > > wrote: > > > On Tuesday, January 7, 2020 at 8:41:31 PM UTC-3, Claudia wrote: > > > >> January 7, 2020 6:08 PM, "Guerlan" 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/ 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 qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4e10bb5b-ac36-49ce-a613-457b6b80013a%40googlegroups.com.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
January 8, 2020 12:10 AM, "Guerlan" wrote: > On Tuesday, January 7, 2020 at 8:41:31 PM UTC-3, Claudia wrote: > >> January 7, 2020 6:08 PM, "Guerlan" 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/ > 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.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
On Tuesday, January 7, 2020 at 8:41:31 PM UTC-3, Claudia wrote:
>
> January 7, 2020 6:08 PM, "Guerlan" >
> 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-system-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 also followed the dmoe...@gmail.com tip of viewing journalctl just before
suspend:
Jan 07 20:56:24 dom0 systemd-logind[1925]: Lid closed.
Jan 07 20:56:24 dom0 systemd-logind[1925]: Suspending...
Jan 07 20:56:24 dom0 systemd[1]: Starting Qubes suspend hooks...
Jan 07 20:56:25 dom0 qmemman.daemon.algo[1921]:
balance_when_enough_memory(xen_free_memory=8172072647,
total_mem_pref=2493652659.2, total_available_memory=13171544083.8)
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '5'
act=3198156800 pref=963591782.4 last_target=3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '0'
act=4294967296 pref=1530060876.8 last_target=4294967296
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447
memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 5 to
3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 0 to
4294967296
Jan 07 20:56:25 dom0 qrexec[3884]: qubes.GetDate: social -> @default:
allowed to dom0
Jan 07 20:56:25 dom0 qmemman.daemon.algo[1921]:
balance_when_enough_memory(xen_free_memory=8172072647,
total_mem_pref=2450575027.2, total_available_memory=13214621715.8)
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '5'
act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: dom '0'
act=4294967296 pref=1530060876.8 last_target=4294967296
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447
memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 5 to
3198156800
Jan 07 20:56:25 dom0 qmemman.systemstate[1921]: mem-set domain 0 to
4294967296
Jan 07 20:56:26 dom0 qmemman.daemon.algo[1921]:
balance_when_enough_memory(xen_free_memory=8172072647,
total_mem_pref=2398557056.0, total_available_memory=13266639687.0)
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: dom '5'
act=3198156800 pref=920514150.4 last_target=3198156800
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: dom '0'
act=4294967296 pref=1478042905.601 last_target=4294967296
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: stat: xenfree=8224501447
memset_reqs=[('5', 3198156800), ('0', 4294967296)]
Jan 07 20:56:26 dom0 qmemman.systemstate[1921]: mem-set domain 5 to
3198156800
Jan 07 20:56:26 dom0
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
January 7, 2020 6:08 PM, "Guerlan" 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-system-suspend-and-hibernation -- 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/edea108d519cb88e335f236b52b5f8c2%40disroot.org.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
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. -- 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/bc364066-1824-413d-afd1-e3c148ad7a53%40googlegroups.com.
Re: [qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
January 6, 2020 3:14 AM, dmoer...@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. -- 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/c90b972acea666dd9454ad277bb3%40disroot.org.
[qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
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. 2. Run speaker-test in dom0 before suspending, if you hear sound on resume then it's some sort of a screen problem. What hardware do you have? If it's corebooted you might want to check out this thread: https://groups.google.com/forum/#!msg/qubes-users/bHJJhK4HtIw/ieQkoJePCgAJ -- 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/a6723332-968f-45e1-a376-40cb7cc801c8%40googlegroups.com.
[qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
On Saturday, January 4, 2020 at 7:00:54 PM UTC-3, dmoe...@gmail.com wrote: > > The suspending problem was s2idle. Adding mem_sleep_default=deep to the > kernel= line of /boot/efi/EFI/qubes/xen.cfg fixes the suspend problem. > > Installing kernel-latest (5.3.11-1) fixes the last two problems with > completing shutdown and with a lack of a bootsplash. > > I'll post an HCL in a moment. Everything now works flawlessly. > > Daniel > 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 -- 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/601cf502-8ac2-4749-9709-fbc534109508%40googlegroups.com.
[qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3
The suspending problem was s2idle. Adding mem_sleep_default=deep to the kernel= line of /boot/efi/EFI/qubes/xen.cfg fixes the suspend problem. Installing kernel-latest (5.3.11-1) fixes the last two problems with completing shutdown and with a lack of a bootsplash. I'll post an HCL in a moment. Everything now works flawlessly. Daniel -- 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/72e1f835-0a5c-42ff-83df-4ae23d884775%40googlegroups.com.
