Hello dri-devel,
I encountered a strange hang during hibernation recently, and spent some time
tracking it down. What follows is the report, produced with assistance via
Codex/GPT 5.6 Sol.
I hope it may be helpful, and happy to provide any further info!
--------------------------------------------------------------------------------
A Framework Laptop 13 with an AMD Ryzen 7040 Series/Phoenix APU intermittently
hangs during hibernation. In the most recent occurrence, the first failure
visible on the kernel console was an amdxdna PCI restore timeout:
amdxdna 0000:c2:00.1: PM: dpm_run_callback(): pci_pm_restore returns -110
amdxdna 0000:c2:00.1: PM: failed to restore: error -110
This was followed by an unresponsive amdgpu SMU, failed GPU power-gating
operations, and a repeating AMD-PMF/ACPI AML timeout loop. The system remained
unresponsive and required a forced power-off.
Environment
===========
Hardware: Framework Laptop 13, AMD Ryzen 7040 Series (FRANMDCP05)
APU/GPU: AMD Phoenix1, PCI 1002:15bf, amdgpu
NPU: AMD IPU, PCI 1022:1502, amdxdna
BIOS: Framework 03.20, released 2026-06-23
OS: NixOS 26.05pre-git
Kernel: Linux 7.0.11
Sleep: s2idle followed by hibernation after 30 minutes
Hibernate mode: shutdown
pm_async: 0
The kernel was built with KASAN, lockdep, DEBUG_LIST, PM debug messages,
no_console_suspend, and ramoops. It also contained Thomas Hellström's v2
nested-sublists TTM patch for drm/amd#5387. I have not yet reproduced this
particular failure on an otherwise unmodified upstream kernel.
Sequence
========
1. systemd-suspend-then-hibernate entered s2idle.
2. The RTC woke the system after approximately 30 minutes.
3. s2idle resume completed successfully. amdgpu reported:
amdgpu 0000:c1:00.0: SMU is resumed successfully!
PM: resume of devices complete after 1356.807 msecs
PM: suspend exit
4. systemd immediately began hibernation:
systemd-sleep: Performing sleep operation 'hibernate'...
PM: hibernation: hibernation entry
Filesystems sync: 0.041 seconds
Freezing user space processes
5. The durable journal stops at that point because userspace and the filesystems
were frozen. The console subsequently showed the amdxdna restore timeout
quoted above.
6. The following failures then appeared:
usb usb5: root hub lost power or was reset
usb usb6: root hub lost power or was reset
usb usb7: root hub lost power or was reset
amdgpu 0000:c1:00.0: SMU: No response ...
amdgpu 0000:c1:00.0: Failed to enable gfxoff!
amdgpu 0000:c1:00.0: Failed to power gate JPEG!
amdgpu 0000:c1:00.0: [drm] *ERROR* Dpm disable jpeg failed, ret = -62
amdgpu 0000:c1:00.0: Failed to power gate VCN instance 0!
amdgpu 0000:c1:00.0: [drm] *ERROR* Dpm disable vcn failed, ret = -62
ACPI Error: Aborting method \_SB.A010 due to previous error
(AE_AML_LOOP_TIMEOUT)
ACPI Error: Aborting method \_SB.A032 due to previous error
(AE_AML_LOOP_TIMEOUT)
ACPI Error: Aborting method \_SB.ALIB due to previous error
(AE_AML_LOOP_TIMEOUT)
ACPI Error: Aborting method \_SB.APX8 due to previous error
(AE_AML_LOOP_TIMEOUT)
ACPI Error: Aborting method \_SB.PMF.PMF8 due to previous error
(AE_AML_LOOP_TIMEOUT)
ACPI Error: Aborting method \_SB.PMF.APMF due to previous error
(AE_AML_LOOP_TIMEOUT)
amd-pmf AMDI0102:00: APMF method:8 call failed
The ACPI/PMF group repeated approximately every 30 seconds.
Frequency and controls
======================
The failure is intermittent. An earlier full hibernate/resume cycle in the same
boot succeeded.
A similar terminal AMD-PMF/ACPI loop previously occurred on BIOS 03.17. The
recurrence on BIOS 03.20 shows that the current Framework firmware does not
prevent it, although only the latest occurrence captured the preceding amdxdna
restore failure.
No TTM/list-corruption report, KASAN finding, lockdep splat, or kernel panic was
observed. Ramoops remained empty because the system was forcibly powered off
without a panic.
The known amdxdna query/autosuspend deadlock fixed in Linux 7.0-rc2 should
already be fixed in this 7.0.11 kernel. Its documented trigger and behavior also
appear different.
Current assessment
==================
amdxdna is the leading isolation target because its restore timeout is the first
captured device callback failure. This does not prove that amdxdna caused the
platform failure: it may instead be the first consumer to observe an
already-unresponsive shared PSP/SMU or firmware path.
Not yet tested:
1. pm_test=freezer
2. pm_test=devices with amdxdna loaded
3. pm_test=devices after removing amdxdna
4. repeated hibernation on an unmodified current kernel
5. amd_pmf isolation if removing amdxdna does not change the result
Questions
=========
- Is pci_pm_restore returning -ETIMEDOUT on Phoenix a known amdxdna failure?
- Which amdxdna dynamic-debug messages or tracepoints would be most useful?
- Is removing or unbinding amdxdna before hibernation a valid isolation test?
- Could a failed NPU restore leave the shared firmware/SMU path in a state that
causes the subsequent amdgpu and AMD-PMF failures?
I posted a full incident report, configuration, and timeline on my personal
NixOS config repo:
https://github.com/samuela/nixos-config/issues/4#issuecomment-5174630789
Some related external reports found in the process of debugging:
- Older amdxdna suspend/hibernate failure:
https://github.com/amd/xdna-driver/issues/18
- Same later SMU/PMF failure cascade on another Framework 13 Phoenix system:
https://community.frame.work/t/fedora-40-on-the-framework-laptop-13/47746?page=3
- Same later cascade on a different AMD platform:
https://marc.info/?l=linux-media&m=175377491609096&w=2
Best,
Samuel Ainsworth
