 |
VOOZH | about |
|
VOOZH | about |
Hi. Suspend to RAM used to work fine for a long time. Then, after the PC sustained some extra physical wear and tear, and after I had to replace both keyboard and mouse, it fails to correctly suspend to RAM (it goes into sleep fine, but almost immediately wakes up). Still using the same Arch Linux setup as before, didn't reinstall.
Maybe this could be related to mouse and/or keyboard. Sometimes if I disconnect them both before suspending, it might stay asleep, but this is not guaranteed. Maybe it was just a coincidence.
I have Windows 10 on another disk (just to play a game occasionally), and with Windows this problem doesn't happen, and I don't have to disconnect any devices.
What can I do to make the sleep work correctly on Arch Linux as well?
More details:
Operating System: Arch Linux
KDE Plasma Version: 5.24.5
KDE Frameworks Version: 5.94.0
Qt Version: 5.15.4
Kernel Version: 5.18.3-zen1-1-zen (64-bit)
Graphics Platform: X11
Processors: 16 × AMD Ryzen 7 3800X 8-Core Processor
Memory: 62.7 GiB of RAM
Graphics Processor: AMD Radeon RX 590 Series
Both keyboard and mouse are wireless, with USB dongles, made by Logitech. Previously (when everything worked fine) I had a different wired keyboard and wireless mouse, all also by Logitech.
Last edited by magicgoose (2022-06-12 13:18:05)
Offline
Disable them one by one to get the bad device.
https://wiki.archlinux.org/title/Wakeup … om_suspend
If both are faulty disable them in BIOS and use the power button.
sys2064
Offline
Thanks for pointer. I looked at /proc/acpi/wakeup, there were 6 enabled entries. I disabled them all:
echo GPP0 | sudo tee /proc/acpi/wakeup
echo GPP8 | sudo tee /proc/acpi/wakeup
echo GP12 | sudo tee /proc/acpi/wakeup
echo GP13 | sudo tee /proc/acpi/wakeup
echo XHC0 | sudo tee /proc/acpi/wakeup
echo BXBR | sudo tee /proc/acpi/wakeup
After this, all entries in /proc/acpi/wakeup are disabled. Then I tried to suspend and the same problem still happens.
I'll try to see what I can do in the PC motherboard's firmware menu (BIOS) in a few minutes...
Offline
Unfortunately looks like everything that's relevant is already disabled in BIOS. I can upload a photo if anyone's interested how it looks, but there are settings named:
"Power On By Keyboard"
"Power On By Mouse"
"Resume by Alarm"
"Wake on LAN"
and they are all disabled. There are also a couple other settings on that screen which I don't recognize, some cryptic words.
Offline
I have Windows 10 on another disk
3rd link below - not a guarantee, but the ACPI in most affected by this. Reboot windows and linux twice afterwards (for voodoo reasons)
Offline
Looks like hibernation was already disabled in this Windows installation. Just in case, I did it anyway -- ran "powercfg -h off" from admin powershell window. Then shut down. After that, the problem still happens. I saw it needs to be done twice, I'll check later again.
Last edited by magicgoose (2022-06-12 15:20:01)
Offline
Try this after it woke up by itself (to show wakeup reason). Maybe it delivers a hint or something.
$ sudo dmidecode | grep Wake-upsys2064
Offline
After turning on, no sleep just yet:
~> sudo dmidecode | grep Wake-up
Wake-up Type: Power Switch
Then, after sleep (and unwanted immediate wake-up):
~> sudo dmidecode | grep Wake-up
Wake-up Type: PCI PME#
Searched this a bit, looks like this is used for the keyboard, but I guess that's just one of the many possibilities.
Offline
You could try passing
pcie_port_pm=off pcie_pme=nomsi to the kernel.
Do you still have a wired keyboard?
Offline
Maybe raising the ACPI debug verbosity leads to something.
Enable all ACPI hardware-related messages:
$ sudo sh -c "echo 0x2 > /sys/module/acpi/parameters/debug_layer"
$ sudo sh -c "echo 0xffffffff > /sys/module/acpi/parameters/debug_level"sys2064
Offline
Thanks.
I don't have my previous wired keyboard, and looks like my current wireless one doesn't have a wired connection option - the USB port is only used for charging and maybe for firmware updates, but it doesn't work as a keyboard when connected by wire.
In the 1st ACPI command above, I tried to understand mask by reading your link, and it means only ACPI_HARDWARE and nothing else from "supported mask values"?
Where should I look for the written log, journalctl?
Offline
In the 1st ACPI command above, I tried to understand mask by reading your link, and it means only ACPI_HARDWARE and nothing else from "supported mask values"?
Where should I look for the written log, journalctl?
Yes and yes.
sys2064
Offline
Ran these 2 commands, then put it to sleep, and then looked at the output of
journalctl -r
There is a lot of text related to ACPI, unsure what is the important part. It's also all posted with "kernel" tag.
Is there a simple way to filter out unrelated messages which are also under "kernel"?
Offline
You can esp. filter by the boot "sudo journalctl -b"
Offline
Kernel buffer only:
$ sudo journalctl -b --dmesg$ sudo dmesg --color=always |lessYou can filter with grep, awk, etc. but i don't think its necessary/useful. The other kernel messages might help for orientation (system state, etc).
Maybe clear the dmesg buffer first.
$ sudo dmesg -CIts possible that 'dmesg' hits the kernel ring buffer limit so it might be better to use 'journalctl' instead (or raise the ring buffer).
You can also limit the ACPI debug verbosity (if you know what you're doing).
$ cat /sys/module/acpi/parameters/debug_level
Description Hex SET
ACPI_LV_INIT 0x00000001 [ ]
ACPI_LV_DEBUG_OBJECT 0x00000002 [ ]
ACPI_LV_INFO 0x00000004 [*]
ACPI_LV_REPAIR 0x00000008 [*]
ACPI_LV_TRACE_POINT 0x00000010 [ ]
ACPI_LV_INIT_NAMES 0x00000020 [ ]
ACPI_LV_PARSE 0x00000040 [ ]
ACPI_LV_LOAD 0x00000080 [ ]
ACPI_LV_DISPATCH 0x00000100 [ ]
ACPI_LV_EXEC 0x00000200 [ ]
ACPI_LV_NAMES 0x00000400 [ ]
ACPI_LV_OPREGION 0x00000800 [ ]
ACPI_LV_BFIELD 0x00001000 [ ]
ACPI_LV_TABLES 0x00002000 [ ]
ACPI_LV_VALUES 0x00004000 [ ]
ACPI_LV_OBJECTS 0x00008000 [ ]
ACPI_LV_RESOURCES 0x00010000 [ ]
ACPI_LV_USER_REQUESTS 0x00020000 [ ]
ACPI_LV_PACKAGE 0x00040000 [ ]
ACPI_LV_ALLOCATIONS 0x00100000 [ ]
ACPI_LV_FUNCTIONS 0x00200000 [ ]
ACPI_LV_OPTIMIZATIONS 0x00400000 [ ]
ACPI_LV_MUTEX 0x01000000 [ ]
ACPI_LV_THREADS 0x02000000 [ ]
ACPI_LV_IO 0x04000000 [ ]
ACPI_LV_INTERRUPTS 0x08000000 [ ]
ACPI_LV_AML_DISASSEMBLE 0x10000000 [ ]
ACPI_LV_VERBOSE_INFO 0x20000000 [ ]
ACPI_LV_FULL_TABLES 0x40000000 [ ]
ACPI_LV_EVENTS 0x80000000 [ ]
--
debug_level = 0x0000000C (* = enabled)Last edited by Maniaxx (2022-08-21 15:51:26)
sys2064
Offline
I had the same issue with the Gigabyte B650M mainboard. This fix worked for me https://bbs.archlinux.org/viewtopic.php?pid=2227413.
Offline
I had the same issue with the Gigabyte B650M mainboard. This fix worked for me https://bbs.archlinux.org/viewtopic.php?pid=2227413.
Please don't necropost 1+ year-old threads. Read this.
Hello, traveler.
Pronouns: sylv/sylvs it/its
my website
Offline
Powered by FluxBB
