Suspend/sleep doesn't work

Support
, ,
1

Note: The topic is only for suspend/sleep. I don’t have hibernation configured.

Recently I moved entire disc (NVMe) to a different laptop with different CPU and GPU hardware. Now I’m ironing out issues that came out of that relocation.

Suspending/sleep doesn’t work, or at least not fully. There is no Sleep action in power menu (KDE Plasma), although it was available under the previous laptop. It doesn’t work fully when I close the lid, it seems as sleep is successful, but then it’s impossible to wake the laptop up, and I have to force shutdown/reboot.

On old laptop, suspend worked, so all settings should be there, in theory.
On another disc, there is TUXEDO OS and suspend works there without problem, so this is not a hardware issue, but certainly some bad configs on my Manjaro system that is not re-configured to the new hardware properly.

Here is the hardware:

inxi --full --admin --filter --width
System:
  Kernel: 6.7.0-0-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
    clocksource: tsc avail: acpi_pm
    parameters: BOOT_IMAGE=/boot/vmlinuz-6.7-x86_64
    root=UUID=05f58c13-0021-44f7-abc9-05a091c4535b rw rhgb quiet
    mitigations=off quiet splash loglevel=3 udev.log_priority=3
    vt.global_cursor_default=0 resume_offset=1363968
  Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.12 info: frameworks
    v: 5.113.0 wm: kwin_wayland with: latte-dock vt: 1 dm: SDDM
    Distro: Manjaro Linux base: Arch Linux
Machine:
  Type: Laptop System: TUXEDO product: TUXEDO Sirius 16 Gen1 v: N/A
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: NB04 model: APX958 serial: <superuser required> part-nu: SIRIUS1601
    uuid: <superuser required> UEFI: American Megatrends LLC. v: 1.00A00_20240108
    date: 01/08/2024
Battery:
  ID-1: BAT0 charge: 73.7 Wh (92.0%) condition: 80.1/80.1 Wh (100.0%)
    volts: 17.2 min: N/A model: AMD Battery Li-ion Real Battery type: Li-ion
    serial: <filter> status: charging
CPU:
  Info: model: AMD Ryzen 7 7840HS w/ Radeon 780M Graphics bits: 64 type: MT MCP
    arch: Zen 4 gen: 5 level: v4 note: check built: 2022+ process: TSMC n5 (5nm)
    family: 0x19 (25) model-id: 0x74 (116) stepping: 1 microcode: 0xA704103
  Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
    L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 8 MiB desc: 8x1024 KiB
    L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 768 high: 1459
    min/max: 400/5137:6080:5764:5293:5449:5608:5924 scaling:
    driver: amd-pstate-epp governor: powersave cores: 1: 400 2: 400 3: 1399
    4: 1370 5: 400 6: 400 7: 400 8: 1459 9: 400 10: 1307 11: 400 12: 400
    13: 400 14: 400 15: 1357 16: 1396 bogomips: 121416
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
  Vulnerabilities:
  Type: gather_data_sampling status: Not affected
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: mmio_stale_data status: Not affected
  Type: retbleed status: Not affected
  Type: spec_rstack_overflow status: Vulnerable
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1 status: Vulnerable: __user pointer sanitization and
    usercopy barriers only; no swapgs barriers
  Type: spectre_v2 status: Vulnerable, IBPB: disabled, STIBP: disabled,
    PBRSB-eIBRS: Not affected
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD Navi 33 [Radeon RX 7700S/7600/7600S/7600M XT/PRO W7600]
    vendor: Emdoor Digital driver: amdgpu v: kernel arch: RDNA-3 code: Navi-33
    built: 2023+ pcie: gen: 4 speed: 16 GT/s lanes: 8 ports: active: none
    empty: DP-1,HDMI-A-1,eDP-1 bus-ID: 03:00.0 chip-ID: 1002:7480
    class-ID: 0300
  Device-2: AMD Phoenix1 vendor: Emdoor Digital driver: amdgpu v: kernel
    arch: RDNA-3 code: Phoenix process: TSMC n4 (4nm) built: 2023+ pcie: gen: 4
    speed: 16 GT/s lanes: 16 ports: active: eDP-2 empty: DP-2, DP-3, DP-4,
    DP-5, DP-6, DP-7, DP-8, DP-9 bus-ID: 69:00.0 chip-ID: 1002:15bf
    class-ID: 0300 temp: 36.0 C
  Device-3: Microdia Integrated Camera driver: uvcvideo type: USB rev: 2.0
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-1:2 chip-ID: 0c45:6362
    class-ID: 0e02 serial: <filter>
  Display: wayland server: X.org v: 1.21.1.10 with: Xwayland v: 23.2.3
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: modesetting,radeon alternate: fbdev,vesa dri: radeonsi
    gpu: amdgpu,amdgpu display-ID: 0
  Monitor-1: eDP-2 res: 1969x1108 size: N/A modes: N/A
  API: EGL v: 1.5 hw: drv: amd radeonsi platforms: device: 0 drv: radeonsi
    device: 1 drv: radeonsi device: 2 drv: swrast gbm: drv: radeonsi surfaceless:
    drv: radeonsi wayland: drv: radeonsi x11: drv: radeonsi
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 23.3.3-manjaro1.1
    glx-v: 1.4 direct-render: yes renderer: AMD Radeon Graphics (radeonsi
    gfx1103_r1 LLVM 16.0.6 DRM 3.56 6.7.0-0-MANJARO) device-ID: 1002:15bf
    memory: 500 MiB unified: no display-ID: :1.0
  API: Vulkan v: 1.3.274 layers: 8 device: 0 type: discrete-gpu name: AMD
    Radeon RX 7600M XT (RADV NAVI33) driver: mesa radv v: 23.3.3-manjaro1.1
    device-ID: 1002:7480 surfaces: xcb,xlib,wayland device: 1
    type: integrated-gpu name: AMD Radeon Graphics (RADV GFX1103_R1)
    driver: mesa radv v: 23.3.3-manjaro1.1 device-ID: 1002:15bf
    surfaces: xcb,xlib,wayland
Audio:
  Device-1: AMD Navi 31 HDMI/DP Audio driver: snd_hda_intel v: kernel pcie:
    gen: 4 speed: 16 GT/s lanes: 8 bus-ID: 03:00.1 chip-ID: 1002:ab30
    class-ID: 0403
  Device-2: AMD Rembrandt Radeon High Definition Audio driver: snd_hda_intel
    v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 69:00.1
    chip-ID: 1002:1640 class-ID: 0403
  Device-3: AMD ACP/ACP3X/ACP6x Audio Coprocessor vendor: Emdoor Digital
    driver: snd_pci_ps v: kernel alternate: snd_pci_acp3x, snd_rn_pci_acp3x,
    snd_pci_acp5x, snd_pci_acp6x, snd_acp_pci, snd_rpl_pci_acp6x,
    snd_sof_amd_renoir, snd_sof_amd_rembrandt, snd_sof_amd_vangogh pcie: gen: 4
    speed: 16 GT/s lanes: 16 bus-ID: 69:00.5 chip-ID: 1022:15e2 class-ID: 0480
  Device-4: AMD Family 17h/19h HD Audio vendor: Emdoor Digital
    driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
    bus-ID: 69:00.6 chip-ID: 1022:15e3 class-ID: 0403
  API: ALSA v: k6.7.0-0-MANJARO status: kernel-api with: aoss
    type: oss-emulator tools: alsactl,alsamixer,amixer
  Server-1: sndiod v: N/A status: off tools: aucat,midicat,sndioctl
  Server-2: JACK v: 1.9.22 status: off tools: N/A
  Server-3: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: e000
    bus-ID: 05:00.0 chip-ID: 10ec:8168 class-ID: 0200
  IF: enp5s0 state: down mac: <filter>
  Device-2: MEDIATEK MT7921K Wi-Fi 6E 80MHz driver: mt7921e v: kernel pcie:
    gen: 2 speed: 5 GT/s lanes: 1 bus-ID: 06:00.0 chip-ID: 14c3:0608
    class-ID: 0280
  IF: wlp6s0 state: up mac: <filter>
Bluetooth:
  Device-1: MediaTek Wireless_Device driver: btusb v: 0.8 type: USB rev: 2.1
    speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-5:4 chip-ID: 0e8d:0608
    class-ID: e001 serial: <filter>
  Report: btmgmt ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 5.2
    lmp-v: 11 status: discoverable: no pairing: no class-ID: 7c010c
Drives:
  Local Storage: total: 2.73 TiB used: 340.39 GiB (12.2%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Kingston model: SKC2500M82000G
    size: 1.82 TiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
    lanes: 4 tech: SSD serial: <filter> fw-rev: S7781101 temp: 31.9 C
    scheme: GPT
  ID-2: /dev/nvme1n1 maj-min: 259:4 vendor: Samsung model: SSD 980 1TB
    size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
    lanes: 4 tech: SSD serial: <filter> fw-rev: 3B4QFXO7 temp: 31.9 C
    scheme: GPT
Partition:
  ID-1: / raw-size: 100.59 GiB size: 98.82 GiB (98.25%) used: 43.9 GiB (44.4%)
    fs: ext4 block-size: 4096 B dev: /dev/nvme0n1p4 maj-min: 259:3
  ID-2: /home raw-size: 1.72 TiB size: 1.69 TiB (98.42%)
    used: 296.49 GiB (17.1%) fs: ext4 block-size: 4096 B dev: /dev/nvme0n1p2
    maj-min: 259:1
Swap:
  Kernel: swappiness: 20 (default 60) cache-pressure: 100 (default) zswap: yes
    compressor: zstd max-pool: 20%
  ID-1: swap-1 type: file size: 512 MiB used: 0 KiB (0.0%) priority: -2
    file: /swapfile
  ID-2: swap-2 type: zram size: 6.12 GiB used: 14.2 MiB (0.2%) priority: 100
    comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 16 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 39.8 C mobo: N/A
  Fan Speeds (rpm): N/A
  GPU: device: amdgpu temp: 37.0 C watts: 7.23 device: amdgpu temp: 40.0 C
    mem: 47.0 C fan: 0
Info:
  Memory: total: 32 GiB note: est. available: 30.58 GiB used: 7.96 GiB (26.0%)
  Processes: 399 Power: uptime: 24m states: freeze,mem,disk suspend: s2idle
    wakeups: 0 hibernate: platform avail: shutdown,reboot,suspend,test_resume
    image: 12.21 GiB daemons: upowerd, org_kde_powerdevil,
    power-profiles-daemon Init: systemd v: 255 default: graphical
    tool: systemctl
  Packages: 2119 pm: pacman pkgs: 2100 libs: 561 tools: pamac,yay pm: flatpak
    pkgs: 12 pm: snap pkgs: 7 Compilers: clang: 16.0.6 gcc: 13.2.1 Shell: Bash
    v: 5.2.21 running-in: konsole inxi: 3.3.32

Here is journald info:

journalctl -b -1 -g suspend
lut 14 19:37:46 alienware-PC kernel: Low-power S0 idle used by default for system suspend
lut 14 19:37:46 alienware-PC kernel: nvme 0000:08:00.0: platform quirk: setting simple suspend
lut 14 19:37:46 alienware-PC kernel: nvme 0000:04:00.0: platform quirk: setting simple suspend
lut 14 19:37:53 alienware-PC kded5[5944]: kscreen.kded: PowerDevil SuspendSession action not available!
lut 14 19:40:08 alienware-PC systemd-logind[761]: The system will suspend now!
lut 14 19:40:08 alienware-PC ModemManager[838]: <msg> [sleep-monitor-systemd] system is about to suspend
lut 14 19:40:09 alienware-PC systemd[1]: Starting System Suspend...
lut 14 19:40:10 alienware-PC systemd-sleep[39018]: Performing sleep operation 'suspend'...

There is never wake up data, because system never wakes up. I have to long-power press to boot the system again.

Any idea where to beging?

2

It seems likely that it’s some old configuration from your old laptop, but without knowing the hardware of the old laptop, and whatever modifications you made to the configuration of it, it seems really hard to pin it down.

My best guess is that as your old machine was an Alienware - at least, according to the name of the computer - it had an Intel CPU + Nvidia GPU. Going from that to an all AMD system could cause some issues in, well, a fair number of configuration files - especially on the GPU portion.

Is there any reason why you can’t reinstall? I know it’s a bit of a pain, but it may very well be that a reinstall is lower effort than resetting all the configuration files.

3

I already removed my graphic configuration via MHWD and installed nonefree which is suitable for AMD system. Otherwise, the system wouldn’t even boot.
As to fstab, since I moved the disc, UUIDs stayed the same, so the only thing I did was to removed entry about HDD from the old computer.
I also needed to regenerate initframs or whatever it is called, to make system boot and installed amd-ucode.

That was basically enough for the system to boot properly. Installing TUXEDO drivers made it boot quicker (or rather normally, because earlier, after the move it was a bit on a slower side), so probably fewer errors in the background.

However, I noticed some issue with dynamic swapfile process that doesn’t start and it claims to be dependency. Certainly it’s not a mandatory dependency, because I reinstalled the package and it didn’t install anything new. Maybe there is some optional dependency for AMD systems, but it doesn’t tell in PKGFILE. Since I have 32G RAM now, I am considering removing swap, but that is needed only for hibernation (which is not set anyway). Anyway, that’s a side problem, that I will solve, so let’s not focus on that here, unless it’s relevant to the sleep issue. EDIT: I solved the dynamic swap issue, it works now, but the issue of suspend not working stays, so as I said, it’s not connected.

I wonder, if dynamic swap issues can influence sleep? In theory, they shouldn’t as sleep is performed into RAM. Maybe the RAM is the issue and needs to be somehow pointed out in some settings?

Since the same systems and configs worked fine on old computer, and now it doesn’t even show suspend option in the menu, shows some basic condition is not met. But which one? I tried reading about suspend in Arch wiki, but it was too technical and they mostly focused on hibernation stuff.

Anyway, maybe those have something to do with it:

/etc/default/grub

GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="Manjaro"
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash loglevel=3 udev.log_priority=3 vt.global_cursor_default=0"
GRUB_CMDLINE_LINUX="rhgb quiet mitigations=off"
GRUB_PRELOAD_MODULES="part_gpt part_msdos"
GRUB_TERMINAL_INPUT=console
GRUB_GFXMODE=auto
GRUB_GFXPAYLOAD_LINUX=keep
GRUB_DISABLE_RECOVERY=true

The rest is just theming options.

/etc/mkinitcpio.conf

MODULES=()
FILES=()
HOOKS=(base udev autodetect modconf kms keyboard keymap block filesystems fsck)

Clean installation is the last resort. I have too many programs and configurations, so trying to recreate it would be a chore. I already tried it and I dropped it, because I had to find out all things I set in the past to set it the same way. I know I can copy /home files, but that is too messy if the system part is different.

However, I don’t have any crazy modifications to my root, Most is kept to defaults. The exception is the swap (had swap partition in the past) and zram (had too little RAM on old device) and some graphic options for optimus-manager, but those were removed during the move.

If the system data is too full and intimidating, I’m sending a simpler version (ignore the alienware part, I will change it later):

System:
  Host: alienware-PC Kernel: 6.7.0-0-MANJARO arch: x86_64 bits: 64
  Desktop: KDE Plasma v: 5.27.10 Distro: Manjaro Linux
Machine:
  Type: Laptop System: TUXEDO product: TUXEDO Sirius 16 Gen1 v: N/A
    serial: <superuser required>
  Mobo: NB04 model: APX958 serial: <superuser required> UEFI: American
    Megatrends LLC. v: 1.00A00_20240108 date: 01/08/2024
Battery:
  ID-1: BAT0 charge: 73.7 Wh (92.0%) condition: 80.1/80.1 Wh (100.0%)
CPU:
  Info: 8-core AMD Ryzen 7 7840HS w/ Radeon 780M Graphics [MT MCP]
    speed (MHz): avg: 623 min/max: 400/5137:6080:5764:5293:5449:5608:5924
Graphics:
  Device-1: AMD Navi 33 [Radeon RX 7700S/7600/7600S/7600M XT/PRO W7600]
    driver: amdgpu v: kernel
  Device-2: AMD Phoenix1 driver: amdgpu v: kernel
  Device-3: Microdia Integrated Camera driver: uvcvideo type: USB
  Display: wayland server: X.org v: 1.21.1.10 with: Xwayland v: 23.2.3
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: modesetting,radeon dri: radeonsi gpu: amdgpu,amdgpu
    resolution: 1969x1108
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 23.3.3-manjaro1.1
    renderer: AMD Radeon Graphics (radeonsi gfx1103_r1 LLVM 16.0.6 DRM 3.56
    6.7.0-0-MANJARO)
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
    driver: r8169
  Device-2: MEDIATEK MT7921K Wi-Fi 6E 80MHz driver: mt7921e
Drives:
  Local Storage: total: 2.73 TiB used: 340.71 GiB (12.2%)
Info:
  Memory: total: 32 GiB note: est. available: 30.58 GiB used: 9.96 GiB (32.6%)
  Processes: 397 Uptime: 43m Shell: Bash inxi: 3.3.32

I also checked my journald, and it looks like mostly the same stuff from old machine:


lut 14 20:33:48 alienware-PC kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.I2CA.TPNL], AE_ALREADY_EXISTS (20230628/dswload2-326)
lut 14 20:33:48 alienware-PC kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)
lut 14 20:33:48 alienware-PC kernel: ACPI BIOS Error (bug): Failure creating named object [\_SB.I2CD.TPDD], AE_ALREADY_EXISTS (20230628/dswload2-326)
lut 14 20:33:48 alienware-PC kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20230628/psobject-220)
lut 14 20:33:52 alienware-PC bluetoothd[2143]: profiles/audio/bap.c:bap_adapter_probe() BAP requires ISO Socket which is not enabled
lut 14 20:33:52 alienware-PC bluetoothd[2143]: bap: Operation not supported (95)
lut 14 20:33:57 alienware-PC wpa_supplicant[1073]: bgscan simple: Failed to enable signal strength monitoring
lut 14 20:35:50 alienware-PC systemd-networkd-wait-online[745]: Timeout occurred while waiting for network connectivity.
lut 14 20:35:50 alienware-PC systemd[1]: Failed to start Wait for Network to be Configured.
lut 14 20:35:50 alienware-PC nmbd[33253]: [2024/02/14 20:35:50.378250,  0] ../../source3/nmbd/nmbd_namequery.c:109(query_name_response)
lut 14 20:35:50 alienware-PC nmbd[33253]:   query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.120 for name WORKGROUP<1d>.
lut 14 20:35:50 alienware-PC nmbd[33253]:   This response was from IP 192.168.1.104, reporting an IP address of 192.168.1.104.
ut 14 22:27:08 alienware-PC kwin_wayland[5743]: kwin_libinput: Libinput: event6  - PNP0C50:0b 0911:5288 Touchpad: kernel bug: Touch jump detected and discarded.
                                                 See https://wayland.freedesktop.org/libinput/doc/1.24.0/touchpad-jumping-cursors.html for details
4

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.

5

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:

6

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.

7

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
8

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

9

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:

10

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.

11

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.

12

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?

13

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.

14

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.

15

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
17

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.

18

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
19

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.

20

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
21

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