[Bug]: s2idle suspend hangs on ASUS TUF Gaming A16 FA608PM (Ryzen 9 8940HX)

[Yousef-Alsaadan]

Affected Component

kernel (asus-armoury kernel driver)

Issue Description

Suspend never completes. The system enters s2idle and the journal stops dead —
no resume, no wake, no shutdown message. Fans spin up while the lid is closed
and the machine has to be force-powered-off with the power button. Battery
drains as if the machine were awake, which it effectively is.

Firmware offers s2idle only; S3 is not available. BIOS is FA608PM.321
(05/11/2026) and ASUS publishes no newer version.

Already ruled out — each tested independently, suspend hangs identically in
all three cases:

• modprobe.blacklist=nvidia,nvidia_modeset,nvidia_drm,nvidia_uvm → still hangs
• systemctl stop asusd before suspending → still hangs
• i2c_hid.polling_mode=1 → still hangs

So it is not the NVIDIA driver, not asusd, and not the I2C-HID polling path.

Possibly related: this machine also needed the LampArray workaround from #284 /
#119 for the keyboard backlight — same 0B05:19B6 ITE controller on I2C-HID, no
0b05 device in lsusb. Mentioning it in case platform/EC handling is a common
thread. The suspend hang occurs with or without that workaround active.

Steps to Reproduce

1. Boot normally to GNOME on Wayland.
2. Click Suspend from the system menu (or run: systemctl suspend).
3. Wait — screen goes dark, fans audibly spin up.
4. Press a key or the power button briefly to wake.
5. Nothing responds. Only a 15-second power-button hold recovers the machine.

Expected vs Actual Behavior

Expected: the system enters s2idle, quiesces, and resumes on keypress or lid
open with the session intact.

Actual: the system enters s2idle and never returns. The journal's final line is
"PM: suspend entry (s2idle)" with nothing after it — no PM: suspend exit, no
Restarting tasks. Fans run throughout. Recovery requires a forced power-off,
losing the session.

Laptop Model / Board Name

ASUS TUF Gaming A16 FA608PM_FA608PM (board: FA608PM)

Linux Distribution

Fedora Linux 44 (Workstation Edition)

Kernel Version

7.1.9-200.fc44.x86_64

asusctl / asusd / ROG Control Center Version

asusctl v6.4.0

Desktop Environment & Display Server

GNOME (Wayland)

Relevant Logs

Last lines before the hang:


systemd[1]: Reached target sleep.target - Sleep.
systemd[1]: Starting nvidia-suspend.service - NVIDIA system suspend actions...
systemd[1]: nvidia-suspend.service: Skipped due to 'exec-condition'.
systemd[1]: Starting systemd-suspend.service - System Suspend...
systemd-sleep[14744]: Performing sleep operation 'suspend'...
kernel: PM: suspend entry (s2idle)


Nothing follows.

Present at every boot:


kernel: NVRM: GPU0 ... PlatformRequestHandler failed to get target temp from SBIOS
kernel: NVRM: GPU0 ... PlatformRequestHandler failed to get platform power mode from SBIOS
asus_armoury: No matching power limits found for this system
asus_wmi: Initialization: 0x1
asus_wmi: SFUN value: 0x21
asus_wmi: fan_curve_get_factory_default (0x00110032) failed: -19


Hardware:


CPU:   AMD Ryzen 9 8940HX (Zen 4, 16C/32T)
GPU:   NVIDIA RTX 5060 Max-Q (driver 610.43.03) + AMD Radeon 610M
BIOS:  FA608PM.321 (05/11/2026)
Sleep: cat /sys/power/mem_sleep → [s2idle]

[NeroReflex]

Mmmmhhh why is the AI writing the affected component is asus-armoury?
Iin general s2idle cannot work if you don't configure the nvidia driver properly, disabling it won't fix the issue.

Have you ensured s0ix support is enabled in nVidia driver and nvidia-suspend is enabled?

[Yousef-Alsaadan]

LOL, i'm new with linux. so the AI will reply on my behalf.

I picked it because asus_armoury, asus_wmi, and the ITE controller all throw errors on this board and I wasn't sure where the boundary was. Happy for it to be re-labelled.

On the NVIDIA side: I did try enabling nvidia-suspend, nvidia-resume, and nvidia-hibernate together with NVreg_PreserveVideoMemoryAllocations=1 and NVreg_TemporaryFilePath=/var/tmp, then rebuilt the initramfs. Suspend still hung, and the hang got worse — the machine became unresponsive for longer before I force-powered it off. I reverted both changes.

The reason I then tested with the driver blacklisted entirely (modprobe.blacklist=nvidia,nvidia_modeset,nvidia_drm,nvidia_uvm) was to establish whether the GPU was involved at all. It hung identically with no NVIDIA modules loaded, which is what led me to look elsewhere. If s0ix can still fail with the driver fully out of the picture, I've misunderstood — happy to be corrected.

One detail that may matter: at every boot the driver reports it cannot read power state from firmware:

NVRM: GPU0 ... PlatformRequestHandler failed to get target temp from SBIOS
NVRM: GPU0 ... PlatformRequestHandler failed to get platform power mode from SBIOS

Is there a specific s0ix configuration you'd like me to test? I can run whatever you suggest and report back.

Driver is now 610.57.04 on kernel 7.1.9-200.fc44, module built and loaded, nvidia-smi reporting the GPU at P8 idle. Ready to test whatever configuration you suggest.

[NeroReflex]

Look the guide for configuring the nvidia on asus-linux.org website: you will need to make absolutely sure s0ix support is enabled. When that is true we can start talking about amd s2idle if the problem is still there.... Hopefully not.

asus-armoury is not involved in s2idle and the error you see is because you haven't yet sent screenshots of armoury crate to the asus ppt data collection thread (look in older issues here on github).

[Yousef-Alsaadan]

Ran amd-s2idle. Summary of findings:

Initial run (default config):
_SB.A018 → _SB.ALIB → \M277 → _SB.PCI0.GP17.ACP._PS3 all abort with AE_AML_LOOP_TIMEOUT. noirq suspend takes 30.3 s, then amd_pmc AMDI0008:00: SMU response timed out / suspend failed: -110. Hardware sleep residency 0.00% over an 80-second cycle.

On resume the SMU is still unreachable, so amdgpu fails with resume of IP block failed -62 and the iGPU driving the internal panel never comes back. That's why this presented as a hang — Restarting tasks: Done appears normally, there's just no display.

After blacklisting snd_pci_acp6x:
All AE_AML_LOOP_TIMEOUT errors are gone (count 0) and the 30-second noirq stall disappears. But SMU response timed out / suspend failed: -110 persists and amdgpu still dies on resume.

Since ALIB is the ACPI path to the SMU, the AML loop timeouts look like a downstream symptom of the SMU already being unresponsive rather than the cause.

Also ruled out: s0ix is confirmed Enabled (EnableS0ixPowerManagement: 1, Status: Enabled) and the failure is identical with the NVIDIA driver fully blacklisted.

Testing next with asus_wmi / asus_nb_wmi / asus_armoury blacklisted to see whether the ASUS platform driver is involved. Worth noting these throw errors at every boot: asus_wmi: fan_curve_get_factory_default (0x00110032) failed: -19 and asus_armoury: No matching power limits found for this system.

BIOS FA608PM.321 (05/11/2026), EC 3.21, kernel 7.1.9-200.fc44.x86_64, asusctl 6.3.11.

amd-s2idle-report-2026-08-24.md

[superm1]

To me this looks like platform firmware issue. If you're not on latest BIOS, please upgrade. If you're on latest BIOS, please report it to ASUS. You might try to reproduce on Windows too (you can use powercfg /sleepstudy to confirm you're getting to HW DRIPS - if you're not there is a problem there too).

[scardracs]

I took a look on it as I had some free time and it is caused by the BIOS as hypothesized (at least on version 321 that is the latest for this model).

1. EC Sleep/Wake and Wake-up Events are Locked Inside Windows-Only PEP DSM
   In ssdt10.dsl, the Power Engine Plugin device (_SB.PEP, AMDI0008 / PNP0D80) implements a Device-Specific Method (_DSM) for Microsoft PEP Notifications:

// ssdt10.dsl (lines 693-706 & 745-778)
Case (0x03) // S0i3 Entry (invoked by Windows PEP)
{
    M000 (0x3E03)
    \_SB.PCI0.SBRG.EC0.ECMD (0x97) // Tells EC to enter sleep mode
    \_SB.PCI0.SBRG.EC0.HBHT = One  // Heartbeat active
    Return (Zero)
}
Case (0x04) // S0i3 Exit
{
    M000 (0x3E04)
    \_SB.PCI0.SBRG.EC0.ECMD (0x99)
    \_SB.PCI0.SBRG.EC0.HBHT = Zero
    Return (Zero)
}
Case (0x07) / Case (0x08) // Wake cleanup & Device Notifications
{
    Notify (\_SB.PCI0.GPP1.NVME, One)
    Notify (\_SB.PCI0.GPP7.NVME, One)
    Notify (\_SB.PCI0.GP19.XHC2, One)
    \_SB.PCI0.SBRG.EC0.ECMD (0x98)
    \_SB.PCI0.SBRG.EC0.ECMD (0x86)
}

Linux s2idle does not execute this proprietary Microsoft PEP notification DSM.

• The Embedded Controller (EC0) never receives command 0x97 to quiesce.
• The EC remains in an active state expecting regular thermal/heartbeat responses from the CPU.
• When Linux halts the CPU cores for s2idle, the EC detects the sudden loss of CPU communication and triggers its hardware watchdog/fail-safe, spinning the fans up to full speed.
• Device wake interrupts for NVMe and USB (GPP1, GPP7, GP19.XHC2) are routed through these PEP DSM notification callbacks rather than standard ACPI GPEs, leaving the machine unable to wake upon keypress or lid open.

2. Missing AMD PMC Device (AMDI0005)
   On modern AMD platforms, the Linux amd-pmc driver requires the AMDI0005 (or AMDI0006/AMDI0007) ACPI object to coordinate S0i3 transitions with the AMD SMU.

• In BIOS 321, AMDI0005 is completely absent from the ACPI tables. As a result, amd-pmc cannot bind or issue SMU sleep commands, preventing the SoC power rails from entering the lowest hardware sleep states.

3. Dummy / Uninitialized _LPI Tables

• In ssdt35.dsl (CPMMSLPI) and ssdt36.dsl (MSLPIDIS), the Low Power Idle table (_LPI) defines S0i3 with zeroed system memory registers:
  Register (SystemMemory, 0x00, 0x00, 0x0000000000000000, )
  so no valid coordinates or hardware residency counters are registered.

4. Dragon Range (Zen 4 HX) Hardware Mismatch
   The Ryzen 9 8940HX is an MCM processor (Zen 4 CCDs + desktop IOD), not a monolithic mobile APU:

• The desktop IOD does not have native mobile S0i3 hardware power gating and is designed for standard ACPI S3 (Suspend-to-RAM).
• While Name (_S3, Package (0x04) { 0x03, Zero, Zero, Zero }) exists in DSDT, the FADT flags enforce Modern Standby (s2idle) for Windows certification, leaving Linux caught between an incomplete S0i3 implementation and a disabled S3.

5. Confirmation of WMI Fan Curve Error in Logs
   The log line asus_wmi: fan_curve_get_factory_default (0x00110032) failed: -19 is also explained in dsdt.dsl (lines 9576 & 10372):

If ((IIA0 == 0x00110032))
{
    Return (0xFFFFFFFE) // Returns -2, which maps to -ENODEV (-19) in Linux WMI
}

[superm1]

Did you have an agent build that hypothesis from a kernel check-out? Because a lot of it is definitely wrong.

[scardracs]

Did you have an agent build that hypothesis from a kernel check-out? Because a lot of it is definitely wrong.

Yes, sorry. I confrontened the FA608PM ACPI tables aginst my laptop (G614PR, same CPU) at hand and ended up finding that:

G614PR, working on linux (ssdt21.dsl)

                        Case (0x03)
                        {
                            M000 (0x3E03)
                            M460 ("   aaron Return (0x00)\n", Zero, Zero, Zero, Zero, Zero, Zero)
                            \_SB.PCI0.SBRG.MSFN = 0x03
                            \_SB.PCI0.SBRG.MSCK = One
                            \_SB.PCI0.SBRG.HOTF = One
                            \_SB.PCI0.SBRG.ALED (Zero)
                            \_SB.PCI0.SBRG.MS01 (\_SB.PCI0.SBRG.MDSA, \_SB.PCI0.SBRG.MDSE)
                            Return (Zero)
                        }

                        Case (0x07)
                        {
                            M000 (0x3E07)
                            \_SB.PCI0.SBRG.MSFN = 0x07
                            \_SB.PCI0.SBRG.MSIN = One
                            Return (Zero)
                        }

Function 7 only sets a state flag (MSIN = 1). The Embedded Controller goes to sleep smoothly, and the system suspends cleanly.

FA608PM, buggy (ssdt10.dsl)

                        Case (0x03)
                        {
                            M000 (0x3E03)
                            \_SB.PCI0.SBRG.EC0.ECMD (0x97)
                            \_SB.PCI0.SBRG.EC0.HBHT = One
                            Return (Zero)
                        }

                        Case (0x07)
                        {
                            M000 (0x3E07)
                            If (CondRefOf (\_SB.PCI0.GPP1.NVME))
                            {
                                Notify (\_SB.PCI0.GPP1.NVME, One) // Device Check
                            }

                            If (CondRefOf (\_SB.PCI0.GPP7.NVME))
                            {
                                Notify (\_SB.PCI0.GPP7.NVME, One) // Device Check
                            }

                            \_SB.PCI0.SBRG.EC0.ECMD (0x98)
                            Return (Zero)
                        }