[Round 2] Framework 16 Fails to Resume From Hibernate

Framework Laptop 16
, ,
1

Since my last update, my laptop hangs when resuming from hibernate.

Kernel: 6.16.5.arch1-1
Systemd: 257.9-1

See previous (locked) thread– symptoms are very similar: Framework 16 Fails to Resume From Hibernate

Hangs displaying this:

Sep 24 21:57:41 nickadeck kernel: mt7921e 0000:04:00.0: Message 00020007 (seq 8) timeout
Sep 24 21:57:41 nickadeck kernel: mt7921e 0000:04:00.0: PM: dpm_run_callback(): pci_pm_restore returns -110
Sep 24 21:57:41 nickadeck kernel: mt7921e 0000:04:00.0: PM: failed to restore async: error -110

After waiting far too long, I pressed the power button. At this point, it powers off. Looking at the journal, I see this was printed immediately after pressing the power button.

Sep 24 21:57:41 nickadeck kernel: mt7921e 0000:04:00.0: HW/SW Version: 0x8a108a10, Build Time: 20250523103150a
Sep 24 21:57:41 nickadeck kernel: mt7921e 0000:04:00.0: WM Firmware Version: ____000000, Build Time: 20250523103234
Sep 24 21:57:41 nickadeck kernel: PM: hibernation: Basic memory bitmaps freed
Sep 24 21:57:41 nickadeck kernel: OOM killer enabled.
Sep 24 21:57:41 nickadeck kernel: Restarting tasks: Starting
Sep 24 21:57:41 nickadeck kernel: Restarting tasks: Done
Sep 24 21:57:41 nickadeck kernel: Bluetooth: hci0: HW/SW Version: 0x008a008a, Build Time: 20250523103438
Sep 24 21:57:41 nickadeck kernel: PM: hibernation: hibernation exit

Full log attached. I am using the rfkill systemd service from the linked post, and have checked that it is enabled. Perhaps something changed in systemd? Or maybe the driver is even more poorly behaved than before.

2

Based on our earlier lkml report (link: Making sure you're not a bot! ) , when it got worse for Sergio, he had to rfkill wifi too, not just bluetooth. Perhaps I should try that, since @Matt_Hartley ‘s script only kills wifi at the moment. Let me know if you all have any other ideas, or are experiencing this yourselves?

3

Just bumping this– anyone else seeing an issue here again? I’m considering taking a more aggressive approach, such as entirely disabling mt7921e before hibernating and re-enabling after resume.

4

I’ve had this problem continually since owning the FW 16 (5 months)
I’ve gotten into the habit of manually locking my session/screen before closing the lid. I’ve had a 100% success rate of returning from sleep since doing that.
I’ve got a FW 13 running the same OS (Fedora KDE Plasma) that has never, ever had this issue.

5

I use Hyprland, and I had a 100% success rate for a long time after applying @Matt_Hartley ‘s fix, but no longer it seems. Which kernel are you on?

I nearly always lock my screen too, using swaylock with Hyprland. Also, for anyone trying to reproduce, the issue seems intermittent. I lose my session on resume to the lock-up maybe 1/3 times I close the lid. I’m not sure if that’s because the hibernate issue is intermittent or if the other times the computer isn’t closed long enough to hibernate (I am using sleep-then-hibernate).

6

Current kernel is 6.16

The intermittent nature appears to be a timing/race issue. As near as I can tell from the logs, what happens is the user session starts its standby, then the OS-level starts its sleep. The lockup happens when the user session has not completed its standby before the OS sleeps. So, when the OS wakes back up, the User session picks up where it left off, by completing the session standby. :roll_eyes:
By locking manually first, it seems to prevent the race condition.

I don’t use hibernate at all, only sleep.

7

This might be a different issue then, and one related to the user session. When this happens, can you start a new session with Ctrl+Alt+F4?

8

No, the whole thing becomes unresponsive, no mouse/keyboard/network

9

What does the TTY say if you add no_console_suspend to the kernel arguments?

10

More aggressive, but this just worked:

Suspend:

$ cat /etc/systemd/system/bluetooth-rfkill-suspend.service
[Unit]
Description=Disable mt7921e on suspend/hibernate
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
ExecStart=modprobe -r mt7921e
ExecStartPost=/bin/sleep 3
RemainAfterExit=yes

[Install]
WantedBy=suspend.target hibernate.target suspend-then-hibernate.target

Resume

$ cat /etc/systemd/system/bluetooth-rfkill-resume.service 
[Unit]
Description=Enable mt7921e on resume
After=suspend.target hibernate.target suspend-then-hibernate.target

[Service]
Type=oneshot
ExecStart=modprobe mt7921e

[Install]
WantedBy=suspend.target hibernate.target suspend-then-hibernate.target
11

Hi,

There is another thread on here, that was solved by replacing the RAM chips.
I have no idea how a RAM chips could fail to resume, but it’s a possible cause.
I would probably aim to discount all other causes, e.g. wifi, Bluetooth, usb4/thunderbolt device first.