nov 09 07:49:36 EzaRuda systemd-sleep[3214]: Entering sleep state 'suspend'...
nov 09 07:50:38 EzaRuda systemd-sleep[3214]: Failed to put system to sleep. System resumed again: Device or resource busy
Hmm, can you do a,
sudo powertop
(wait for it to launch it takes some time). Use Tab to go to the WakeUp section and see if
>> Disabled Wake-on-lan status for device wlp0s20f3
Disabled Wake status for USB device usb3
Disabled Wake status for USB device 3-6
Disabled Wake status for USB device usb1
Disabled Wake status for USB device usb4
Disabled Wake status for USB device 3-10
Disabled Wake status for USB device usb2
any of these are enabled instead of disabled? If any of these are set to enabled then press Enter to toggle their state and once done try to suspend and see if any changes happen (no need to reboot)?
Yeah, they were enabled. I turned them off and trying to suspend it seemed to suspend… then, having disabled all the usb devices, the only way to wake it was the power button… and it seemed to wake up but could not turn on the screen - even changing the HDMI/DVI (I am connected via DVI - HDMI is going to a dock for the Steam Deck, not connected atm) source in the monitor could not move it from black screen.
I then rebooted and in powertop I now see this again:
>> Disabled Wake-on-lan status for device enp12s0
Disabled Wake status for USB device usb5
Disabled Wake status for USB device 4-2
Disabled Wake status for USB device usb3
Disabled Wake status for USB device 2-1
Disabled Wake status for USB device usb1
Enabled Wake status for USB device 1-1.3
Enabled Wake status for USB device 1-1.1
Disabled Wake status for USB device 3-2
Enabled Wake status for USB device 2-1.5
Disabled Wake status for USB device usb6
Disabled Wake status for USB device 1-1
Disabled Wake status for USB device usb4
Disabled Wake status for USB device usb2
Disabled Wake status for USB device 2-1.6
I dit not enable the usb devices myself, after the reboot it seems it reset to the previous state.
Yeah, powertop changes are temporary you can look at the commands it’s using to toggle them from enable to disable and create a systemd service to execute those commands. However, before we do any of that we should take a look at journal logs,
journalctl -r -n 500 -b -1 | tb
To get top 500 lines from last boot’s journal and,
first and see if it works? In case it doesn’t and causes issues you can reboot your system. In case it works you can enable it so that it autostarts at boot.
I’ll look at the article and when I am back with the system do the test, thank you!
I think I found out what usb device interferes… but if the system does not turn on the monitor it would be useless to disable it.
In the meantime: I forgot to mention that, after the creation of the swap partition, “Hibernate” appeared amongst the options, alongside suspend.
However, if I click “Hibernate”, it brings me directly to the login screen (dragon wallpaper with clock → login screen) and nothing else happens.
To enable hibernation, in addition to creating the swap device and adding the kernel parameter you must add a dracut module and regenerate the initramfs. See this post, for example:
Just to clarify what hibernation does: when you trigger hibernation, the computer takes the entire session that is being held in RAM and writes it onto the hard drive. Then the computer completely shuts down. When you power the computer back on, it will read the session that was saved on the disk back into RAM and attempt to restore the session.
It is not the same as suspend, which is more of an “idle” state where the monitors and other peripherals may turn off, but the computer stays on and when you move the mouse or whatever it comes right back.
This is what I was trying to say: setting up hibernation will not fix the issue with suspend, it just enables a completely different power management state.
I don’t want to derail the discussion, but if we can just backtrack for a moment:
One explanation for this is a kernel change may have introduced a regression. This is actually fairly common. A quick, simple thing to test will be to install the LTS kernel and see if the issue persists when you boot with it.
sudo pacman -S linux-lts linux-lts-headers
After you reboot, you should be able to select the LTS kernel from the advanced boot options in the Grub menu.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 003: ID 046d:c539 Logitech, Inc. Lightspeed Receiver
Bus 002 Device 004: ID 046d:0a4d Logitech, Inc. G430 Surround Sound Gaming Headset
Bus 002 Device 005: ID 2516:003b Cooler Master Co., Ltd. MasterKeys Pro L
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 003 Device 003: ID 0763:410c M-Audio AIR 192 6
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 05e3:0616 Genesys Logic, Inc. hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Thank you for the additional input and clarification.
I already tried installing the LTS kernel and using it - if anything, unfortunately, the result was worse: trying to suspend went in a loop for several times with messages of “loading linux-lts” and “loading initial ramdisk”, then brought me to login screen.
So: worse than Zen Kernel, I think?
I’m trying to activate hibernation following your instructions, in the meantime: thanks for that as well!
EDIT
after doing this and rebooting, hibernation now tries to do its thing, but result is the same that with suspend: fans still spinning, keybard still lighting up, black screen for a minute or so, then back to login screen.
This is happening most likely due to the same reason suspend is not working, the usb device is waking it up. I tried looking at your logs from when you disabled it using powertop. It seems the system went to sleep but never woke up. It just doesn’t have any logs that indicate it tried to wake up from it’s suspend state.
A fake wake-up then? I thought it woke because of the fans spinning and keyboard lights coming back. But I guess it could be…
Maybe if I try and somewhat disable the usb devices (or the one generating the problem) and leaving the power button as the only mean to wake the system up? Should I see the power button in powertop as well?
Your logs say the system could not go to sleep because device or resource is busy which is your USB device that’s enabled to wake up your system. Once you disabled it using powertop you could go to sleep but not recover from it… Quite weird in my opinion. You should take a look at the systemd service I mentioned before and check if it helps. In case it doesn’t remove it.
Well we have tbg and bluishHumility looking at this thread. They are much more experienced than me.
there was a blurb in the archwiki article bluishhumility linked earlier about this exact thing, that certain system peripherals can interfere with the suspend and hibernation function.
i think you’re on the right track in isolating the specific interfering device.
you could try disconnecting any devices you have connected to your rig one by one to see if you can isolate it that way.
the chances of it being a mouse or keyboard are limited so i’d try things like a headset, any webcams or other such singular devices and anything connected to a hub before trying the hubs themselves.
If you are using Linux kernel 6.1 and above on an AMD CPU, this can also be caused by an S3-related control policy issue in the kernel. A temporary solution would be turning off wakeup on related i2c devices. You can find them by
$ ls /sys/bus/i2c/devices/*/power/wakeup
And the format of the device name should be i2c-ELAN0679:00 or i2c-MSFT0001:00. Then, test if the below command can enter suspend:
it actually just occurred to me that if you have an external hub that allows devices to charge from the machine via the USB power rail, that it may be the culprit due to the fact that it needs an active power supply.
Thanks everybody!
I’ll try everything you suggested.
Still, when I disabled the usb devices via powertop, the system seemed to go in suspend state - only for not waking up (or, at least, not waking up the monitor - but the journals indicated it was not really waking up)… this not waking up seems really strange to me. I wonder if it is necessarily linked to the failing suspend issue or if it is a different problem alltogether.
definitely a software issue, my guess is that it’s not keeping an eye on your keyboard or mouse for inputs to wake up.
i have a similar issue as my keyboard buttons will not wake my sleeping system, but i can wake it via a mouse click instead.
i didn’t see my particular manifestation as a problem issue, i saw it as a variance in function so i never bothered to file a report.
Enabled Wake status for USB device 1-1.1
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Enabled Wake status for USB device 1-1.3
Bus 001 Device 003: ID 046d:c52b Logitech, Inc. Unifying Receiver
Accordingly, the two devices preventing a proper suspend/hibernate are a USB root hub and your Logitech Unifying Receiver (dongle for Logitech G604 Wireless Gaming Mouse).
Remove your Logitech Unifying Receiver and Logitech G604 Wireless Gaming Mouse from your system. Replace your mouse with an old wired PS2 mouse (preferred) or a wired USB mouse for troubleshooting purposes.
Unfortunately, from my past experiences writing services I was never able to fix this problem with a service when a root hub on the mobo was the offending device. Perhaps a udev rule might be more successful with this, however I haven’t written enough udev rules to even guess if it’s possible. As a further troubleshooting step you should also remove any external USB hub to eliminate it as a possible cause.
Sorry, but this type of issue with a root hub is often only fixed by a change in the bios, kernel, or firmware.
They are much more experienced than me.