[TRACKING] Cannot resume from suspend on AMD

[Matt_Hartley]

Please open a ticket and we’ll take a look at the logs as I have not been able to reproduce. Please link to this post.

[mailtodevnull]

@Matt_Hartley After upgrading to the 3.03 BIOS, the problem seems to be worse (or is at least unchanged, at best).

I often walk away from my laptop and it goes into suspend, and I am not able to wake it at least once or twice a day.

Edit: This happens even when suspend is triggered via power button. This last time, the laptop seemed to still be on. The chassis was very hot and when I held down the power button to shut off and restart, the fan came on full blast for a good minute or two to dissipate the heat. Yikes.

[Matt_Hartley]

Trying to replicate this without any success. I’m fully up to date, kernel 6.5.9.

Because I cannot replicate, this is what we’re needing folks to do.

[REQUEST] Fedora Workstation 39 Bug Reporting

Greetings all, Anyone experiencing issues with Fedora 39, it will be immensely helpful if we can get issues logged onto Bugzilla so the Fedora team can work to replicate and squash. Sometimes I am unable to replicate the exact issue experienced by a customer, after multiple attempts, we go nowhere with it. But, we need the ability to gather the customer experience for the Fedora team to help. Filing a bug and then tagging me directly there is going to help a TON. From here, we may be able to…

[mailtodevnull]

I have no idea what Fedora component this would be related to… susp and sleep bring up no entries, and power brings up a lot but I am not sure which to pick…

[snek]

perhaps unrelated (i’m on arch, not fedora) but my laptop was freezing 100% of the time when resuming from suspend after upgrading to the amd mainboard. i found that removing nvme.noacpi=1 (which i had previously added to fix freezing on the intel mainboard lol) fixed this.

[Matt_Hartley]

Just a reminder, AMD users, do not use nvme.noacpi=1 as it will absolutely cause issues with suspend.

[jonp]

I am also seeing this on an new Framework 13 AMD 76540U with Fedora 39 and 2xUSB-c, HDMI and USB-A expansion cards. It’s happened twice so far with nothing obvious to me in the logs (see below). The power button was blinking but not responsive, and I also had to eventually just hold it down to force a reboot.

$ uname -a
Linux fw 6.5.11-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov  8 22:37:57 UTC 2023 x86_64 GNU/Linux

$ sudo journalctl -r -b -1
Nov 16 09:40:09 fw kernel: PM: suspend entry (s2idle)
Nov 16 09:40:09 fw systemd-sleep[38541]: Entering sleep state 'suspend'...
Nov 16 09:40:09 fw systemd[1]: Starting systemd-suspend.service - System Suspend...
Nov 16 09:40:09 fw systemd[1]: Reached target sleep.target - Sleep.
Nov 16 09:40:06 fw wpa_supplicant[34658]: nl80211: deinit ifname=wlp1s0 disabled_11b_rates=0
Nov 16 09:40:06 fw wpa_supplicant[34658]: wlp1s0: CTRL-EVENT-DSCP-POLICY clear_all
Nov 16 09:40:06 fw wpa_supplicant[34658]: wlp1s0: CTRL-EVENT-DSCP-POLICY clear_all
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.4175] device (wlp1s0): set-hw-addr: reset MAC address to 14:AC:60:46:7E:DB (unmanage)
Nov 16 09:40:06 fw chronyd[34329]: Source 174.142.148.226 offline
Nov 16 09:40:06 fw chronyd[34329]: Can't synchronise: no selectable sources
Nov 16 09:40:06 fw chronyd[34329]: Source 149.56.47.60 offline
Nov 16 09:40:06 fw chronyd[34329]: Source 68.69.221.61 offline
Nov 16 09:40:06 fw chronyd[34329]: Source 69.196.158.106 offline
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.3731] device (wlp1s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Nov 16 09:40:06 fw wpa_supplicant[34658]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US
Nov 16 09:40:06 fw systemd-resolved[34125]: wlp1s0: Bus client reset DNS server list.
Nov 16 09:40:06 fw systemd-resolved[34125]: wlp1s0: Bus client set default route setting: no
Nov 16 09:40:06 fw avahi-daemon[34162]: Interface wlp1s0.IPv4 no longer relevant for mDNS.
Nov 16 09:40:06 fw avahi-daemon[34162]: Leaving mDNS multicast group on interface wlp1s0.IPv4 with address 192.168.1.150.
Nov 16 09:40:06 fw avahi-daemon[34162]: Withdrawing address record for 192.168.1.150 on wlp1s0.
Nov 16 09:40:06 fw avahi-daemon[34162]: Registering new address record for 192.168.1.150 on wlp1s0.IPv4.
Nov 16 09:40:06 fw avahi-daemon[34162]: New relevant interface wlp1s0.IPv4 for mDNS.
Nov 16 09:40:06 fw avahi-daemon[34162]: Joining mDNS multicast group on interface wlp1s0.IPv4 with address 192.168.1.150.
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.1290] device (wlp1s0): set-hw-addr: set MAC address to 1A:91:7E:92:A5:49 (scanning)
Nov 16 09:40:06 fw avahi-daemon[34162]: Withdrawing address record for 192.168.1.150 on wlp1s0.
Nov 16 09:40:06 fw avahi-daemon[34162]: Leaving mDNS multicast group on interface wlp1s0.IPv4 with address 192.168.1.150.
Nov 16 09:40:06 fw avahi-daemon[34162]: Interface wlp1s0.IPv4 no longer relevant for mDNS.
Nov 16 09:40:06 fw avahi-daemon[34162]: Interface wlp1s0.IPv6 no longer relevant for mDNS.
Nov 16 09:40:06 fw audit[34429]: NETFILTER_CFG table=firewalld:10 family=1 entries=26 op=nft_unregister_rule pid=34429 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
Nov 16 09:40:06 fw avahi-daemon[34162]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::ff61:6cc9:6748:71fa.
Nov 16 09:40:06 fw avahi-daemon[34162]: Withdrawing address record for fe80::ff61:6cc9:6748:71fa on wlp1s0.
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.0180] dhcp4 (wlp1s0): state changed no lease
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.0180] dhcp4 (wlp1s0): activation: beginning transaction (timeout in 45 seconds)
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.0180] dhcp4 (wlp1s0): canceled DHCP transaction
Nov 16 09:40:06 fw wpa_supplicant[34658]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.0177] device (wlp1s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
Nov 16 09:40:06 fw NetworkManager[34455]: <info>  [1700145606.0175] device (wlp1s0): supplicant interface state: completed -> disconnected
Nov 16 09:40:06 fw wpa_supplicant[34658]: wlp1s0: CTRL-EVENT-DSCP-POLICY clear_all
Nov 16 09:40:06 fw wpa_supplicant[34658]: wlp1s0: CTRL-EVENT-DISCONNECTED bssid=34:3a:20:a4:f6:72 reason=3 locally_generated=1
Nov 16 09:40:05 fw kernel: wlp1s0: deauthenticating from 34:3a:20:a4:f6:72 by local choice (Reason: 3=DEAUTH_LEAVING)
Nov 16 09:40:05 fw audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 16 09:40:05 fw systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
Nov 16 09:40:05 fw systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
Nov 16 09:40:05 fw NetworkManager[34455]: <info>  [1700145605.8413] device (wlp1s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
Nov 16 09:40:05 fw NetworkManager[34455]: <info>  [1700145605.8411] manager: NetworkManager state is now ASLEEP
Nov 16 09:40:05 fw ModemManager[34426]: <info>  [sleep-monitor-systemd] system is about to suspend
Nov 16 09:40:05 fw NetworkManager[34455]: <info>  [1700145605.8407] device (p2p-dev-wlp1s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Nov 16 09:40:05 fw NetworkManager[34455]: <info>  [1700145605.8404] manager: sleep: sleep requested (sleeping: no  enabled: yes)
Nov 16 09:40:05 fw systemd-logind[34270]: Suspending...
Nov 16 09:40:05 fw systemd-logind[34270]: Lid closed.
Nov 16 09:39:57 fw kernel: i2c_hid_acpi i2c-FRMW0005:00: i2c_hid_get_input: incomplete report (7/65535)
Nov 16 09:39:53 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:39:51 fw wpa_supplicant[34658]: RRM: Unsupported radio measurement type 9
Nov 16 09:39:46 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:39:46 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:39:46 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:39:44 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:39:23 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:39:23 fw firefox.desktop[36735]: ATTENTION: default value of option mesa_glthread overridden by environment.
Nov 16 09:38:18 fw wpa_supplicant[34658]: RRM: Unsupported radio measurement type 9

[Matt_Hartley]

@jonp

I am also seeing this on an new Framework 13 AMD 76540U with Fedora 39 and 2xUSB-c, HDMI and USB-A expansion cards. It’s happened twice so far with nothing obvious to me in the logs (see below). The power button was blinking but not responsive, and I also had to eventually just hold it down to force a reboot.

Confirming you’re on the latest BIOS?

sudo dmidecode -s bios-version

If you are on 3.03, please run this as sudo and report back:

sudo python3 amd_s2idle.py

[jonp]

Yup, bios 3.03. I ran amd_s2idle.py from drm / amd · GitLab

1st attempt: it suspended and then shortly afterwards rebooted the machine
2nd attempt: it suspended the machine, but wouldn’t wake up (reproduced the bug)
3rd attempt: it suspended, and woke up once and then exited.

Here are the outputs for all the attempts: Filebin | lq8rgnovrxkv0ozo

(The discussion board won’t let me post the entire log file.)

[Matt_Hartley]

Everyone experiencing this, on a hunch. Can you list what is attached to your Framework laptops (AMD Ryzen 7040 Series only):

• Peripherals
• Displays (how attached; USB, USB hub/dock, HDMI or DP expansion card - please be detailed)

I’m going to try and replicate here before sending this off to engineering.

---

@jonp

Yup, bios 3.03. I ran amd_s2idle.py from drm / amd · GitLab

1st attempt: it suspended and then shortly afterwards rebooted the machine
2nd attempt: it suspended the machine, but wouldn’t wake up (reproduced the bug)
3rd attempt: it suspended, and woke up once and then exited.

Here are the outputs for all the attempts: Filebin | lq8rgnovrxkv0ozo

(The discussion board won’t let me post the entire log file.)

Appreciate this, thank you.

[jonp]

@Matt_Hartley I’m running an AMD 76540U, Fedora 39. 2xUSB-c, HDMI and USB-A expansion cards, with no peripherals or displays.

[mailtodevnull]

@Matt_Hartley Ryzen 5 7640U, Fedora 39, 2xUSB-C, HDMI, USB-A expansion cards.

Looks like @jonp and I have the same expansion cards!

Displays are irrelevant, but has happened with:

• Standalone (no external displays)
• USB-C display (to 1 monitor, then daisy-chained via DP to another)

[jonp]

I wonder if this is related (based on what I saw with the amd_s2idle.py behaviour), but a few times now I’ve had my machine restart after suspending (similar to attempt #1 above).

Nothing obvious to me in the logs:

jp@fw:~$ sudo journalctl -r -b -1 | head -n 41
Nov 20 13:10:18 fw systemd[1]: Starting systemd-suspend.service - System Suspend...
Nov 20 13:10:18 fw wpa_supplicant[2181]: wlp1s0: CTRL-EVENT-DSCP-POLICY clear_all
Nov 20 13:10:18 fw systemd[1]: Reached target sleep.target - Sleep.
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.3028] device (wlp1s0): set-hw-addr: reset MAC address to 14:AC:60:46:7E:DB (unmanage)
Nov 20 13:10:18 fw chronyd[1596]: Source 206.108.0.133 offline
Nov 20 13:10:18 fw chronyd[1596]: Can't synchronise: no selectable sources
Nov 20 13:10:18 fw chronyd[1596]: Source 68.233.120.40 offline
Nov 20 13:10:18 fw chronyd[1596]: Source 158.69.20.38 offline
Nov 20 13:10:18 fw chronyd[1596]: Source 173.183.146.26 offline
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.2621] device (wlp1s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.2618] device (wlp1s0): supplicant interface state: disconnected -> interface_disabled
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.1923] device (wlp1s0): set-hw-addr: set MAC address to 7E:1B:0E:66:7B:BC (scanning)
Nov 20 13:10:18 fw audit[1674]: NETFILTER_CFG table=firewalld:28 family=1 entries=26 op=nft_unregister_rule pid=1674 subj=system_u:system_r:firewalld_t:s0 comm="firewalld"
Nov 20 13:10:18 fw systemd-resolved[1386]: wlp1s0: Bus client reset DNS server list.
Nov 20 13:10:18 fw systemd-resolved[1386]: wlp1s0: Bus client set default route setting: no
Nov 20 13:10:18 fw avahi-daemon[1422]: Interface wlp1s0.IPv4 no longer relevant for mDNS.
Nov 20 13:10:18 fw avahi-daemon[1422]: Leaving mDNS multicast group on interface wlp1s0.IPv4 with address 192.168.2.79.
Nov 20 13:10:18 fw avahi-daemon[1422]: Withdrawing address record for 192.168.2.79 on wlp1s0.
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.0779] dhcp4 (wlp1s0): state changed no lease
Nov 20 13:10:18 fw avahi-daemon[1422]: Interface wlp1s0.IPv6 no longer relevant for mDNS.
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.0779] dhcp4 (wlp1s0): activation: beginning transaction (timeout in 45 seconds)
Nov 20 13:10:18 fw avahi-daemon[1422]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address fe80::a660:1e6a:259c:c26c.
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.0779] dhcp4 (wlp1s0): canceled DHCP transaction
Nov 20 13:10:18 fw avahi-daemon[1422]: Withdrawing address record for fe80::a660:1e6a:259c:c26c on wlp1s0.
Nov 20 13:10:18 fw wpa_supplicant[2181]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=US
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.0774] device (wlp1s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
Nov 20 13:10:18 fw wpa_supplicant[2181]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Nov 20 13:10:18 fw NetworkManager[1708]: <info>  [1700503818.0772] device (wlp1s0): supplicant interface state: completed -> disconnected
Nov 20 13:10:18 fw wpa_supplicant[2181]: wlp1s0: CTRL-EVENT-DSCP-POLICY clear_all
Nov 20 13:10:18 fw wpa_supplicant[2181]: wlp1s0: CTRL-EVENT-DISCONNECTED bssid=02:ec:da:f2:2b:e3 reason=3 locally_generated=1
Nov 20 13:10:17 fw kernel: wlp1s0: deauthenticating from 02:ec:da:f2:2b:e3 by local choice (Reason: 3=DEAUTH_LEAVING)
Nov 20 13:10:17 fw audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 20 13:10:17 fw systemd[1]: Started NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service.
Nov 20 13:10:17 fw systemd[1]: Starting NetworkManager-dispatcher.service - Network Manager Script Dispatcher Service...
Nov 20 13:10:17 fw NetworkManager[1708]: <info>  [1700503817.9169] device (wlp1s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
Nov 20 13:10:17 fw NetworkManager[1708]: <info>  [1700503817.9167] manager: NetworkManager state is now ASLEEP
Nov 20 13:10:17 fw ModemManager[1672]: <info>  [sleep-monitor-systemd] system is about to suspend
Nov 20 13:10:17 fw NetworkManager[1708]: <info>  [1700503817.9163] device (p2p-dev-wlp1s0): state change: disconnected -> unmanaged (reason 'sleeping', sys-iface-state: 'managed')
Nov 20 13:10:17 fw NetworkManager[1708]: <info>  [1700503817.9161] manager: sleep: sleep requested (sleeping: no  enabled: yes)
Nov 20 13:10:17 fw systemd-logind[1509]: Suspending...
Nov 20 13:10:17 fw systemd-logind[1509]: Lid closed.

[Matt_Hartley]

Let’s take a look at your last 3 boots, for both of you:

journalctl -b 0 -u systemd-logind; journalctl -b -1 -u systemd-logind; journalctl -b -2 -u systemd-logind

and

cat /etc/default/grub

Testing against Fedora 39 or Ubuntu 22.04.3 OEM C kernel (please not Mint, number of items there are old).

[jonp]

Okay! Also, I added amdgpu.sg_display=0 because I was getting the screen glitching issue.

jp@fw:~$ cat /etc/default/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-1bc906c1-fbe5-4985-b07f-9fa13b689164 rhgb quiet amdgpu.sg_display=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
jp@fw:~$ journalctl -b 0 -u systemd-logind
Nov 20 13:35:17 fw systemd[1]: Starting systemd-logind.service - User Login Management...
Nov 20 13:35:17 fw systemd-logind[1631]: New seat seat0.
Nov 20 13:35:17 fw systemd-logind[1631]: Watching system buttons on /dev/input/event0 (Lid Switch)
Nov 20 13:35:17 fw systemd-logind[1631]: Watching system buttons on /dev/input/event1 (Power Button)
Nov 20 13:35:17 fw systemd-logind[1631]: Watching system buttons on /dev/input/event4 (FRMW0004:00 32AC:0006 Consumer Control)
Nov 20 13:35:17 fw systemd-logind[1631]: Watching system buttons on /dev/input/event2 (AT Translated Set 2 keyboard)
Nov 20 13:35:18 fw systemd[1]: Started systemd-logind.service - User Login Management.
Nov 20 13:35:18 fw systemd-logind[1631]: New session c1 of user gdm.
Nov 20 13:35:24 fw systemd-logind[1631]: New session 2 of user jp.
Nov 20 13:35:27 fw systemd-logind[1631]: Session c1 logged out. Waiting for processes to exit.
Nov 20 13:35:27 fw systemd-logind[1631]: Removed session c1.
Nov 20 14:08:48 fw systemd-logind[1631]: Power key pressed short.
Nov 20 14:08:48 fw systemd-logind[1631]: The system will suspend now!
Nov 20 14:08:49 fw systemd-logind[1631]: Lid closed.
Nov 20 15:31:28 fw systemd-logind[1631]: Lid opened.
Nov 20 15:31:28 fw systemd-logind[1631]: Operation 'sleep' finished.
Nov 20 16:48:51 fw systemd-logind[1631]: Lid closed.
Nov 20 16:48:51 fw systemd-logind[1631]: Suspending...
Nov 20 19:21:49 fw systemd-logind[1631]: Operation 'sleep' finished.
Nov 20 19:21:56 fw systemd-logind[1631]: Lid opened.
Nov 20 20:10:47 fw systemd-logind[1631]: Watching system buttons on /dev/input/event13 (SRS-XE200 (AVRCP))
jp@fw:~$ journalctl -b -1 -u systemd-logind
Nov 20 13:27:02 fw systemd[1]: Starting systemd-logind.service - User Login Management...
Nov 20 13:27:02 fw systemd-logind[9904]: New seat seat0.
Nov 20 13:27:02 fw systemd-logind[9904]: Watching system buttons on /dev/input/event0 (Lid Switch)
Nov 20 13:27:02 fw systemd-logind[9904]: Watching system buttons on /dev/input/event1 (Power Button)
Nov 20 13:27:02 fw systemd-logind[9904]: Watching system buttons on /dev/input/event4 (FRMW0004:00 32AC:0006 Consumer Control)
Nov 20 13:27:02 fw systemd-logind[9904]: Watching system buttons on /dev/input/event2 (AT Translated Set 2 keyboard)
Nov 20 13:27:02 fw systemd[1]: Started systemd-logind.service - User Login Management.
Nov 20 13:27:03 fw systemd-logind[9904]: New session c1 of user gdm.
Nov 20 13:27:24 fw systemd-logind[9904]: New session 2 of user jp.
Nov 20 13:27:27 fw systemd-logind[9904]: Session c1 logged out. Waiting for processes to exit.
Nov 20 13:27:27 fw systemd-logind[9904]: Removed session c1.
Nov 20 13:32:43 fw systemd-logind[9904]: Power key pressed short.
Nov 20 13:32:44 fw systemd-logind[9904]: The system will suspend now!
jp@fw:~$ journalctl -b -2 -u systemd-logind
Nov 19 18:12:53 fw systemd[1]: Starting systemd-logind.service - User Login Management...
Nov 19 18:12:53 fw systemd-logind[1509]: New seat seat0.
Nov 19 18:12:53 fw systemd-logind[1509]: Watching system buttons on /dev/input/event0 (Lid Switch)
Nov 19 18:12:53 fw systemd-logind[1509]: Watching system buttons on /dev/input/event1 (Power Button)
Nov 19 18:12:53 fw systemd-logind[1509]: Watching system buttons on /dev/input/event4 (FRMW0004:00 32AC:0006 Consumer Control)
Nov 19 18:12:53 fw systemd-logind[1509]: Watching system buttons on /dev/input/event2 (AT Translated Set 2 keyboard)
Nov 19 18:12:53 fw systemd[1]: Started systemd-logind.service - User Login Management.
Nov 19 18:12:53 fw systemd-logind[1509]: New session c1 of user gdm.
Nov 19 18:12:58 fw systemd-logind[1509]: New session 2 of user jp.
Nov 19 18:13:01 fw systemd-logind[1509]: Session c1 logged out. Waiting for processes to exit.
Nov 19 18:13:01 fw systemd-logind[1509]: Removed session c1.
Nov 19 18:25:52 fw systemd-logind[1509]: Lid closed.
Nov 19 18:25:52 fw systemd-logind[1509]: Suspending...
Nov 19 18:25:57 fw systemd-logind[1509]: Delay lock is active (UID 1000/jp, PID 2853/gnome-shell) but inhibitor timeout is reached.
Nov 19 18:26:58 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 19 18:27:24 fw systemd-logind[1509]: Suspending...
Nov 19 18:27:29 fw systemd-logind[1509]: Delay lock is active (UID 1000/jp, PID 2853/gnome-shell) but inhibitor timeout is reached.
Nov 19 18:27:35 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 19 18:28:00 fw systemd-logind[1509]: Suspending...
Nov 19 18:28:05 fw systemd-logind[1509]: Delay lock is active (UID 1000/jp, PID 2853/gnome-shell) but inhibitor timeout is reached.
Nov 19 18:29:37 fw systemd-logind[1509]: Lid opened.
Nov 19 18:29:37 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 19 20:35:02 fw systemd-logind[1509]: Lid closed.
Nov 19 20:35:02 fw systemd-logind[1509]: Suspending...
Nov 19 20:41:07 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 19 20:41:36 fw systemd-logind[1509]: Suspending...
Nov 20 08:07:05 fw systemd-logind[1509]: Lid opened.
Nov 20 08:07:05 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 08:14:05 fw systemd-logind[1509]: Lid closed.
Nov 20 08:14:05 fw systemd-logind[1509]: Suspending...
Nov 20 08:37:56 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 08:37:57 fw systemd-logind[1509]: Lid opened.
Nov 20 08:57:36 fw systemd-logind[1509]: Lid closed.
Nov 20 08:57:36 fw systemd-logind[1509]: Suspending...
Nov 20 09:00:08 fw systemd-logind[1509]: Lid opened.
Nov 20 09:00:08 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 09:37:27 fw systemd-logind[1509]: The system will suspend now!
Nov 20 09:47:01 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 10:02:01 fw systemd-logind[1509]: The system will suspend now!
Nov 20 10:17:45 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 10:32:45 fw systemd-logind[1509]: The system will suspend now!
Nov 20 11:25:28 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 12:11:39 fw systemd-logind[1509]: The system will suspend now!
Nov 20 12:13:35 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 12:29:03 fw systemd-logind[1509]: The system will suspend now!
Nov 20 12:43:58 fw systemd-logind[1509]: Operation 'sleep' finished.
Nov 20 13:10:17 fw systemd-logind[1509]: Lid closed.
Nov 20 13:10:17 fw systemd-logind[1509]: Suspending...

[goldenspinach]

@Matt_Hartley An anecdotal data point which may help track down the problem. Yesterday I received my Framework Laptop 13 DIY Edition (AMD Ryzen 7640U), batch 5, BIOS 3.03. Within BIOS settings, limited max battery charge to 80%. Promptly installed Fedora 38 (not 39). During installation I set the filesystem to ext4 instead of btrfs. After installation I updated the kernel to 6.5.11-200; no other package updates.

Suspending and then attempting to wake resulted in a hard lockup. The keyboard lit up, but the screen was completely blank, and no other indication that it was working. The only way to get the machine back alive was a hard reboot by holding the power button for about 10 seconds. The failure to wake happened about 10 times or so. Nothing was attached to the expansion cards.

While in the zombie state (with the keyboard lit up), toggling the caps lock key stopped working after about a minute (the white light on the key wouldn’t turn on).

Analysing logs via journalctl didn’t seem to yield anything that stood out: the system entered sleep and never woke up from it; the immediate messages after sleep indicated a fresh boot.

This morning I installed all the latest Fedora 38 updates. To be doubly sure I reinstalled the kernel (including kernel-modules-extra), systemd, grub2 from the update channel. Manually rebooted several times via the “power off” menu in Gnome.

Suspending the laptop seems to work properly now, with the laptop coming back alive. I did the suspend/wake cycle about 10 times now within a 5 minute window. However, given the problems reported within this ticket (intermittent failures) and my own negative experience, I don’t know if suspend is actually reliable over a longer period. Will report back here with observations.

PS. There was one “weird” thing during the first boot immediately after assembling the laptop. Step 12 in the DIY Edition Quick Start Guide (AMD Ryzen series) states that the first boot will “take a while” due to “memory training” and suggests that the wait will be in the “order of a minute or two”. On first boot I let it do its thing and left it running for at least 15 minutes. During this time, the screen remained blank and the fans were seemingly at full speed. Eventually I got frustrated/worried and did a hard reset via holding the power button.
Is the Quick Start Guide wrong here? Is the first boot supposed to take 15 minutes or even longer?

Laptop details as follows, in case this is helpful.
AMD Ryzen 5 7640U.
1 x 16GB RAM; DDR5-5600; product model: FRANRMFW02.
1TB (Gen 4) WD_BLACK SN770 NVMe SSD.
Expansion cards: 1 x USB-C, 1 x HDMI, 2 x USB-A
Locations:
(1) top-left: USB-C (FRACCKBZ01)
(2) bottom-left: HDMI (FRACCHBZ01-3)
(3) top-right: USB-A (FRACCABZ01)
(4) bottom-right: USB-A (FRACCABZ01)
Let me know if you need the serial numbers of each expansion card.

sudo dmidecode -s bios-version gives: 03.03
uname -r gives: 6.5.11-200.fc38.x86_64
fwupdmgr update states that there are no available firmware updates (WD BLACK SSD and the fingerprint sensor); system firmware and UEFI dbx have the latest available firmware version.

[jonp]

I’ve noticed a pattern: I’ll suspend my machine and it will reboot rather than wake up, and then the very next time I suspend it won’t resume. This what I saw when I ran amd_s2idle.py in previous post.

I’m not seeing any failures to resume that aren’t preceded by suspend-then-reboot.

I tried running amd_s2idle.py multiple times (using the --count parameter) and saw this same pattern: reboot, then unable to wake from suspend, then variable number of successful resumes.

Not sure if this is at all helpful, but thought I’d add it to the mix.

[goldenspinach]

@Matt_Hartley May have found the culprit. Suspend becomes unreliable when the laptop is disconnected from power and “PCIE Dynamic Link Power Management” is enabled within BIOS.

The following seems to reproduce the hard lockup (and the wake-to-reboot observed by jonp) on my machine when using Fedora 38 + latest updates.
(1) Ensure “PCIE Dynamic Link Power Management” is enabled within the BIOS Setup Utility.
(2) Turn off laptop.
(3) Plug in power.
(4) Turn on laptop.
(5) Log in to desktop.
(6) Suspend from the Gnome power off menu.
(7) Disconnect power.
(8) Attempt to wake by pressing the power button; at this stage the laptop either reboots or refuses to wake up.

Suspend seems to work if “PCIE Dynamic Link Power Management” is disabled.
The BIOS setup utility gives the following info:
“Reduce PCIE bus speed to gen 3 when running on battery. AMD PSPP.”

With this setting disabled, suspend appears to work, but the battery still seems to drain at a noticeable rate (around 3 percentage points per hour or so).

(For posterity, this is how to disable PCIE power management. Reboot laptop and repeatedly press F2 until the BIOS menu comes up. Select “Setup Utility”. Go to Advanced settings. Disable “PCIE Dynamic Link Power Management”. Press F10 to save settings and exit.)

@jonp @mailtodevnull Can you try reproducing the above workaround?

[jwp]

I notice a luks volume in your kernel CLI - so I assume you’re using encrypted volumes and have secureboot turned on.

Do you get the same behaviour when secureboot is disabled and/or you don’t have encrypted volume?

[jonp]

@goldenspinach I tried your recipe (again, I’m on Fedora 39) but it doesn’t reliably reproduce the issue for me.

@jwp I am running a luks volume, but I have secure boot turned off. This is my primary machine atm so I’m reluctant to wipe it just to run the experiment of seeing if a non-luks volume / secureboot is a factor here.

That said, the issue is causing me significant strife – I’ve lost some work at this point, and I can’t rely on this machine to wake from suspend which is annoying.

So… perhaps it is time to wipe it and try again…