You are not logged in.
Issue: I can "systemctl suspend" once after a reboot and resume after that just fine, but after I suspend again I can't resume: my keyboard has lighting, it light up, my fans spin up, but the display is off. I tried blindly opening a terminal and trying to suspend again or shutdown and it didn't work, but I guess since I didn't resume properly I can't do that.
What I've tried so far:
1. Installing the Intel microcode package and applying it (I use grub as a boot loader), didn't help
2. Tried uswsusp's "s2ram", didn't change the behavior
3. Installed nouveau package (I hope it's applied, I don't know how to test it), didn't work
4. Tried normal and LTS linux kernels, didn't work
I don't have even a slightest clue how to debug this, what's annoying is the fact that it can successfully suspend once, but then it just fails. I have 16 gigs of swap configured (I have 16 gigs of RAM, maybe I don't have enough swap?). Any sources I can read up and learn at least how to understand how it fails like that would be appreciated since I've moved from Ubuntu to Arch only about 4 days ago and have only basic understanding of what I'm doing.
Last edited by sv-cheats-1 (2022-02-17 21:14:32)
Offline
I don’t know if it matters but should I be worried that my BIOS might be outdated? I haven’t updated it since I bought the motherboard, so since back in 2018 maybe? Can’t quite remember nor do I want to risk messing around with BIOS and stuff
Offline
S3 isn't related to swap.
Enable https://wiki.archlinux.org/title/Keyboa … el_(SysRq) and attempt a clean-as-possible reboot after a failing S3, then inspect your system journal for the last boot (sudo journalctl -b -1) - you can also do this right now, maybe something actually got logged.
installed nouveau
suggests you've an nvidia chip, see https://download.nvidia.com/XFree86/Lin … ement.html
tried blindly opening a terminal
how exactly did you go about that? ctrl+alt+f2 or opening eg. konsole or gnome-terminal?
General S3 debugging instructions: https://01.org/blogs/rzhang/2015/best-p … ate-issues
And ceterum censeo: is there a parallel OS installation (notably windows)?
Offline
S3 isn't related to swap.
Enable https://wiki.archlinux.org/title/Keyboa … el_(SysRq) and attempt a clean-as-possible reboot after a failing S3, then inspect your system journal for the last boot (sudo journalctl -b -1) - you can also do this right now, maybe something actually got logged.installed nouveau
suggests you've an nvidia chip, see https://download.nvidia.com/XFree86/Lin … ement.html
tried blindly opening a terminal
how exactly did you go about that? ctrl+alt+f2 or opening eg. konsole or gnome-terminal?
General S3 debugging instructions: https://01.org/blogs/rzhang/2015/best-p … ate-issues
And ceterum censeo: is there a parallel OS installation (notably windows)?
Ok, thank you for suggesting all of that, I’ll try all of it later today and yes, I have Windows 10 installed on the same drive in parallel
Offline
I have Windows 10 installed […] in parallel
3rd link below, mandatory.
Offline
Thank you very much for the response!!!
Ok so I'm currently in the process of doing this
Enable https://wiki.archlinux.org/title/Keyboa … el_(SysRq) and attempt a clean-as-possible reboot after a failing S3, then inspect your system journal for the last boot (sudo journalctl -b -1) - you can also do this right now, maybe something actually got logged.i
I believe I have enabled everything, but I don't know how to "attempt a clean-as-possible reboot after a failing S3". What does "clean-as-possible reboot" and
"S3" mean?
Also I've checked out the last link per your suggestion and I think I now know how these debugging tools work and I can see more stuff being printed when during startup, but how do I view the logs? Is there a way to save them to a file to check them out after rebooting? What's the "serial console"?
Offline
What does "clean-as-possible reboot" and "S3" mean?
Not rebooting by pressing the power button (but using the sysrq) and https://en.wikipedia.org/wiki/Advanced_ … wer_states (S3 is suspend to ram)
But first things first: see the 3rd link below, disable windows fast start (NOT the BIOS option!) and reboot windows and linux (in doubt: twice - voodoo advice for erratic behavior) and see whether the issue remains,
A hibernating windows is the primary cause for weired ACPI behavior.
We'll look at the in depth debugging if necessary.
Offline
Ok thank you again, I'll disable Window's fast start and properly shut it down and will give you updates
Offline
So I've booted into Windows, disabled fast reboot, then shut it down safely, let it take as much time as it needed and the booted back to Arch. I've managed to suspend-resume successfully 2 times in a row, but on the third time it froze again during resume. This 2 times streak happened only once after the changes to Windows, after that Arch again could only handle 1 suspend-resume. I'll try to do the clean-as-possible reboot, because journalctl already prints out a lot of info (which probably means I've enabled everything correctly I guess). I'll post the log soon.
Offline
So I've booted into Windows, disabled fast reboot, then shut it down safely, let it take as much time as it needed and the booted back to Arch. I've managed to suspend-resume successfully 2 times in a row, but on the third time it froze again during resume. This 2 times streak happened only once after the changes to Windows, after that Arch again could only handle 1 suspend-resume. I'll try to do the clean-as-possible reboot, because journalctl already prints out a lot of info (which probably means I've enabled everything correctly I guess). I'll post the log soon.
I've just noticed links that are attached below every reply you send and there was a page about Windows/Linux dualbooting and how these OSs don't like each other. This page here https://wiki.archlinux.org/title/Dual_b … ibernation mentions this:
In any case if you disable a setting, make sure to disable the setting and then shut down Windows, before ~installing Linux~; note that rebooting is not sufficient.
Should have I disabled this setting before installing Arch? Should I maybe try reinstalling now? Or should I just try disabling hibernation for Windows?
Last edited by sv-cheats-1 (2022-02-16 16:59:56)
Offline
I believe I have to reinstall every OS now, because I've used a Windows debloater (for some reason) and it broke my time sync on Windows (my time is 3 hours less that it should be) and this somehow affected the time on Arch (here time is 3 hours more that it should be)... so... yeah... a fresh new start... maybe it'll fix everything including the suspend stuff...
Last edited by sv-cheats-1 (2022-02-16 17:40:22)
Offline
Hold on.
The time is carried across the HW clock, updating it via ntp and setting the hwclock will sanitize it. You're probably using the wrong timezone (in windows)
You don't have to re-install linux after altering windows.
The wording in the wiki is a bit ambigious (I guess) but the crucial part is to properly shut down the system (and not just reboot it) - I assume the wiki operates in the assumption that you're doing this in preparation to install linux at all.
What you should do however is to shut down windows, boot it, shut it down again and then boot and reboot linux (this is anecdotal and borderline voodoo) to "unconfuse" the BIOS idea of the power state.
Offline
Hold on.
The time is carried across the HW clock, updating it via ntp and setting the hwclock will sanitize it. You're probably using the wrong timezone (in windows)You don't have to re-install linux after altering windows.
The wording in the wiki is a bit ambigious (I guess) but the crucial part is to properly shut down the system (and not just reboot it) - I assume the wiki operates in the assumption that you're doing this in preparation to install linux at all.
What you should do however is to shut down windows, boot it, shut it down again and then boot and reboot linux (this is anecdotal and borderline voodoo) to "unconfuse" the BIOS idea of the power state.
My god, ok, I’ll try to do this this evening and will report back
Offline
So, I've followed the exact steps you've described (booted to windows, shutdown, booted to windows, shutdown, booted to linux, shutdown, booted to linux) and I've managed to suspend-resume successfully 2 times in a row, though on a third time it failed. I did, however, manage to reboot using the SysRq key combo after a failed S3.
Last edited by sv-cheats-1 (2022-02-17 16:24:08)
Offline
I did, however, manage to reboot using the SysRq key combo after a failed S3.
Then the system journal for the previous boot might provide some insight into what's going wrong…
Offline
I did, however, manage to reboot using the SysRq key combo after a failed S3.
Then the system journal for the previous boot might provide some insight into what's going wrong…
One sec
Offline
seth wrote:I did, however, manage to reboot using the SysRq key combo after a failed S3.
Then the system journal for the previous boot might provide some insight into what's going wrong…
One sec
Here's the link https://rentry.co/z4xpk. I couldn't fit the entire log onto PasteBin, I've locked for some alternative and found something, but still had to remove a few dozen lines from the beginning and I've pasted them below. The rest is in the link. I used "sudo journalctl -b -1 >> log.txt" to do this.
Feb 16 19:29:57 sv-cheats-1 systemd-journald[304]: Journal started
Feb 16 19:29:57 sv-cheats-1 systemd-journald[304]: Runtime Journal (/run/log/journal/6a34eda909c64d8c9abe967dd7e7523d) is 8.0M, max 795.4M, 787.4M free.
Feb 16 19:29:57 sv-cheats-1 systemd-journald[304]: Missed 368 kernel messages
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_wakeup_tracer+0x0/0x2d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_wakeup_tracer+0x0/0x2d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_graph_trace+0x0/0x5d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_graph_trace+0x0/0x5d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling trace_events_eprobe_init_early+0x0/0x27 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall trace_events_eprobe_init_early+0x0/0x27 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling trace_events_synth_init_early+0x0/0x27 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall trace_events_synth_init_early+0x0/0x27 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_kprobe_trace_early+0x0/0x26 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_kprobe_trace_early+0x0/0x26 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling mem_cgroup_swap_init+0x0/0x55 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall mem_cgroup_swap_init+0x0/0x55 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling memory_failure_init+0x0/0x97 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall memory_failure_init+0x0/0x97 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling cma_init_reserved_areas+0x0/0x1d8 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall cma_init_reserved_areas+0x0/0x1d8 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling fsnotify_init+0x0/0x49 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall fsnotify_init+0x0/0x49 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling filelock_init+0x0/0x98 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall filelock_init+0x0/0x98 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_misc_binfmt+0x0/0x31 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_misc_binfmt+0x0/0x31 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_script_binfmt+0x0/0x16 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_script_binfmt+0x0/0x16 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_elf_binfmt+0x0/0x16 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_compat_elf_binfmt+0x0/0x16 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_compat_elf_binfmt+0x0/0x16 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling configfs_init+0x0/0x9a @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall configfs_init+0x0/0x9a returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling debugfs_init+0x0/0x63 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall debugfs_init+0x0/0x63 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling tracefs_init+0x0/0x3d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall tracefs_init+0x0/0x3d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling securityfs_init+0x0/0x6e @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall securityfs_init+0x0/0x6e returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling lockdown_secfs_init+0x0/0x2d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall lockdown_secfs_init+0x0/0x2d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling prandom_init_early+0x0/0x166 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall prandom_init_early+0x0/0x166 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling pinctrl_init+0x0/0xae @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: pinctrl core: initialized pinctrl subsystem
Feb 16 19:29:57 sv-cheats-1 kernel: initcall pinctrl_init+0x0/0xae returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling gpiolib_dev_init+0x0/0xfc @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall gpiolib_dev_init+0x0/0xfc returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling virtio_init+0x0/0x20 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall virtio_init+0x0/0x20 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling regulator_init+0x0/0x9c @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall regulator_init+0x0/0x9c returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling iommu_init+0x0/0x2b @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall iommu_init+0x0/0x2b returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling component_debug_init+0x0/0x1d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall component_debug_init+0x0/0x1d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling early_resume_init+0x0/0xb9 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: PM: RTC time: 16:29:55, date: 2022-02-16
Feb 16 19:29:57 sv-cheats-1 kernel: initcall early_resume_init+0x0/0xb9 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling opp_debug_init+0x0/0x1d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall opp_debug_init+0x0/0x1d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling cpufreq_core_init+0x0/0x69 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall cpufreq_core_init+0x0/0x69 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling cpufreq_gov_performance_init+0x0/0x11 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall cpufreq_gov_performance_init+0x0/0x11 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling cpufreq_gov_powersave_init+0x0/0x11 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall cpufreq_gov_powersave_init+0x0/0x11 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling cpufreq_gov_userspace_init+0x0/0x11 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall cpufreq_gov_userspace_init+0x0/0x11 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling CPU_FREQ_GOV_ONDEMAND_init+0x0/0x11 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall CPU_FREQ_GOV_ONDEMAND_init+0x0/0x11 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling CPU_FREQ_GOV_CONSERVATIVE_init+0x0/0x11 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall CPU_FREQ_GOV_CONSERVATIVE_init+0x0/0x11 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling cpuidle_init+0x0/0x20 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall cpuidle_init+0x0/0x20 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling capsule_reboot_register+0x0/0x11 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall capsule_reboot_register+0x0/0x11 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling sock_init+0x0/0x9f @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall sock_init+0x0/0x9f returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling net_inuse_init+0x0/0x24 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling net_defaults_init+0x0/0x24 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall net_defaults_init+0x0/0x24 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling init_default_flow_dissectors+0x0/0x50 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall init_default_flow_dissectors+0x0/0x50 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling netpoll_init+0x0/0x29 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall netpoll_init+0x0/0x29 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling netlink_proto_init+0x0/0x17d @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: NET: Registered PF_NETLINK/PF_ROUTE protocol family
Feb 16 19:29:57 sv-cheats-1 kernel: initcall netlink_proto_init+0x0/0x17d returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling genl_init+0x0/0x38 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall genl_init+0x0/0x38 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling bsp_pm_check_init+0x0/0x14 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall bsp_pm_check_init+0x0/0x14 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling trace_boot_init+0x0/0xd7 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall trace_boot_init+0x0/0xd7 returned 0 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling __gnttab_init+0x0/0x30 @ 1
Feb 16 19:29:57 sv-cheats-1 kernel: initcall __gnttab_init+0x0/0x30 returned -19 after 0 usecs
Feb 16 19:29:57 sv-cheats-1 kernel: calling pi_init+0x0/0x59 @ 1Offline
sv-cheats-1 wrote:seth wrote:Then the system journal for the previous boot might provide some insight into what's going wrong…
One sec
Here's the link https://rentry.co/z4xpk. I couldn't fit the entire log onto PasteBin, I've locked for some alternative and found something, but still had to remove a few dozen lines from the beginning and I've pasted them below. The rest is in the link. I used "sudo journalctl -b -1 >> log.txt" to do this.
The link is borked, I'll try pastebin again.
Offline
sudo journalctl -b -1 | curl -F 'f:1=<-' ix.ioOffline
The link is borked, I'll try pastebin again.
Here's the link, sorry for the Google Drive, the log file takes about 1Mb, can't paste it anywhere properly
https://drive.google.com/file/d/1XgOj8L … sp=sharing
Offline
nouveau times out - consider trying the nvidia blob.
Offline
nouveau times out - consider trying the nvidia blob.
Ayyyyy hell yeah!!!! This was the issue!!!! I've installed nvidea package via pacman and I believe I can suspend-resume with no issues!!! Just managed to do so 3 times in a row!!! A new record!!! Thank you so much for the help, seth!!!
I guess I should prepend [SOLVED] to the name of this topic, right?
Last edited by sv-cheats-1 (2022-02-17 21:02:51)
Offline
I guess I should prepend [SOLVED] to the name of this topic, right?
Offline
sv-cheats-1 wrote:I guess I should prepend [SOLVED] to the name of this topic, right?
Done! Thank you again for your help!
Offline