Device Information
System Model or SKU
Mainboard: FRANMDCP05
BIOS VERSION
03.20 (released 2026-06-23)
The same terminal failure also occurred on BIOS 03.17.
DIY Edition information
Memory: Crucial 32GB Laptop DDR5-5600 MHz SO-DIMM; B&H SKU CR32G56C46S5
Storage: Western Digital WD_BLACK SN850X 2 TB
Port/Peripheral information
No peripheral has been identified as contributing to the failure.
- USB-C Expansion Card
- USB-C Expansion Card
- USB-C Expansion Card
- USB-C Expansion Card
Standalone Operation (Laptop Only)
Describe the bug
The laptop has twice become permanently unresponsive while systemd-suspend-then-hibernate transitioned from s2idle to hibernation. Recovery required holding the power button, losing the active session and creating filesystem-integrity risk.
Occurrences:
- 2026-07-27 on BIOS 03.17
- 2026-08-03 on BIOS 03.20
The recurrence demonstrates that BIOS 03.20 does not prevent this failure.
During the BIOS 03.20 occurrence, s2idle resumed successfully and amdgpu reported that the SMU had resumed. Hibernation then began. The first failure captured on the kernel console was the AMD NPU timing out in its PCI restore callback:
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 USB root-hub resets, an unresponsive amdgpu SMU, failed GPU power-gating operations, and repeating AMD-PMF/ACPI errors:
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/AMD-PMF group repeated approximately every 30 seconds until the forced shutdown.
The Linux amdxdna maintainers have been notified in this public thread:
https://lore.kernel.org/dri-devel/CAHYiNPZtDJ1ftQ4-uxc4mFQLRKL_dEXK4f=0FmBWOX96b4%2B7mw@mail.gmail.com/
Because the failure crosses the NPU, GPU SMU, AMD-PMF, and ACPI interfaces, I am asking Framework to investigate whether a BIOS/AGESA/platform-firmware problem could leave the shared AMD firmware or power-management path unresponsive, and to coordinate with AMD and the kernel maintainers as appropriate.
Steps To Reproduce
The failure is intermittent.
- Boot the Framework Laptop 13 AMD 7040 on BIOS 03.20.
- Configure systemd suspend-then-hibernate with a 30-minute hibernation delay.
- Configure hibernation mode as shutdown.
- Run systemctl suspend-then-hibernate.
- Allow the machine to remain in s2idle until the RTC wake initiates hibernation.
- On a failing attempt, the console begins printing the errors above and the machine never powers off or returns to userspace.
An earlier complete hibernate/resume cycle during the same boot succeeded, so a single successful cycle does not exclude the problem.
Expected behavior
After the configured s2idle interval, the laptop should create a valid hibernation image, power off, and restore the session on the next boot without device, SMU, AMD-PMF, or ACPI timeouts.
Screenshots
A kernel-console photograph from the August 3 occurrence is available and will be attached in a follow-up comment because the GitHub CLI does not support uploading issue attachments.
Operating System
- OS/Distribution: NixOS 26.05pre-git
- Kernel: Linux 7.0.11
- Desktop/session: niri on Wayland
- Hibernation mode: shutdown
- /sys/power/pm_async: 0
Additional context
Full incident history, configuration, timeline, and captured logs:
samuela/nixos-config#4
Canonical Linux-kernel report:
https://lore.kernel.org/dri-devel/CAHYiNPZtDJ1ftQ4-uxc4mFQLRKL_dEXK4f=0FmBWOX96b4%2B7mw@mail.gmail.com/
A separate Framework Laptop 13 AMD 7040 report on BIOS 03.05 contains the same later SMU failure, AE_AML_LOOP_TIMEOUT, and amd-pmf APMF method:8 failure cascade, although its trigger was an amdgpu hang rather than hibernation:
https://community.frame.work/t/fedora-40-on-the-framework-laptop-13/47746?page=3
The captured recurrence used a debug kernel with KASAN, lockdep, DEBUG_LIST, PM diagnostics, ramoops, and a proposed amdgpu TTM patch. The system has not yet reproduced this specific failure on an otherwise unmodified upstream kernel. No TTM/list-corruption report, KASAN finding, lockdep splat, or kernel panic occurred.
The first visible failure being amdxdna does not prove that the NPU driver caused the problem. It may instead be the first device to observe an already unresponsive shared firmware path.
Device Information
System Model or SKU
Mainboard: FRANMDCP05
BIOS VERSION
03.20 (released 2026-06-23)
The same terminal failure also occurred on BIOS 03.17.
DIY Edition information
Memory: Crucial 32GB Laptop DDR5-5600 MHz SO-DIMM; B&H SKU CR32G56C46S5
Storage: Western Digital WD_BLACK SN850X 2 TB
Port/Peripheral information
No peripheral has been identified as contributing to the failure.
Standalone Operation (Laptop Only)
Describe the bug
The laptop has twice become permanently unresponsive while systemd-suspend-then-hibernate transitioned from s2idle to hibernation. Recovery required holding the power button, losing the active session and creating filesystem-integrity risk.
Occurrences:
The recurrence demonstrates that BIOS 03.20 does not prevent this failure.
During the BIOS 03.20 occurrence, s2idle resumed successfully and amdgpu reported that the SMU had resumed. Hibernation then began. The first failure captured on the kernel console was the AMD NPU timing out in its PCI restore callback:
This was followed by USB root-hub resets, an unresponsive amdgpu SMU, failed GPU power-gating operations, and repeating AMD-PMF/ACPI errors:
The ACPI/AMD-PMF group repeated approximately every 30 seconds until the forced shutdown.
The Linux amdxdna maintainers have been notified in this public thread:
https://lore.kernel.org/dri-devel/CAHYiNPZtDJ1ftQ4-uxc4mFQLRKL_dEXK4f=0FmBWOX96b4%2B7mw@mail.gmail.com/
Because the failure crosses the NPU, GPU SMU, AMD-PMF, and ACPI interfaces, I am asking Framework to investigate whether a BIOS/AGESA/platform-firmware problem could leave the shared AMD firmware or power-management path unresponsive, and to coordinate with AMD and the kernel maintainers as appropriate.
Steps To Reproduce
The failure is intermittent.
An earlier complete hibernate/resume cycle during the same boot succeeded, so a single successful cycle does not exclude the problem.
Expected behavior
After the configured s2idle interval, the laptop should create a valid hibernation image, power off, and restore the session on the next boot without device, SMU, AMD-PMF, or ACPI timeouts.
Screenshots
A kernel-console photograph from the August 3 occurrence is available and will be attached in a follow-up comment because the GitHub CLI does not support uploading issue attachments.
Operating System
Additional context
Full incident history, configuration, timeline, and captured logs:
samuela/nixos-config#4
Canonical Linux-kernel report:
https://lore.kernel.org/dri-devel/CAHYiNPZtDJ1ftQ4-uxc4mFQLRKL_dEXK4f=0FmBWOX96b4%2B7mw@mail.gmail.com/
A separate Framework Laptop 13 AMD 7040 report on BIOS 03.05 contains the same later SMU failure, AE_AML_LOOP_TIMEOUT, and amd-pmf APMF method:8 failure cascade, although its trigger was an amdgpu hang rather than hibernation:
https://community.frame.work/t/fedora-40-on-the-framework-laptop-13/47746?page=3
The captured recurrence used a debug kernel with KASAN, lockdep, DEBUG_LIST, PM diagnostics, ramoops, and a proposed amdgpu TTM patch. The system has not yet reproduced this specific failure on an otherwise unmodified upstream kernel. No TTM/list-corruption report, KASAN finding, lockdep splat, or kernel panic occurred.
The first visible failure being amdxdna does not prove that the NPU driver caused the problem. It may instead be the first device to observe an already unresponsive shared firmware path.