Suspend/sleep doesn't work

MHWD doesn’t necessarily remove all the relevant configurations (for example, I think it would leave X/Wayland configs intact). More to the point, you now say that you’ve made some changes to the configuration as well, so it could be one of those that’s the culprit.

Maybe check /etc/systemd/sleep.conf and make sure that’s all default? And perhaps test a Manjaro live USB environment to make sure that can suspend successfully. But other than that, I think your choices are to start checking all of your configuration files, or to reinstall. The general advice for massive hardware changes is to reinstall in any case - just because you can transplant a boot drive, doesn’t mean it’s a good idea.

My configuration is mostly limited to user space, but have some very, very small changes in root, like personal grub background.

Basically, the system works as it should and is not generating many issues aside this sleep one.

I checked /etc/systemd/sleep.conf and:

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

Interesting. I have never changed it and suspend worked before. I’ll uncomment #AllowSuspend=yes and let you know how it worked.

EDIT: It didn’t help. In fact, it made it even worse, because earlier, after closing the lid, the system was completely powered off, but now the fans are still spinning.

On the new laptop, my journald errors are even smaller in numbers, so it all seems quite nice, aside to this mysterious suspend issue. I will check live session now.

 michaldybczak  Sirius16-Manjaro  ~  sudo journalctl -b -p3
[sudo] hasło użytkownika michaldybczak: 
lut 15 20:40:45 Sirius16-Manjaro kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.I2CA.TPNL], AE_ALREADY_EXISTS (20230628/dswload2-326)
lut 15 20:40:45 Sirius16-Manjaro kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)
lut 15 20:40:45 Sirius16-Manjaro kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.I2CD.TPDD], AE_ALREADY_EXISTS (20230628/dswload2-326)
lut 15 20:40:45 Sirius16-Manjaro kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)
lut 15 20:40:49 Sirius16-Manjaro bluetoothd[1636]: profiles/audio/bap.c:bap_adapter_probe() BAP requires ISO Socket which is not enabled
lut 15 20:40:49 Sirius16-Manjaro bluetoothd[1636]: bap: Operation not supported (95)
lut 15 20:40:56 Sirius16-Manjaro wpa_supplicant[1078]: bgscan simple: Failed to enable signal strength monitoring
lut 15 20:42:45 Sirius16-Manjaro systemd-networkd-wait-online[737]: Timeout occurred while waiting for network connectivity.
lut 15 20:42:45 Sirius16-Manjaro systemd[1]: Failed to start Wait for Network to be Configured.
lut 15 20:42:45 Sirius16-Manjaro nmbd[32665]: [2024/02/15 20:42:45.886347,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
lut 15 20:42:45 Sirius16-Manjaro nmbd[32665]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.120 for name WORKGROUP<1d>.
lut 15 20:42:45 Sirius16-Manjaro nmbd[32665]:   This response was from IP 192.168.1.104, reporting an IP address of 192.168.1.104.

How often do you see this short error list? :wink:

In Manjaro live I was unable to test suspend, because the default energy settings were set to turn the screen off when the lid is closed and the suspend/sleep option was not available, probably to avoid various issues.

By the way, I forgot to mention, that I disabled TLP for the tests, but it didn’t change a thing. The same issue is with TLP on or off, but for tests I prefer to be off, to avoid complications.

EDIT: Found some clue. Finally got some journald hint:

 michaldybczak  Sirius16-Manjaro  ~  sudo journalctl -b -1 -p3
lut 15 21:03:20 Sirius16-Manjaro (sd-exec-strv)[102977]: /usr/lib/systemd/system-sleep/tlp failed with exit status 1.
lut 15 21:03:20 Sirius16-Manjaro systemd-sleep[102975]: Failed to lock home directories: Unknown object '/org/freedesktop/home1'.

TLP config was disabled, so it shouldn’t generate errors. Weird. Still, because the issue was there regardless of TLP state, I assume this has no consequences. However, the second error looks serious and points out to systemd. That’s a start. Now I need to find some info about it.

I’ve had a similar issue as you, and I have similar hardware (laptop with Ryzen 7 and same gpu and a desktop with Ryzen 9 and similar GPU; both with NVME drives). I have never changed hardware on those systems. This issue first showed up in Kernel 6.2. I bet if you go to the 6.1 LTS kernel you will be fine with resuming after sleep. My non-Ryzen, non-NVME systems don’t have this issue. I have seen some similar issues online where NVME drives may be the culprit, but it seems nobody can pin this down (I haven’t exerted great amounts of energy on it since I have a LTS kernel that still works - eventually I’ll need to move on from 6.1).

Not an answer, but I hope it helps you get in the right direction, I’ll keep watching to see what you can find.

1 Like

Yeah, I’ve just found a bunch of topics, showing similar errors and it turns out, those are some very nasty, hard to detect bugs in drivers and kernel, and only some users (oftentimes with AMD hardware, like me) are affected.

It is said that with firmware 37 with kernel-6.7.4 and kernel-6.8.0-rc3 the issue seems to be fixed. This is why I checked testing branch and the said kernel is there. I’m doing backup right now and then install it, to see if it helped.

And here is the bug report discussing this:

https://superuser.com/questions/1826215/unable-to-shutdown-restart-suspend-linux-system

Unfortunately, upgrading to 6.7.4-2 or using 6.1 kernel are not helping. Seems like something more is going on here for me :frowning:

OK, I think I might have useful information here. My best guess is that Tuxedo has something non-standard about the hardware, because some probing at the Tuxedo website reveals that they recommend users to install their own modifications to any Linux distro they install themselves. The instructions for Manjaro are here, but the instructions boil down to installing their custom stuff with:

pamac install tuxedo-control-center-bin tuxedo-drivers-dkms

The example they give has them using Kernel 6.1, but I hope that this works with a newer kernel than that.

Installing TUXEDO TCC and DKMs was one of the first things I did after moving the disc. To rule out that those are not the culprit as well (TCC is not fully compatible with Sirius model yet), I uninstalled them, rebooted and tried to suspend. Still the same problem, so I restored them back.

Well, in that case I revert to my recommendation of trying a clean install, if at all possible. Perhaps swap back to the Tuxedo OS NVME, install Manjaro on that, check that Suspend works, and then transfer stuff off your current install by using a caddy? Surely if you have both drives visible, transferring stuff should be pretty easy, especially if most of your customizations are in your user.

Otherwise it’s going to be a lot of looking in the dark. I do still think that it may be to do with Tuxedo’s hardware drivers though - perhaps they need to release a new version of their drivers/control center for Manjaro?

TCC is already in newer version here then on TUXEDO OS, ironically. However, it’s still not updated to work fully with Siurius.

As to clean install, it’s never as easy. I have tons of installed packages, so installing it anew would be a huge chore. Then and only then, I could retrieve my home files, and it must be done outside the system, otherwise some configs are overwritten. Then, there are small configuration changes in configs on root, the ones that have no copy on user side, because those work from root anyway. I do compare pacnew with the current configs thanks to pacnew-chaser and meld, so I see, that configs are fairly default, but some small options are enabled - those have no big impact, but are small customizations within the config range (so no extra files and settings).

And oh, there are some extra files like grub background and printer drivers that were installed from AUR many years ago and are not available anymore. I would have to track them down on the disc and copy manually back, because there is no way I could get them back, aside tinkering with deb.

This is all doable, but incredibly tedious thing to do. Moreover, in my experience, after such daunting work, some things still don’t work as good as they should.

Because I didn’t want to pollute the system with old configs, I tried to set things as I want again, but to make some things happen, I had to look at my old notices to find out, how I did it and why. This was another chore, a very irritating one. It would take many weeks to recreate things as I want, so I just gave up and copied my configs.

So the new, theoretically clean installation is not really clean, because of copying of the configs and is inferior, because some things don’t work exactly as they should, and you have another task of debuggung it.

For example, on my old Alienware, on clean Manjaro install multimonitor doesn’t work, period. No matter what I did, how hard tried to restore my settings, it would never budge. No HDMI signal. On my old system, ALL WORKS! Imagine that. I lost a week restoring my system on a clean install and in the end, I had to replace it with the old one anyway,

Clean installs are a myth. I mean, if you are really new and star from scratch, then yes. After using Manjaro for 10 years, I want my system, not a default one. Besides, I never learn anything if I clean install every time I came across any mysterious issue. There is a reason why my Manjaro install is over 9,5 year old. I solved the problems instead of starting things over.

There is also no guarantee that clean install will fix it. I’ll install Manjaro on USB and will try to do suspend test from there, but that may be problematic, because powering USBs is a different thing as internal discs, so it’s not as good test as having it on bare metal. Another thing I can test is to create some small partition for another Manjaro install, but that could lead to some confusions, so that’s risky too.

There are tons of logs in the system, so if there are issues, you can find them somehow, given the right time and knowledge. Time and knowledge is a bit of a problem here.

Clean installs are very much not a myth; they’re certainly useful for fault finding. At the very least, you need to test a clean install, because at the moment we have no way of knowing if your issues are being caused inherently by the switch in hardware or your configuration interacting with the new hardware.

I would also advocate not running the same install for a huge amount of time on security reasons; this isn’t a slight against you, but just an observation that over 10 years there are plenty of security vulnerabilities.

I fail to understand where security risk would be. System is updated, system configs are updated with pacnew configs, kernels are updated and moved to newer ones. Aside of that, I will consider clean install only if I find no solutions to go further.

Clean installation is a huge undertaking and install part is only the beginning. I need to create fresh backups, have list of installed packages, separately from repos, separately from AUR, then have command to install packages from the file, then go to live session, chroot, restore home files, but if those stay, I need to install new packages from chroot, before starting first session. I need to create list of all important modifications and secure files, like drivers that are not in AUR anymore, etc. Some packages need to be configured after installation on root (dynamic swap), etc. Not mentioning ttf packages that won’t install just like that and need to unpack font files from Windows iso… What am I forgetting? Probably a lot.

1 Like

I’m stubborn, so I will give myself some time to figure it out, maybe many weeks, but in the end, clean install test and possibly clean install in general is on the table.

As to security, I’m not sure what you are saying, but I’m not an expert in the matter, so maybe that is why I’m not worrying that much. However, out of curiosity, can you give examples of such persistencies? I always thought that updates should have eliminated vulnerabilities and if the system is constantly updating, there are no persistencies left, at least those really, really bad ones. I am aware that some vulnerabilities are always there, and there is always a battle or choice between security and convenience - you can’t have both, so being at least in the middle, some threats remain. However, those are there if there is a clean install or not, so that is not what you are talking about.

A vulnerability is used by a bad actor to get onto the system. Persistence is obtained by modifying the system to load a payload on boot or similar. A simple way of doing this would be to modify a users startup applications. More complex and harder to detect ways include rootkits, which typically use kernel level functions to make themselves pretty much invisible to the user. For the avoidance of doubt, once the system has been modified by a bad actor for persistence, the bad actor is effectively authorized by the system and no longer needs the vulnerability to control the system. Therefore, patching the vulnerability doesn’t do anything. Here’s a report on Mumblehard, for an example. FritzFrog is another one that can obtain persistence. As is Satori.

Most persistent malware cannot survive a reinstall of the operating system though - this would require a hack of the UEFI or BIOS of the system and having it override the install process, and frankly there are easier targets. Hence, a clean install of an operating system will almost certainly be clean from malware.

As I said, it’s up to you if you consider this a threat. However, from a security point of view it is good practice to do a clean install at least once in a while.

1 Like

Just to add some info:

 michaldybczak  Sirius16-Manjaro  ~  sudo journalctl -b -1 | grep suspend
lut 18 10:55:39 Sirius16-Manjaro kernel: Low-power S0 idle used by default for system suspend
lut 18 10:55:39 Sirius16-Manjaro kernel: nvme 0000:08:00.0: platform quirk: setting simple suspend
lut 18 10:55:39 Sirius16-Manjaro kernel: nvme 0000:04:00.0: platform quirk: setting simple suspend
lut 18 10:56:22 Sirius16-Manjaro systemd-logind[991]: The system will suspend now!
lut 18 10:56:22 Sirius16-Manjaro ModemManager[1057]: <msg> [sleep-monitor-systemd] system is about to suspend
lut 18 10:56:23 Sirius16-Manjaro systemd-sleep[15344]: Performing sleep operation 'suspend'...
 michaldybczak  Sirius16-Manjaro  ~  sudo journalctl -b -1 | grep sleep
lut 18 10:56:22 Sirius16-Manjaro ModemManager[1057]: <msg> [sleep-monitor-systemd] system is about to suspend
lut 18 10:56:22 Sirius16-Manjaro NetworkManager[1023]: <info>  [1708250182.3019] manager: sleep: sleep requested (sleeping: no  enabled: yes)
lut 18 10:56:22 Sirius16-Manjaro NetworkManager[1023]: <info>  [1708250182.3020] device (enp5s0): state change: unavailable -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
lut 18 10:56:22 Sirius16-Manjaro NetworkManager[1023]: <info>  [1708250182.3094] device (p2p-dev-wlp6s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
lut 18 10:56:22 Sirius16-Manjaro NetworkManager[1023]: <info>  [1708250182.3096] device (wlp6s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
lut 18 10:56:22 Sirius16-Manjaro NetworkManager[1023]: <info>  [1708250182.7252] device (wlp6s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
lut 18 10:56:22 Sirius16-Manjaro NetworkManager[1023]: <info>  [1708250182.9094] device (wlp6s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
lut 18 10:56:23 Sirius16-Manjaro systemd[1]: Starting TUXEDO Control Center Service (sleep/resume)...
lut 18 10:56:23 Sirius16-Manjaro systemd[1]: Finished TUXEDO Control Center Service (sleep/resume).
lut 18 10:56:23 Sirius16-Manjaro systemd-sleep[15344]: Performing sleep operation 'suspend'...

It all points that the sleep is working just fine. Waking up is the problem.

Suspend/sleep buttons are available in the system (I was wrong before that they weren’t) and if I close the lid or click on suspend, it just works. Everything powers down, fans stop, backlights stop, everything becomes quiet and power button light starts to fade away very slowly and come back very slowly, indicating sleep.

When I click any key or open a lid (depending on how it was suspended), the power button light wakes up and keep glowing permanently showing awake status, fans start to spin but:

  • no keyboard lights
  • no screen
  • no further reaction to keyboard or any buttons

Only hard reset is solution.

I heard that there is a way to ssh into a computer from another one, to see the logs live. I will research this, but if any of you know any helpful sites about this, let me know. Without seeing logs about what happens during the wake up attempt, it’s hard to find out what is wrong.

By the way, acpid was dead on my system, so I enabled it, but it didn’t change anything. Is acpid process disabled a normal thing?

And from a different side: I know that hibernation and suspend are different things, but terms in usage are mixed up so I checked:

sudo journalctl -b -1 | grep hibernation
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000fffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x09a7f000-0x09ffffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x0a200000-0x0a23bfff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x8b0e8000-0x8b163fff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x8dacf000-0x8dacffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x8f5a6000-0x92103fff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x92104000-0x92190fff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x92191000-0x9720afff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9720b000-0x9ad7bfff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9ad7c000-0x9adfefff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9bff9000-0x9bffcfff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9bfff000-0x9cffffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9d000000-0x9d78ffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9d790000-0x9d7effff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9d7f0000-0x9d7f4fff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0x9d7f5000-0x9fffffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0xa0000000-0xfedfffff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
lut 18 10:55:39 Sirius16-Manjaro kernel: PM: hibernation: Registered nosave memory: [mem 0xfee01000-0xffffffff]

This nosave memory sounds suspicious. Suspend is to memory, but what memory it has in mind? RAM or swap? The time 10:55 suggests suspending, because I wasn’t doing any hibernating, because it doesn’t want to work either and have even no way to attempt it.
EDIT: It seems to be a normal info happening probably on all systems. The kernel marks all memory areas that do not belong to RAM in order to save only the same when suspending to disk.
Dead end here.

This might work with an ethernet cable attached as unless you have disabled screen locking on resume you probably won’t be connected to WiFi.

Does the backlight come on (even with black screen)?

1 Like

Nope, the backlight is off. Only power button light becomes active, and the fans start spinning. Rest seems to be dead. If there are no logs of attempting to wake, the system is not woke at all, aside some peripherals.

Thanks for the tip with the Ethernet cable. Makes sense.

Anyway, if there are no surviving logs, either there are temporary logs that don’t survive hard boot, or the system really won’t try to wake, which means, I won’t get any data even via ssh.

The same suspend method is used on TUXEDO OS, and it works there, but it’s hard to compare because there is no mkinitcpio on Ubuntu systems. I may try to switch to S3, to check if there is a difference, thou.

Or maybe, I should consider switching to systemd boot? That can handle things differently. Or maybe systemd boot is enabled on TUXEDO OS? I have no idea. This is another topic to research.

1 Like

Sorry for delayed response. I guess it wouldn’t hurt to try systemd boot? If it works, please let us know.

NB: I have not looked in to that, might have a play around in a VM to familiarize myself.

I just found out that the problem with existing out of suspension is a known problem of my laptop model. The fix is applied to Tuxedo OS kernel, hence it works well there. This was reported upstream, but it was rejected by AMD, so it’s still in progress of figuring out how to fix it differently.

So there is no point of digging further. I have to wait till it’s fully resolved. Alternatively I could compile kernel with it, but that’s too complicated and problematic for me. Given the fact that kernel and its modules are needed every few updates, often with every update, I can’t imagine compiling kernels all the time.

Maybe Manjaro would be willing to include the fix in Manjaro kernels? It’s a long stretch, but in theory possible. @philm, what do you think? I could get you in touch with someone in Tuxedo. This would make Manjaro a friendly platform for the newest AMD laptop. Of course, this is a temporary fix, but still, a needed one, because suspend is working only on Tuxedo OS, which is absurd. Linux dedicated laptop that works completely on one distro?

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.