Persistent sleep/standby impossibility is slowly pushing me away

Hi there Garuda people,

shortly after having installed Garuda, I wrote a post that became a very long thread about my impossibility to put the system in standby/sleep status.
Here is the original thread: Suspend/sleep not working - #107 by Ezahn
Thanks again and again to everybody that contributed! :pray:

I tried everyting, nothing worked, and then continued to search online for solutions that never worked (es. puttinc ACPI parameters in the kernel parameters).
At the time I even created a 16gb SWAP partition that never let me hybernate the system. And now, since many updates, I do not even see the hybernate option anymore.

After all those tries I just kept constantly updating the system with garuda-update, hoping that a new kernel or a new something would have fixed my sleep issues (at the time of my test live-usb it was working!): but no, nothing changed for the best until now.

Basically now:

  1. I’d like to remove the useless SWAP partition to reclaim space withou breaking anything;
  2. I’d like to know if it is worth it to keep trying and updating or If I must simply accept that my system will never sleep with Garuda (I’m dual booting and in W10 sleeps works); if that’s the case I will be forced to try another distro, even if I would really prefer to stay with Garuda, I’m loving it overall. :unamused:

To make matters worse, at least one of my fans keep spinning constantly even when the PC is completely idle (in W10 as weel, that’s always been a problem, maybe it was assembled incorrectly) so not having a working sleep mode means hearing a fan all day long… ^^

Here’s my actual inxi, btw:

Kernel: 6.7.6-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc avail: hpet,acpi_pm
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=1930b164-e875-487b-9e15-d08dfb606021 rw rootflags=subvol=@
quiet quiet rd.udev.log_priority=3 vt.global_cursor_default=0 loglevel=3
ibt=off resume=UUID=290da5e7-6510-4b46-9fa1-14463cba09cf
Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 info: frameworks
v: 5.115.0 wm: kwin_x11 vt: 2 dm: SDDM Distro: Arch Linux
Type: Desktop Mobo: ASRock model: P67 Extreme4 serial: <superuser required>
uuid: <superuser required> BIOS: American Megatrends v: P3.10
date: 04/24/2012
Device-1: hidpp_battery_0 model: Logitech G604 Wireless Gaming Mouse
serial: <filter> charge: 100% (should be ignored) rechargeable: yes
status: discharging
Info: model: Intel Core i5-2500K bits: 64 type: MCP arch: Sandy Bridge
gen: core 2 level: v2 built: 2010-12 process: Intel 32nm family: 6
model-id: 0x2A (42) stepping: 7 microcode: 0x2F
Topology: cpus: 1x cores: 4 smt: <unsupported> cache: L1: 256 KiB
desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB L3: 6 MiB
desc: 1x6 MiB
Speed (MHz): avg: 1598 high: 1600 min/max: 1600/5900 scaling:
driver: intel_cpufreq governor: schedutil cores: 1: 1600 2: 1600 3: 1596
4: 1596 bogomips: 26341
Flags: avx ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities: <filter>
Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: ZOTAC driver: nvidia
v: 545.29.06 alternate: nouveau,nvidia_drm non-free: 545.xx+ status: current
(as of 2024-02; EOL~2026-12-xx) arch: Maxwell code: GMxxx
process: TSMC 28nm built: 2014-2019 pcie: gen: 2 speed: 5 GT/s lanes: 16
ports: active: none off: DP-1,DVI-I-1 empty: DVI-D-1,HDMI-A-1
bus-ID: 01:00.0 chip-ID: 10de:13c2 class-ID: 0300
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.4
compositor: kwin_x11 driver: X: loaded: nvidia unloaded: modesetting
alternate: fbdev,nouveau,nv,vesa gpu: nvidia,nvidia-nvswitch
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 97 s-size: 503x283mm (19.80x11.14")
s-diag: 577mm (22.72")
Monitor-1: DP-1 note: disabled model: Panasonic Panasonic-TV
serial: <filter> built: 2010 res: 1920x1080 dpi: 70 gamma: 1.2
size: 698x392mm (27.48x15.43") modes: max: 1920x1080 min: 640x480
Monitor-2: DVI-I-1 note: disabled pos: primary model: LG (GoldStar) W2363D
serial: <filter> built: 2011 res: 1920x1080 dpi: 96 gamma: 1.2
size: 510x287mm (20.08x11.3") diag: 582mm (22.9") ratio: 16:9 modes:
max: 1920x1080 min: 640x480
API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 2
drv: swrast gbm: drv: nvidia surfaceless: drv: nvidia x11: drv: nvidia
inactive: wayland,device-1
API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 545.29.06
glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
memory: 3.91 GiB
API: Vulkan v: 1.3.276 layers: 5 device: 0 type: discrete-gpu
name: NVIDIA GeForce GTX 970 driver: nvidia v: 545.29.06
device-ID: 10de:13c2 surfaces: xcb,xlib
Device-1: Intel 6 Series/C200 Series Family High Definition Audio
vendor: ASRock 6 driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
chip-ID: 8086:1c20 class-ID: 0403
Device-2: NVIDIA GM204 High Definition Audio vendor: ZOTAC
driver: snd_hda_intel v: kernel pcie: gen: 2 speed: 5 GT/s lanes: 16
bus-ID: 01:00.1 chip-ID: 10de:0fbb class-ID: 0403
Device-3: M-Audio AIR 192 6 driver: snd-usb-audio type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-1.5:3 chip-ID: 0763:410c
class-ID: fe01
Device-4: Logitech G430 Surround Sound Gaming Headset
driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
lanes: 1 mode: 1.1 bus-ID: 2-1.2:4 chip-ID: 046d:0a4d class-ID: 0300
API: ALSA v: k6.7.6-zen1-1-zen status: kernel-api with: aoss
type: oss-emulator tools: N/A
Server-1: PipeWire v: 1.0.3 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: ASRock driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1
port: b000 bus-ID: 0c:00.0 chip-ID: 10ec:8168 class-ID: 0200
IF: enp12s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Device-2: Realtek RTL88x2bu [AC1200 Techkey] driver: rtw_8822bu type: USB
rev: 2.1 speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-2.2:3
chip-ID: 0bda:b812 class-ID: 0000 serial: <filter>
IF: wlp4s0u2u2 state: down mac: <filter>
Info: services: NetworkManager, systemd-timesyncd, wpa_supplicant
Device-1: Cambridge Silicon Radio Bluetooth Dongle (HCI mode) driver: btusb
v: 0.8 type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-1.6:4
chip-ID: 0a12:0001 class-ID: e001
Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 4.0
lmp-v: 6 status: discoverable: no pairing: no class-ID: 6c0104
Local Storage: total: 2.85 TiB used: 610.9 GiB (21.0%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 1TB
size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
tech: SSD serial: <filter> fw-rev: 3B6Q scheme: MBR
ID-2: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST2000DX001-1NS164
size: 1.82 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
tech: HDD rpm: 7200 serial: <filter> fw-rev: CC41 scheme: MBR
ID-3: /dev/sdc maj-min: 8:32 vendor: Crucial model: M4-CT128M4SSD2
size: 119.24 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
tech: SSD serial: <filter> fw-rev: 070H scheme: MBR
ID-1: / raw-size: 50 GiB size: 46.57 GiB (93.13%) used: 26.72 GiB (57.4%)
fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-2: /home raw-size: 414.91 GiB size: 414.91 GiB (100.00%)
used: 155.38 GiB (37.5%) fs: btrfs dev: /dev/sda3 maj-min: 8:3
ID-3: /var/log raw-size: 50 GiB size: 46.57 GiB (93.13%)
used: 26.72 GiB (57.4%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
ID-4: /var/tmp raw-size: 50 GiB size: 46.57 GiB (93.13%)
used: 26.72 GiB (57.4%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 15.58 GiB used: 0 KiB (0.0%) priority: 100
comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 4 dev: /dev/zram0
ID-2: swap-2 type: partition size: 16.6 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/sda4 maj-min: 8:4
System Temperatures: cpu: 42.0 C mobo: N/A gpu: nvidia temp: 37 C
Fan Speeds (rpm): N/A gpu: nvidia fan: 32%
Memory: total: 16 GiB available: 15.58 GiB used: 7.67 GiB (49.2%)
Processes: 273 Power: uptime: 1h 12m states: freeze,standby,mem,disk
suspend: deep avail: s2idle,shallow wakeups: 0 hibernate: platform
avail: shutdown, reboot, suspend, test_resume image: 6.17 GiB
services: org_kde_powerdevil, power-profiles-daemon, upowerd Init: systemd
v: 255 default: graphical tool: systemctl
Packages: pm: pacman pkgs: 1493 libs: 489 tools: octopi,paru Compilers:
clang: 16.0.6 gcc: 13.2.1 Shell: garuda-inxi default: Bash v: 5.2.26
running-in: konsole inxi: 3.3.33
Garuda (2.6.23-1):
System install date:     2024-01-27
Last full system update: 2024-02-25
Is partially upgraded:   No
Relevant software:       snapper NetworkManager dracut nvidia-dkms
Windows dual boot:       <superuser required>
Failed units:

Thanks for everything!

Just an update: I updated and tried again to boot in the LTS kernel but results are exactly the same. :frowning:

Perhaps you are not a native English speaker @Ezahn, and maybe this was responsible for your poor wording in your title. Perhaps no one has responded to your request because they perceive your thread title to be a veiled threat. To many people, your request may simply come off as “Help me, or I’m leaving Garuda”. It generally doesn’t predispose a lot of forum assistants to render aid when an ultimatum is perceived.

Looking at your inxi, it would seem from the age of your computer you may not have a lot of options to run a dozen+ year old system on a modern OS. Will Windows 11 even run on a system this old. I haven’t run Windows since Windows 7, but I’m doubting you could even run a modern version of Windows on a system this old.

Have you tested other Linux distributions?

Does your system work properly on other Linux distributions? If not, you’ve probably got your work cut out for you to find a fix.

Generally, the kernel and the bios are the two biggest factors affecting a Linux computer’s ability to suspend.

Are you running the most recent version of your bios available?

The old single core Sandy Bridge models are well known for having suspend problems in Linux.

To possibly find a solution, my suggestion would be to run the following search parameters in your favorite search engine:

“Linux Sandy Bridge” suspend not working

“Linux Sandy Bridge” sleep not working

“Arch Linux Sandy Bridge” suspend not working

“Arch Linux Sandy Bridge” sleep not working

Good luck finding a fix.


Do a search yes they were plagued with problems on windows let alone Linux. maybe time to invest in some new gear or just put up with its downfall.


Hi @tbg (and hi @mandog), you got it right, I’m not a native spaker at all and I can assure you the last thing I wanted was to sound menacing. :blush: :smiling_face_with_tear:
I’m really sorry about that.

Yeah, I know this PC is on its last leg, I’m just trying to squeeze out all it can give before caving in and spend for a new build - or a new laptop. Windows 11 will absolutely not run on it, but Windows 10 do. A part from the standby problema Garuda has been running great and I really like its “rolling but assisted/simplified” philosophy. I tested other distros via USB sticks and they all seem to go to sleep correctly… but so did Garuda when I tried the live USB!

I think the BIOS version is the latest one, yes, but I’ll definitely try againg and search for Sandy Bridge related possible solutions.

I’ll just leave the now useless SWAP partition alone for now, I really don’t want to mess anything up deleting it (the hybernate option ceased to show up, so I think the partition really is useless atm).

Thanks again to all of you for taking the time and help a noob, I really appreciate it. :slight_smile:

1 Like

Had this problem too years ago on a Sandy Bridge machine. I´m old and lot of time has passed. So I don´t remeber all oft it. But i still have a few old notes.
As root in terminal try
echo 0 > /sys/power/pm_async
and try suspending. If working you need to create a systemd service file to do this always on every boot. Hope it will do the trick for you.


Thank you @Apocalypticus!
I tried, but unfortunately:

╭─ezahn@EzaRuda in ~ took 6ms
[🔴] × sudo echo 0 > /sys/power/pm_async
warning: An error occurred while redirecting file '/sys/power/pm_async'
open: Permesso negato

Am I making something really noobish here? :thinking:
I doesn’t even ask me for the root password.

Try with su first and then echo 0 > /sys/power/pm_async, when you’re root.


That happens because sudo applies to the echo command, but not the redirection.
The redirection happens first, and the whole command fails.

Either su first as already advised, or echo 0 |sudo tee /sys/power/pm_async
(note, without > redirection: tee takes a file argument)
this way whatever before the | pipe runs as normal user, and tee runs as root.


This did it… as far as the command goes.
But trying to suspend, unfortunately, results in a sort of “freeze” on the login screen, that unfreezes in a minute or so - then I’m able to login again. :unamused:

Tnx for the explanation!

I´m not an expert but maybe it will make a difference doing it in the running system or being started by a systemd service file?

1 Like

I don’t have a clue on how to do this, but I’m sure willing to try if someone kindly show me the way. :pray:

Hopefully I’m not goofing it…

In a new file /etc/systemd/system/pm_async_off.service:

Description=Disable pm_async
ExecStart=/bin/echo 0


systemctl daemon-reload
systemctl enable pm_async_off.service

Gut feeling tells me it won’t make any difference though. And I did not test it.

I also found indication that /sys/power/sync_on_suspend being 0 could cause resume to fail, but on my system it’s 1 so I guess that is the default.
cat /sys/power/sync_on_suspend just in case to confirm.
also, sudo cat /sys/kernel/debug/suspend_stats

The website has debugging tips for Debugging hibernation and suspend and documentation of the /sys/power variables.

P.S. make no mistake, I don’t really know anything, sometimes I’m just lucky at guessing.


Thanks @meanruse.
I tried it but maybe I’m messing something up?

╭─root@EzaRuda in /etc/systemd as 🧙 took 15s
╰─λ ls
drwxr-xr-x    - root 10 apr  2023  network
drwxr-xr-x    - root  1 mar 11:51  system
drwxr-xr-x    - root  1 mag  2023  user
.rw-r--r-- 1,0k root 27 feb 21:38  coredump.conf
.rw-r--r--  890 root 27 feb 21:38  homed.conf
.rw-r--r-- 1,1k root 27 feb 21:38  journal-remote.conf
.rw-r--r-- 1,0k root 27 feb 21:38  journal-upload.conf
.rw-r--r-- 1,4k root 27 feb 21:38  journald.conf
.rw-r--r-- 1,7k root 27 feb 21:38  logind.conf
.rw-r--r-- 1,1k root 27 feb 21:38  networkd.conf
.rw-r--r--  928 root 27 feb 21:38  oomd.conf
.rw-r--r--  140 root  4 mar 08:38  pm_async_off.service
.rw-r--r--  879 root 27 feb 21:38  pstore.conf
.rw-r--r-- 1,7k root 27 feb 21:38  resolved.conf
.rw-r--r-- 1,1k root 27 feb 21:38  sleep.conf
.rw-r--r-- 2,3k root 27 feb 21:38  system.conf
.rw-r--r-- 1,1k root 27 feb 21:38  timesyncd.conf
.rw-r--r-- 1,8k root 27 feb 21:38  user.conf

╭─root@EzaRuda in /etc/systemd as 🧙 took 3ms
╰─λ systemctl daemon-reload

╭─root@EzaRuda in /etc/systemd as 🧙 took 244ms
╰─λ systemctl enable pm_async_off.service
Failed to enable unit: Unit file pm_async_off.service does not exist.

I am not 100% sure my service is correct, and I have not tested it.
It likely makes no difference by what means or at which point in time pm_async is set to zero.
If, after reboot, cat /sys/power/pm_async returns a zero, it means the service unit is working but pm_async is not the solution. If so, it may only be useful as example, if/when some of those variables will be found to allow resume.

Er, I did goof it. Hold on.
The path was wrong, it’s /etc/systemd/system/pm_async_off.service. :man_facepalming:
The service does set pm_async to zero (once put in the right place, reloaded, enabled, and started).

1 Like

I think I did it all and the results are, unfortunately, the same.

╭─ezahn@EzaRuda in /etc/systemd/system🔒
╰─λ cat /sys/power/pm_async
File: /sys/power/pm_async

I also think I now have a second pm_async_off.servicelying around in the system and I don’t know where (I misplaced it trying to mv it from the terminal…). :frowning:
But thanks so much for putting in the effort to help me, @meanruse! :blush: :pray:
Do you think I should remove the two files?

The misplaced file should be inert, but misleading. I advise to find it and remove it.
Or even undo the whole service thing since it doesn’t help.

Meanwhile, I’m chasing rabbits on the documentation and doing some tests on my box.
If you smell something burning and it’s not your lunch, it’s probably my head.
By the way, I can suspend but I just found out I can’t hibernate, which is not really a problem for me but it’s an opportunity to poke around.

Let’s see some info

cat /sys/power/state
cat /sys/power/mem_sleep
cat /sys/power/disk

To clarify: you’re interested in either suspend to RAM or hibernate to disk, right?
Anything that would let you put the machine to rest and resume where you left off?

1 Like

You’re absolutely right, and I don’t even smell anything burning atm. :wink:
I searched for the duplicate file and didn’t find anything if not the original and a symbolic link that I think one of the commands you suggested created.

Here’s the required info:

╭─ezahn@EzaRuda in ~ took 3s
╰─λ cat /sys/power/state
File: /sys/power/state
freeze standby mem disk

╭─ezahn@EzaRuda in ~ took 6s
[🔍] × cat /sys/power/mem_sleep
File: /sys/power/mem_sleep
s2idle shallow [deep]

╭─ezahn@EzaRuda in ~ took 12ms
╰─λ cat /sys/power/disk
File: /sys/power/disk
[platform] shutdown reboot suspend test_resume

Thanks again! :pray:

1 Like

Pretty sure this is related to you using the proprietary nvidia drivers and it’s a bug in the drivers. Alternatively it’s something to do with kde and nvidia drivers not mixing well which is another thing that I have seen being reported in kde bug reports.

1 Like