Suspend not working on Linux Mint 22.1 XFCE 4.18?

dbaser · 2025-08-12 18:00:26

Just testing something and discovered that if I run this command:

$ systemctl suspend

in terminal, monitors go black as if the system is entering suspend and then it just wakes itself back up again?

My system LEDs should go off during suspend (according to my UEFI settings) but they never go out.

ToZ · 2025-08-12 21:33:18

What does your journal say after you try this?

sudo journalctl -b 0 | grep systemd-sleep

dbaser · 2025-08-13 19:14:18

Looks like it suspends then wakes up but I don't understand the rest of the output:

$ sudo journalctl -b 0 | grep systemd-sleep
Aug 12 13:57:31 TARS systemd-sleep[3803538]: Performing sleep operation 'suspend'...
Aug 12 13:57:41 TARS systemd-sleep[3803538]: System returned from sleep operation 'suspend'.
Aug 12 13:57:41 TARS systemd-sleep[3803720]: /dev/sda:
Aug 12 13:57:41 TARS systemd-sleep[3803720]:  setting Advanced Power Management level to 0xfe (254)
Aug 12 13:57:41 TARS systemd-sleep[3803720]:  APM_level        = 254
Aug 12 13:57:41 TARS systemd-sleep[3803738]: /dev/sdb:
Aug 12 13:57:41 TARS systemd-sleep[3803738]:  setting Advanced Power Management level to 0xfe (254)
Aug 12 13:57:41 TARS systemd-sleep[3803738]:  APM_level        = off
Aug 12 13:57:41 TARS systemd-sleep[3803757]: /dev/sdc:
Aug 12 13:57:41 TARS systemd-sleep[3803757]:  setting Advanced Power Management level to 0xfe (254)
Aug 12 13:57:41 TARS systemd-sleep[3803757]:  APM_level        = 254

ToZ · 2025-08-13 19:18:43

Not much there. Can you post back the full log entry after you have tried a suspend?

sudo journalctl -b 0 --no-pager

dbaser · 2025-08-14 04:53:35

Sure this is the full log right after I ran 'systemctl suspend':

https://termbin.com/3hoi

ToZ · 2025-08-14 10:09:55

Whats strange about this log output is it doesn't contain any systemd-sleep entries like from your previous post.

Can you try:

sudo journalctl -b -1 --no-pager

...and:

sudo journalctl -b -2 --no-pager

...and so on until you get a log file that includes systemd-sleep entries and then post that log file back?

dbaser · 2025-08-14 18:14:22

I think that's because of the problem, right? It doesn't suspend. The only time it even tries is when I try to do it manually, hence:

$ sudo journalctl -b -1 | grep systemd-sleep
Aug 12 13:57:31 TARS systemd-sleep[3803538]: Performing sleep operation 'suspend'...
Aug 12 13:57:41 TARS systemd-sleep[3803538]: System returned from sleep operation 'suspend'.
Aug 12 13:57:41 TARS systemd-sleep[3803720]: /dev/sda:
Aug 12 13:57:41 TARS systemd-sleep[3803720]:  setting Advanced Power Management level to 0xfe (254)
Aug 12 13:57:41 TARS systemd-sleep[3803720]:  APM_level        = 254
Aug 12 13:57:41 TARS systemd-sleep[3803738]: /dev/sdb:
Aug 12 13:57:41 TARS systemd-sleep[3803738]:  setting Advanced Power Management level to 0xfe (254)
Aug 12 13:57:41 TARS systemd-sleep[3803738]:  APM_level        = off
Aug 12 13:57:41 TARS systemd-sleep[3803757]: /dev/sdc:
Aug 12 13:57:41 TARS systemd-sleep[3803757]:  setting Advanced Power Management level to 0xfe (254)
Aug 12 13:57:41 TARS systemd-sleep[3803757]:  APM_level        = 254
Aug 14 00:48:16 TARS systemd-sleep[1420604]: Performing sleep operation 'suspend'...
Aug 14 00:48:26 TARS systemd-sleep[1420604]: System returned from sleep operation 'suspend'.
Aug 14 00:48:26 TARS systemd-sleep[1420762]: /dev/sda:
Aug 14 00:48:26 TARS systemd-sleep[1420762]:  setting Advanced Power Management level to 0xfe (254)
Aug 14 00:48:26 TARS systemd-sleep[1420762]:  APM_level        = 254
Aug 14 00:48:26 TARS systemd-sleep[1420779]: /dev/sdb:
Aug 14 00:48:26 TARS systemd-sleep[1420779]:  setting Advanced Power Management level to 0xfe (254)
Aug 14 00:48:26 TARS systemd-sleep[1420779]:  APM_level        = off
Aug 14 00:48:26 TARS systemd-sleep[1420796]: /dev/sdc:
Aug 14 00:48:26 TARS systemd-sleep[1420796]:  setting Advanced Power Management level to 0xfe (254)
Aug 14 00:48:26 TARS systemd-sleep[1420796]:  APM_level        = 254

No output for these commands:

$ sudo journalctl -b -2 | grep systemd-sleep
$ sudo journalctl -b -3 | grep systemd-sleep
$ sudo journalctl -b -4 | grep systemd-sleep
$ sudo journalctl -b -5 | grep systemd-sleep
$ sudo journalctl -b -6 | grep systemd-sleep

ToZ · 2025-08-14 22:30:33

That is a strange one. Going to throw a couple of things out there:

cat /etc/systemd/sleep.conf

...and:

ls /etc/systemd/sleep.conf.d/

...and see if there is a file in there that disables sleep.

sudo systemctl status systemd-suspend.service

...after a suspend attempt.

dbaser · 2025-08-17 04:28:58

Ok here is the output for the first command:

$ cat /etc/systemd/sleep.conf
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file (or a copy of it placed in
# /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/sleep.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/sleep.conf' to display the full config.
#
# See systemd-sleep.conf(5) for details.

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateDelaySec=
#SuspendEstimationSec=60min

Output for the second command is that the directory doesn't exist:

$ ls /etc/systemd/sleep.conf.d/
ls: cannot access '/etc/systemd/sleep.conf.d/': No such file or directory

For the last one, I attempted to suspend:

$ systemctl suspend

After monitors go black and then come back on, I ran your command:

$ sudo systemctl status systemd-suspend.service
○ systemd-suspend.service - System Suspend
     Loaded: loaded (/usr/lib/systemd/system/systemd-suspend.service; static)
     Active: inactive (dead) since Sun 2025-08-17 00:25:52 EDT; 17s ago
       Docs: man:systemd-suspend.service(8)
    Process: 3544503 ExecStart=/usr/lib/systemd/systemd-sleep suspend (code=exited, status=0/SUCCESS)
   Main PID: 3544503 (code=exited, status=0/SUCCESS)
        CPU: 800ms

Aug 17 00:25:52 TARS systemd-sleep[3544642]:  setting Advanced Power Management level to 0xfe (254)
Aug 17 00:25:52 TARS systemd-sleep[3544642]:  APM_level        = 254
Aug 17 00:25:52 TARS systemd-sleep[3544659]: /dev/sdb:
Aug 17 00:25:52 TARS systemd-sleep[3544659]:  setting Advanced Power Management level to 0xfe (254)
Aug 17 00:25:52 TARS systemd-sleep[3544659]:  APM_level        = off
Aug 17 00:25:52 TARS systemd-sleep[3544690]: /dev/sdc:
Aug 17 00:25:52 TARS systemd-sleep[3544690]:  setting Advanced Power Management level to 0xfe (254)
Aug 17 00:25:52 TARS systemd-sleep[3544690]:  APM_level        = 254
Aug 17 00:25:52 TARS systemd[1]: systemd-suspend.service: Deactivated successfully.
Aug 17 00:25:52 TARS systemd[1]: Finished systemd-suspend.service - System Suspend.

ToZ · 2025-08-17 11:02:20

Can I see the full journal log for a boot that has a "Performing sleep operation 'suspend'..." entry?

Also, post back the output of:

sudo cat /sys/kernel/debug/suspend_stats

dbaser · 2025-08-17 22:38:01

ToZ wrote:

Can I see the full journal log for a boot that has a "Performing sleep operation 'suspend'..." entry?

Sure, I checked with grep to make sure:

$ journalctl -b 0 | grep -i performing
Aug 17 00:25:44 TARS systemd-sleep[3544503]: Performing sleep operation 'suspend'...

And I generated like this:

$ journalctl -b 0 | nc termbin.com 9999

Result:
https://termbin.com/tf8i

ToZ wrote:

Also, post back the output of:
sudo cat /sys/kernel/debug/suspend_stats

Ok here you go (output ends with a blank line if you couldn't tell):

$ sudo cat /sys/kernel/debug/suspend_stats
success: 1
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume_noirq: 0
failed_resume_early: 0
failed_resume: 0
failures:
  last_failed_dev:	
			
  last_failed_errno:	0
			0
  last_failed_step:

ToZ · 2025-08-17 22:56:18

dbaser wrote:

Sure, I checked with grep to make sure:
$ journalctl -b 0 | grep -i performing
Aug 17 00:25:44 TARS systemd-sleep[3544503]: Performing sleep operation 'suspend'...
And I generated like this:
$ journalctl -b 0 | nc termbin.com 9999
Result:
https://termbin.com/tf8i

But this file doesn't have that entry in it. It stops at "Aug 15 08:36:34"

$ sudo cat /sys/kernel/debug/suspend_stats
success: 1
fail: 0
failed_freeze: 0
failed_prepare: 0
failed_suspend: 0
failed_suspend_late: 0
failed_suspend_noirq: 0
failed_resume_noirq: 0
failed_resume_early: 0
failed_resume: 0
failures:
  last_failed_dev:	
			
  last_failed_errno:	0
			0
  last_failed_step:

No failures - this is confusing. Maybe my initial assumption that suspend is broken is wrong - your system suspends but wakes up right away. Have a look at your wakeup triggers. There is a troubleshooting section on that page that shows you how to disable triggers - see if you can find the culprit.

dbaser · 2025-08-17 23:40:29

ToZ wrote:

dbaser wrote:
Sure, I checked with grep to make sure:
$ journalctl -b 0 | grep -i performing
Aug 17 00:25:44 TARS systemd-sleep[3544503]: Performing sleep operation 'suspend'...
And I generated like this:
$ journalctl -b 0 | nc termbin.com 9999
Result:
https://termbin.com/tf8i
But this file doesn't have that entry in it. It stops at "Aug 15 08:36:34"

What the?... How is that even possible? I just tried with "--no-pager" also but it's the same thing. sigh This system is fucked.

ToZ wrote:

No failures - this is confusing.

It's my cursed system lol So many problems and no one can figure them out.

ToZ wrote:

Maybe my initial assumption that suspend is broken is wrong - your system suspends but wakes up right away. Have a look at your wakeup triggers. There is a troubleshooting section on that page that shows you how to disable triggers - see if you can find the culprit.

Ok I'll look into this, thanks. And do you know of any other commands to get you the full log?

... I am so thoroughly and completely confused right now. I remembered that zero is current boot. So I thought if I restart, then maybe it would produce the full log for you. Now look what happens:

$ journalctl -b 0 | grep -i performing
$ journalctl -b 1 | grep -i performing
Jul 11 01:06:30 TARS mullvad-daemon[1480]: [mullvad_daemon::management_interface][DEBUG] is_performing_post_upgrade
$ journalctl -b 2 | grep -i performing
Jul 11 03:52:28 TARS mullvad-daemon[1522]: [mullvad_daemon::management_interface][DEBUG] is_performing_post_upgrade

WTF??? My LOGS don't even work properly? So now the line from August 17th is GONE??????

I will never understand this shit in a million years.

Last edited by dbaser (2025-08-18 00:02:29)

ToZ · 2025-08-18 00:38:14

I feel for you. Sometimes things like this just happen.

Try the wakeup things - disabling one at a time until you (hopefully) you find the culprit.

dbaser · 2025-08-18 00:48:05

Well this is interesting. The troubleshooting section you linked says to run the command below and that 'The relevant devices are EHC1, EHC2 and XHC (for USB 3.0)':

$ cat /proc/acpi/wakeup
Device	S-state	  Status   Sysfs node
GP12	  S4	*enabled   pci:0000:00:07.1
GP13	  S4	*enabled   pci:0000:00:08.1
XHC0	  S4	*enabled   pci:0000:0c:00.3
GP30	  S4	*disabled
GP31	  S4	*disabled
PS2K	  S3	*disabled
GPP0	  S4	*enabled   pci:0000:00:01.1
GPP8	  S4	*enabled   pci:0000:00:03.1
SWUS	  S4	*enabled   pci:0000:08:00.0
SWDS	  S4	*enabled   pci:0000:09:00.0
PTXH	  S4	*enabled   pci:0000:02:00.0
PT20	  S4	*enabled   pci:0000:03:00.0
PT21	  S4	*disabled
PT22	  S4	*disabled
PT23	  S4	*disabled
PT24	  S4	*disabled
PT26	  S4	*disabled
PT27	  S4	*disabled
PT28	  S4	*enabled   pci:0000:03:08.0
PT29	  S4	*enabled   pci:0000:03:09.0

So I have no EHC1, EHC2 or XHC. I only have one called XHC0. However, the next part makes me think I've found the general culprit:

3.3.2 Gigabyte motherboards
3.3.2.1 GPP bridge
On some Gigabyte motherboards, the GPP bridge to the NVMe drive may cause premature wakeups from suspend.
Known boards affected:
B550i AORUS,
B550 AORUS ELITE V2,
B550 AORUS ELITE AX V2 (Rev. 1.5),
B550M DS3H
B550M AORUS PRO-P

My motherboard is a B550 AORUS ELITE AX V2 (Rev 1.3), so not one of the ones listed but pretty close.

The section goes on to say:

Setting the status of GPP0 to disabled may fix the issue:
# echo GPP0 > /proc/acpi/wakeup

So I tried it and ...

$ echo GPP0 > /proc/acpi/wakeup
bash: /proc/acpi/wakeup: Permission denied
$ sudo echo GPP0 > /proc/acpi/wakeup
bash: /proc/acpi/wakeup: Permission denied

roll For the love of god... It never ends.

Last edited by dbaser (2025-08-18 00:50:59)

ToZ · 2025-08-18 01:02:26

Try:

echo GPP0 | sudo tee /proc/acpi/wakeup

...or run the command as root. You need elevated privileges.

dbaser · 2025-08-18 02:07:31

ToZ wrote:

Try:
echo GPP0 | sudo tee /proc/acpi/wakeup
...or run the command as root. You need elevated privileges.

Oh. my. god. This is the first time I've been able to suspend the system since I built this PC!

I ran your command, put in my password, then tried 'systemctl suspend' again and... Monitors went black (that always happens), BUT,,, then the keyboard LEDs went out, then the PC LEDs went out! I waited a few seconds and it didn't wake back up! I think this totally worked! No idea what the hell 'GPP0' is but it works! Thank you!

Added later 15 min 36 s:

ToZ wrote:

...or run the command as root. You need elevated privileges.

I thought that's what 'sudo' does?

Your command worked, but it doesn't work to make the setting permanent as described here:
https://bbs.archlinux.org/viewtopic.php … 7#p2004037

If I use 'echo GPP0 | sudo tee /proc/acpi/wakeup' for the 'ExecStart' value, it throws these errors:

Aug 17 22:16:29 TARS systemd[1]: /etc/systemd/system/wakeup-disable_GPP0.service:5: Neither a valid executable name nor an absolute path: echo GPP0 | sudo tee /proc/acpi/wakeup
Aug 17 22:16:29 TARS systemd[1]: wakeup-disable_GPP0.service: Unit configuration has fatal error, unit will not be started.

Last edited by dbaser (2025-08-18 02:08:02)

ToZ · 2025-08-18 12:45:58

If it's a system service file (which it should be), then you won't need to use sudo. In which case:

echo GPP0 > /proc/acpi/wakeup

The other systemd way of doing this it to use tmpfiles (which will disable on every boot).

Create the file /etc/tmpfiles.d/fix_suspend.conf (need root privileges).
Add in the following content:
```
w+   /proc/acpi/wakeup     -    -    -    -   GPP0
```
...note the 4 space-separated dashes, they are important.
Apply the changes:
```
sudo systemd-tmpfiles --create
```

dbaser · 2025-08-19 16:42:43

Ok I think it worked, I used this command of yours:

echo GPP0 > /proc/acpi/wakeup

So service looks like this:

$ cat /etc/systemd/system/wakeup-disable_GPP0.service 
[Unit]
Description=Fix suspend by disabling GPP0 sleepstate thingie

[Service]
ExecStart=echo GPP0 > /proc/acpi/wakeup

[Install]
WantedBy=multi-user.target

Here is me suspending manually with the 'systemctl suspend' command and then waking the system with the mouse:

$ journalctl -b | grep suspend
Aug 19 11:44:58 TARS systemd-logind[1255]: The system will suspend now!
Aug 19 11:44:58 TARS lact[1960]: 2025-08-19T15:44:58.870058Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
Aug 19 11:44:58 TARS ModemManager[1409]: <msg> [sleep-monitor-systemd] system is about to suspend
Aug 19 11:44:59 TARS systemd[1]: Starting systemd-suspend.service - System Suspend...
Aug 19 11:44:59 TARS systemd-sleep[667478]: Performing sleep operation 'suspend'...
Aug 19 11:44:59 TARS kernel: PM: suspend entry (deep)
Aug 19 11:45:07 TARS kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 19 11:45:07 TARS kernel: PM: suspend exit
Aug 19 11:45:07 TARS systemd-sleep[667478]: System returned from sleep operation 'suspend'.
Aug 19 11:45:07 TARS systemd[1]: systemd-suspend.service: Deactivated successfully.
Aug 19 11:45:07 TARS systemd[1]: Finished systemd-suspend.service - System Suspend.
Aug 19 11:45:07 TARS systemd[1]: Reached target suspend.target - Suspend.
Aug 19 11:45:07 TARS systemd-logind[1255]: Operation 'suspend' finished.
Aug 19 11:45:07 TARS lact[1960]: 2025-08-19T15:45:07.599495Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
Aug 19 11:45:07 TARS systemd[1]: Stopped target suspend.target - Suspend.
Aug 19 11:46:52 TARS systemd-logind[1255]: The system will suspend now!
Aug 19 11:46:52 TARS lact[1960]: 2025-08-19T15:46:52.745656Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
Aug 19 11:46:52 TARS ModemManager[1409]: <msg> [sleep-monitor-systemd] system is about to suspend
Aug 19 11:46:52 TARS systemd[1]: Starting systemd-suspend.service - System Suspend...
Aug 19 11:46:52 TARS systemd-sleep[670001]: Performing sleep operation 'suspend'...
Aug 19 11:46:52 TARS kernel: PM: suspend entry (deep)
Aug 19 11:47:21 TARS kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 19 11:47:21 TARS kernel: PM: suspend exit
Aug 19 11:47:21 TARS systemd-sleep[670001]: System returned from sleep operation 'suspend'.
Aug 19 11:47:24 TARS systemd[1]: systemd-suspend.service: Deactivated successfully.
Aug 19 11:47:24 TARS systemd[1]: Finished systemd-suspend.service - System Suspend.
Aug 19 11:47:24 TARS systemd[1]: Reached target suspend.target - Suspend.
Aug 19 11:47:24 TARS systemd-logind[1255]: Operation 'suspend' finished.
Aug 19 11:47:24 TARS lact[1960]: 2025-08-19T15:47:24.453373Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
Aug 19 11:47:24 TARS systemd[1]: Stopped target suspend.target - Suspend.

I then set Power Manager to suspend to lock screen after 15 minutes of inactivity:

15 minutes later it suspends itself at 12:03 and I wake the system with the mouse at 12:23:

Aug 19 12:03:02 TARS systemd-logind[1255]: The system will suspend now!
Aug 19 12:03:02 TARS lact[1960]: 2025-08-19T16:03:02.614363Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
Aug 19 12:03:02 TARS ModemManager[1409]: <msg> [sleep-monitor-systemd] system is about to suspend
Aug 19 12:03:02 TARS systemd[1]: Starting systemd-suspend.service - System Suspend...
Aug 19 12:03:02 TARS systemd-sleep[682306]: Performing sleep operation 'suspend'...
Aug 19 12:03:02 TARS kernel: PM: suspend entry (deep)
Aug 19 12:23:49 TARS kernel: printk: Suspending console(s) (use no_console_suspend to debug)
Aug 19 12:23:49 TARS kernel: PM: suspend exit
Aug 19 12:23:49 TARS systemd-sleep[682306]: System returned from sleep operation 'suspend'.
Aug 19 12:23:52 TARS systemd[1]: systemd-suspend.service: Deactivated successfully.
Aug 19 12:23:52 TARS systemd[1]: Finished systemd-suspend.service - System Suspend.
Aug 19 12:23:52 TARS systemd[1]: Reached target suspend.target - Suspend.
Aug 19 12:23:52 TARS systemd-logind[1255]: Operation 'suspend' finished.
Aug 19 12:23:52 TARS lact[1960]: 2025-08-19T16:23:52.621201Z  INFO lact_daemon::suspend: suspend/resume event detected, reloading config
Aug 19 12:23:52 TARS systemd[1]: Stopped target suspend.target - Suspend.

Does this look ok? Looks good to me!

ToZ · 2025-08-19 20:27:36

Looks great. Thanks for sharing the final result.

dbaser · 2025-08-21 00:24:57

I spoke too spoon lol This goddamn thing keeps re-enabling itself. Is there anyway to disable this permanently?

I didn't symlink it to anything but I just noticed all the other systemd services in '/etc/systemd/system/' are symlinks. Is that why it's not working?

Last edited by dbaser (2025-08-21 00:58:40)

ToZ · 2025-08-21 02:35:10

Try the systemd-tmpfiles approach I noted above in post #18.

dbaser · Yesterday 20:07:28

Hi, I managed to get the systemd service working. It was a lock screen setting screwing it up.

Thanks for the tmpfiles info though, I have never heard of doing it that way before and have made note of it.

And thanks again for solving this problem for me!

Xfce Forum

Sub domains

#1 2025-08-12 18:00:26

Suspend not working on Linux Mint 22.1 XFCE 4.18?

#2 2025-08-12 21:33:18

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#3 2025-08-13 19:14:18

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#4 2025-08-13 19:18:43

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#5 2025-08-14 04:53:35

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#6 2025-08-14 10:09:55

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#7 2025-08-14 18:14:22

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#8 2025-08-14 22:30:33

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#9 2025-08-17 04:28:58

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#10 2025-08-17 11:02:20

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#11 2025-08-17 22:38:01

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#12 2025-08-17 22:56:18

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#13 2025-08-17 23:40:29

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#14 2025-08-18 00:38:14

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#15 2025-08-18 00:48:05

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#16 2025-08-18 01:02:26

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#17 2025-08-18 02:07:31

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#18 2025-08-18 12:45:58

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#19 2025-08-19 16:42:43

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#20 2025-08-19 20:27:36

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#21 2025-08-21 00:24:57

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#22 2025-08-21 02:35:10

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

#23 Yesterday 20:07:28

Re: Suspend not working on Linux Mint 22.1 XFCE 4.18?

Board footer