Hi, since 2 or 3 weeks, may be more, I don’t remember, my laptop, a Thinpad T14s AMD gen3, powered by Fedora 39 Gnome Wayland, randomly, the suspension cannot be restored, I have to do a hard reboot/reset.

This is the last line in journald:

janv. 27 23:43:42 t14s awatcher[5517]: [2024-01-27 22:43:42.757280 ERROR watchers::watchers] Error on active window iteration: org.freedesktop.DBus.Error.UnknownMethod: L’objet n’existe pas à l’emplacement « /org>
janv. 27 23:43:43 t14s systemd[1]: Reached target sleep.target - Sleep.
janv. 27 23:43:43 t14s systemd[1]: Starting systemd-suspend.service - System Suspend...
janv. 27 23:43:43 t14s rtkit-daemon[1524]: Successfully made thread 3838 of process 3792 (/usr/bin/gnome-shell) owned by '1000' high priority at nice level 0.
janv. 27 23:43:43 t14s systemd-sleep[224210]: Entering sleep state 'suspend'...
janv. 27 23:43:43 t14s kernel: PM: suspend entry (s2idle)
$ neofetch --off
OS: Fedora Linux 39 (Workstation Edition) x86_64
Host: 21CQCTO1WW ThinkPad T14s Gen 3
Kernel: 6.6.13-200.fc39.x86_64
Uptime: 10 mins
Packages: 3347 (rpm), 48 (flatpak)
Shell: zsh 5.9
Resolution: 1920x1200
DE: GNOME 45.3
WM: Mutter
WM Theme: Adwaita
Theme: Adwaita:dark [GTK2/3]
Icons: Adwaita [GTK2/3]
Terminal: tmux
CPU: AMD Ryzen 7 PRO 6850U with Radeon Graphics (16) @ 4.768GHz
GPU: AMD ATI Radeon 680M
Memory: 7262MiB / 30847MiB

I researched on ask fedora, no success.

I also searched on RedHat Bugzilla, I only found this slightly related to my problem “Radeon on Wayland - Black screen/crash on suspend/resume” but contrary to the description in this bug report, my problem only happens randomly. I’m not able to reproduce it with any certainty.

Am I the only one with this problem?

Do you have an idea of a direction in which I could explore to correct this problem?

Best regards, Stéphane

Crossposted on:

  • Vik
    15 months ago

    Do you have a rough guide of how frequently you can hit this issue in a given timeframe, like over the course of a week?

    I have the gen 2 version of this notebook (Cezanne) also with Fedora 39 + GNOME.

    One quick thing; I know this is a recent issue for you, but just want to confirm that you have the proper system sleep mode selected in UEFI. I presume (but cannot confirm if) the same option is available on your platform, but you will find it by hitting Enter on boot, and then F1 when prompted. Once in UEFI head to > Power settings > Sleep mode.

    Aside from that (and depending on how intermittent this), I’d try temporarily reverting the kernel for a few sessions via grub on boot

  • Stéphane Klein OP
    14 months ago

    After investigation, I think I’m the victim of two bugs:

    • the first is the one described here:

    Since kernel 6.6.8, I’ve been having suspend issues. Sometimes, a suspend request would result in the screen blanking, but the power LED remains lit. Other times, suspend would occur, but randomly, the system wakes itself (power LED is solid white), and eventually the fans turn on to full speed and the system gets very warm. A long press of the power button shuts it down, and it reboots normally. After a bit of experimenting, the bad suspend only occurs on lid close. Suspend works normally if a suspend is requested by pressing the power button. This behaviour has been confirmed by other Asus G14GA402 users, as well one Asus TUF Gaming A16 Advantage Edition FA617NS user. There was no issue with suspend on kernel 6.6.7 and lower. The issue has persisted through 6.6.8/9/11/13 and 6.7.2.

    The kernel 6.6.8 was released in “stable” on 2023-12-25, I think that’s when I started having problems that I considered random.

    Summary of QCNFA765 ath11k problems kernel-6.7.4

    The current 6.7.x suspend crashes are intertwined with the long standing packet loss and latency problems we’ve been seeing with QCNFA765 Linux ath11k.

    Kernel 6.4.12-6.6.14 all had the same problem where you need the iw dev wlp1s0 set power_save off workaround to prevent crippling packet losses and slow speeds. With the power_save workaround applied this wifi adapter was mostly tolerable.

    Kernel-6.7.3 broke suspend.

    Kernel-6.7.4 included a partial fix.

    I think I have this issue since 2024-02-06 when this kernel-6.7.3-200.fc39 package was published in stable.