Zenbook S 16 with Ryzen HX AI 370 not reaching s2idle.

I've been trying to debug high power usage on suspend (~30%/day, https://github.com/BNieuwenhuizen/zenbook-s16?tab=readme-ov-file#standby-battery-duration), and tried to debug this through amd_s2idle.py. It indicates that the laptop actually doesn't reach s2idle:

$ sudo python amd_s2idle.py 
Location of log file (default s2idle_report-2024-08-09.txt)? 
Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ASUS Zenbook S 16 UM5606WA_UM5606WA (ASUS Zenbook S 16) running BIOS 5.35 (UM5606WA.308) released 07/17/2024 and EC 3.22
🐧 Arch Linux
🐧 Kernel 6.11.0-rc1-1-git-00269-gd9ef02e56f0f
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 100.86% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.9.0)
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.6
✅ System is configured for s2idle
✅ NVME Micron Technology Inc 2400 NVMe SSD (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU properly configured
How long should suspend cycles last in seconds (default 10)? 600
How long to wait in between suspend cycles in seconds (default 4)? 
How many suspend cycles to run (default 1)? 
Started at 2024-08-09 22:18:12.742055 (cycle finish expected @ 2024-08-09 22:28:16.742069)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ Wakeup triggered from IRQ 9: ACPI SCI
○ Woke up from IRQ 9: ACPI SCI
○ gpe10 increased from 180 to 186
✅ Userspace suspended for 0:10:18.052243
❌ Did not reach hardware sleep state
🔋 Battery BAT0 lost 585000 µWh (0.74%) [Average rate 0.34W]

At this point I'm not sure what can prevent the HW from reaching s2idle and since apparently the SMU seems to be involved looking at the source of the amd_s2idle.py script, I thought it was worth reporting here.

The full log is attached. s2idle_report-2024-08-09.txt

The issue seems to happen every suspend cycle I've tried (will try multiple boot cycles in a bit).

added Strix s0ix labels

Please attach your dmesg output.

suspend_dmesg.txt

Hmm, just noticed that I get the following on my first suspend:

[  110.237880] ACPI: \_SB_.PCI0.GPP0.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
[  110.237887] ACPI: \_SB_.PCI0.GPP1.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0
[  110.237892] ACPI: \_SB_.PCI0.GPP5.WLAN: LPI: Device not power manageable
[  110.237902] ACPI: \_SB_.PCI0.GPPB.IPU_: LPI: Device not power manageable
[  110.237911] ACPI: \_SB_.PLTF.C000: LPI: Device not power manageable
[  110.237913] ACPI: \_SB_.PLTF.C001: LPI: Device not power manageable
[  110.237916] ACPI: \_SB_.PLTF.C002: LPI: Device not power manageable
[  110.237918] ACPI: \_SB_.PLTF.C003: LPI: Device not power manageable
[  110.237921] ACPI: \_SB_.PLTF.C004: LPI: Device not power manageable
[  110.237924] ACPI: \_SB_.PLTF.C005: LPI: Device not power manageable
[  110.237926] ACPI: \_SB_.PLTF.C006: LPI: Device not power manageable
[  110.237928] ACPI: \_SB_.PLTF.C007: LPI: Device not power manageable
[  110.237931] ACPI: \_SB_.PLTF.C008: LPI: Device not power manageable
[  110.237934] ACPI: \_SB_.PLTF.C009: LPI: Device not power manageable
[  110.237936] ACPI: \_SB_.PLTF.C00A: LPI: Device not power manageable
[  110.237939] ACPI: \_SB_.PLTF.C00B: LPI: Device not power manageable
[  110.237941] ACPI: \_SB_.PLTF.C00C: LPI: Device not power manageable
[  110.237944] ACPI: \_SB_.PLTF.C00D: LPI: Device not power manageable
[  110.237946] ACPI: \_SB_.PLTF.C00E: LPI: Device not power manageable
[  110.237949] ACPI: \_SB_.PLTF.C00F: LPI: Device not power manageable
[  110.237951] ACPI: \_SB_.PLTF.C010: LPI: Device not power manageable
[  110.237953] ACPI: \_SB_.PLTF.C011: LPI: Device not power manageable
[  110.237956] ACPI: \_SB_.PLTF.C012: LPI: Device not power manageable
[  110.237958] ACPI: \_SB_.PLTF.C013: LPI: Device not power manageable
[  110.237961] ACPI: \_SB_.PLTF.C014: LPI: Device not power manageable
[  110.237962] ACPI: \_SB_.PLTF.C015: LPI: Device not power manageable
[  110.237965] ACPI: \_SB_.PLTF.C016: LPI: Device not power manageable
[  110.237967] ACPI: \_SB_.PLTF.C017: LPI: Device not power manageable
[  110.239362] ACPI: \_SB_.PEP_: Successfully transitioned to state screen off
[  110.240391] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 ms entry
[  110.240616] ACPI: \_SB_.PEP_: Successfully transitioned to state lps0 entry

Seems more ACPI than I'd like so I dsdt.dsl also attached my ACP DSDT in case it helps ...

changed title from Zenbook S 16 with Rayzen HX AI 370 not reaching s2idle. to Zenbook S 16 with Ryzen HX AI 370 not reaching s2idle.

FYI for best power savings at runtime you'll probably want to pick this up.

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git/commit/?id=c35fad6f7e0d69b0e9e7e196bdbca3ed03ac24ea

0xffef9add

I think you're missing some of the IPS optimization patches that came in later 6.11.

https://github.com/torvalds/linux/commit/f6098641d3e1e4d4052ff9378857c831f9675f6b

Can you repro with 6.11-rc4 or later?

I tested with 6.11-rc4 + the patch linked and it seems to help, the script now says I'm reaching sleep state and my keyboard backlight turns off while suspended.

Also tested, I still get a freeze for about 10 seconds after resuming from suspending, but now the keyboard turns off properly when suspended!

Also tested, I still get a freeze for about 10 seconds after resuming from suspending, but now the keyboard turns off properly when suspended!

@bnieuwenhuizen do you see this too?

@ThatOneCalculator if you turn off PSR and panel replay does this help?

No, I've had PSR turned off for almost two weeks now and it's stopped every other freeze except for the resume-from-suspend freeze.

yeah I also have the freeze (black screen for ~10 seconds, keyboard backlight is on) for 10 seconds or so on resume. PSR is off with the amdgpu.dcdebugmask=0x600, I don't know if that disables panel replay? If not can you give instructions?

enum DC_DEBUG_MASK {
	DC_DISABLE_PIPE_SPLIT = 0x1,
	DC_DISABLE_STUTTER = 0x2,
	DC_DISABLE_DSC = 0x4,
	DC_DISABLE_CLOCK_GATING = 0x8,
	DC_DISABLE_PSR = 0x10,
	DC_FORCE_SUBVP_MCLK_SWITCH = 0x20,
	DC_DISABLE_MPO = 0x40,
	DC_ENABLE_DPIA_TRACE = 0x80,
	DC_ENABLE_DML2 = 0x100,
	DC_DISABLE_PSR_SU = 0x200,
	DC_DISABLE_REPLAY = 0x400,
	DC_DISABLE_IPS = 0x800,
};

That mask (0x610) is turning off PSR-SU and replay. It should be 0x610 for PSR, PSR-SU and replay.

But these are all power saving features, I would only turn them off for debugging purposes. File more bugs if they're broken on your system.

If they're working properly, you should leave them on.

yeah I also have the freeze (black screen for ~10 seconds, keyboard backlight is on) for 10 seconds or so on resume.

Can you share an s2idle report with the 6.11-rc4 + that ACP patch and we can see if anything stands out in the log? Please also set /sys/power/pm_print_times to 1 before you run amd_s2idle.py so we can get some more timing information.

But these are all power saving features, I would only turn them off for debugging purposes. File more bugs if they're broken on your system.

This was recommended by AMD to Phoronix to avoid some system hangs, and it helped for us too (https://www.phoronix.com/review/amd-radeon-890m-rdna35), so I was assuming AMD was on it. Will file if there is not a public bug on it yet .

I had thought the updated DMCUB firmware fixed it though. If it hasn't that's news to me; so yes another bug please.

I and @ThatOneCalculator are not using the last version of the DMCUB firmware version because it introduces new hangs for both of us. @ThatOneCalculator has an email thread about that going, might be worth moving that to a bug here.

Please don't speak on my behalf -- I am using the latest DMCUB firmware.

Oops, was just looking it up, apologies.

(edit: looks like I missed linux-firmware-git hd another DMCUB update 10 days ago)

Yes; if there is a regression in the DMCUB binary, please a get dedicated bug opened for it and ping it here.

For reference, here's my output & log:

Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ASUS Zenbook S 16 UM5606WA_UM5606WA (ASUS Zenbook S 16) running BIOS 5.35 (UM5606WA.304) released 06/17/2024 and EC 3.19
🐧 EndeavourOS
🐧 Kernel 6.11.0-rc4-2-mainline-um5606-dirty
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 100.83% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.4.0)
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.6
✅ System is configured for s2idle
✅ NVME Micron Technology Inc 2400 NVMe SSD (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU properly configured
How long should suspend cycles last in seconds (default 10)?
How long to wait in between suspend cycles in seconds (default 4)?
How many suspend cycles to run (default 1)?
Started at 2024-08-22 08:56:21.320433 (cycle finish expected @ 2024-08-22 08:56:35.320448)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ GPIOs active: ['8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8']
○ Wakeup triggered from IRQ 9: ACPI SCI
○ Woke up from IRQ 9: ACPI SCI
○ gpe10 increased from 41 to 67
✅ Userspace suspended for 0:00:24.503791
✅ In a hardware sleep state for 0:00:07.665802 (31.28%)
🔋 Battery BAT0 lost 200000 µWh (0.25%) [Average rate 2.94W]

s2idle_report-2024-08-22.txt

Can you try disabling the IOMMU with amd_iommu=off? Does this help the 10s delay?

And if it doesn't, please provide the same report with /sys/power/pm_print_times also set.

Apologies for the late reply. Disabling the IOMMU with amd_iommu=off didn't help, the output does seem a bit different though. I don't know how to set /sys/power/pm_print_times. However, running with amd_iommu=off gave me a lot more GPIOs:

Location of log file (default s2idle_report-2024-08-23.txt)?
Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ASUS Zenbook S 16 UM5606WA_UM5606WA (ASUS Zenbook S 16) running BIOS 5.35 (UM5606WA.304) released 06/17/2024 and EC 3.19
🐧 EndeavourOS
🐧 Kernel 6.11.0-rc4-2-mainline-um5606-dirty
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 101.37% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.4.0)
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.6
✅ System is configured for s2idle
✅ NVME Micron Technology Inc 2400 NVMe SSD (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU properly configured
How long should suspend cycles last in seconds (default 10)?
How long to wait in between suspend cycles in seconds (default 4)?
How many suspend cycles to run (default 1)?
Started at 2024-08-23 23:11:30.830193 (cycle finish expected @ 2024-08-23 23:11:44.830209)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ GPIOs active: ['8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8']
○ Wakeup triggered from IRQ 9: ACPI SCI
○ Woke up from IRQ 9: ACPI SCI
○ gpe10 increased from 37 to 43
✅ Userspace suspended for 0:00:24.313897
✅ In a hardware sleep state for 0:00:07.487945 (30.80%)
🔋 Battery BAT0 lost 72000 µWh (0.09%) [Average rate 1.07W]

s2idle_report-2024-08-23.txt

I don't know how to set /sys/power/pm_print_times

echo 1 | sudo tee /sys/power/pm_print_times

Ah gotcha, I'll be able to test that in a few hours :)

Upgrading now, will lyk how it goes 🫡

Sorry about that, my laptop felt that it'd be a perfect time to stop recognizing my Wifi, so having a bit of trouble upgrading :/

@superm1 here we go -- new output & log:

Location of log file (default s2idle_report-2024-08-27.txt)?
Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ASUS Zenbook S 16 UM5606WA_UM5606WA (ASUS Zenbook S 16) running BIOS 5.35 (UM5606WA.304) released 06/17/2024 and EC 3.19
🐧 EndeavourOS
🐧 Kernel 6.11.0-rc5-1-mainline-um5606-dirty
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 101.41% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.4.0)
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.6
✅ System is configured for s2idle
✅ NVME Micron Technology Inc 2400 NVMe SSD (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU properly configured
How long should suspend cycles last in seconds (default 10)?
How long to wait in between suspend cycles in seconds (default 4)?
How many suspend cycles to run (default 1)?
Started at 2024-08-27 16:55:19.294969 (cycle finish expected @ 2024-08-27 16:55:33.294981)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ GPIOs active: ['8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8', '8']
○ Wakeup triggered from IRQ 9: ACPI SCI
○ Woke up from IRQ 9: ACPI SCI
○ gpe10 increased from 45 to 51
✅ Userspace suspended for 0:00:24.884732
✅ In a hardware sleep state for 0:00:08.588897 (34.51%)
🔋 Battery BAT0 lost 80000 µWh (0.10%) [Average rate 1.16W]

s2idle_report-2024-08-27.txt

@superm1 thoughts?

@ThatOneCalculator can you see if the comments from @PisonJay apply to your system too?

@superm1 for some reason, my email notifications aren't working, just saw this rn. I'm recompiling the kernel rn to test!

Tried, but it didn't change that much

Hi,

I am observing the (about) 10 seconds freeze as well on the same hardware. I have attached my report with 4.12-rc3 and these kernel arguments : "amdgpu.dcdebugmask=0x610 amd_iommu=off".

Was an issue already created for the system freezes from PSR? I am asking because I am seeing those freezes as well without that amdgpu.dcdebugmask=0x600.

s2idle_report-2024-10-21.txt

Hello, here is my output on MEA um5606wa

Location of log file (default s2idle_report-2024-08-27.txt)? 
Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ASUS Zenbook S 16 UM5606WA_UM5606WA (ASUS Zenbook S 16) running BIOS 5.35 (UM5606WA.308) released 07/17/2024 and EC 3.22
🐧 Gentoo Linux
🐧 Kernel 6.11.0-rc5-x86_64
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 100.70% of design
Checking prerequisites for s2idle
🚦Logs are provided via dmesg, timestamps may not be accurate over multiple cycles
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.9.0)
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c6:00.6
❌ GPU firmware missing
✅ System is configured for s2idle
✅ NVME Sandisk Corp WD Black SN770 / PC SN740 256GB / PC SN560 (DRAM-less) NVMe SSD is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
🚦 Device firmware checks unavailable without fwupd gobject introspection
✅ IOMMU properly configured
Your system does not meet s2idle prerequisites!
Explanations for your system
🚦 AMDGPU firmware is missing
        The amdgpu driver loads firmware from /lib/firmware/amdgpu
        In some cases missing firmware will prevent a successful suspend cycle.
        Upgrade to a newer snapshot at https://gitlab.com/kernel-firmware/linux-firmware
        amdgpu 0000:c4:00.0: Direct firmware load for amdgpu/isp_4_1_0.bin failed with error -2
For more information on this failure see:
        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053856

Where to find the isp_4_1_0.bin? It's not on firmware git.

I think we should make an exclusion for that firmware binary in the script, it's totally optional. Can you run with --force and see if there is any other issues reported? Please attach the text file generated.

I've updated the script to exclude the ISP binary.

I got my first successful suspend in a while. I have just recompiled the kernel to enable the PM debug, and ACPI error report store. Maybe it was that that did something.

s2idle_report-2024-08-27.txt

Now, something different happened: grey screen on resume, blinking keyboard. Judging by the sound still playing, the rest of the system was still operational.

Is there a way to output printk on AMD systems through the USB port debug mode like on Intel chips?

Wait, what?

2024-08-27 21:39:18,808 DEBUG:	PM: suspend entry (deep)
2024-08-27 21:39:18,808 DEBUG:	PM: suspend exit
2024-08-27 21:39:18,808 DEBUG:	PM: suspend entry (deep)
2024-08-27 21:39:18,808 DEBUG:	PM: suspend exit

Have you modified your firmware in some way? Or is this only because of mem_sleep_default=deep on your kernel command line? We don't support deep on modern mobile APUs.

Is there a way to output printk on AMD systems through the USB port debug mode like on Intel chips?

It depends on how the OEM design is put together whether this would work. You can certainly try if there is such a port on the OEM design.

Now, something different happened: grey screen on resume, blinking keyboard. Judging by the sound still playing, the rest of the system was still operational.

That's pretty weird. Do you have a journal to go with it from that boot?

That's pretty weird. Do you have a journal to go with it from that boot?

Yes. I ran it 10 times. Some times the picture returned, some times, grey screen. The last time it returned, but froze. I was able to CTRL+F1 to console, but return to X froze the display.

s2idle_report-2024-08-27.txt

After reboot by sysrq, bluetooth started to segfault, and system froze after a while (still sysrq rebootable). Dmesg:

bt

Does this part of the log correspond with the time you had a grey screen?

2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:52:39,765460+04:00 amdgpu 0000:c4:00.0: [drm] *ERROR* [CRTC:79:crtc-0] flip_done timed out
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:52:41,301745+04:00 [drm:amdgpu_dm_atomic_check] *ERROR* [CRTC:79:crtc-0] hw_done or flip_done timed out
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:52:51,542009+04:00 amdgpu 0000:c4:00.0: [drm] *ERROR* flip_done timed out
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:52:51,542016+04:00 amdgpu 0000:c4:00.0: [drm] *ERROR* [CRTC:79:crtc-0] commit wait timed out
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:53:01,781716+04:00 amdgpu 0000:c4:00.0: [drm] *ERROR* flip_done timed out
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:53:01,781722+04:00 amdgpu 0000:c4:00.0: [drm] *ERROR* [PLANE:58:plane-3] commit wait timed out
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:53:02,210583+04:00 PM: suspend of devices aborted after 30953.852 msecs
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:53:02,210590+04:00 PM: start suspend of devices aborted after 30953.989 msecs
2024-08-27 21:52:38,777 DEBUG:	2024-08-27T21:53:02,210592+04:00 PM: Some devices failed to suspend, or early wake event detected

After reboot by sysrq, bluetooth started to segfault, and system froze after a while (still sysrq rebootable). Dmesg:

This looks like a separate problem with the BT/WLAN controller.

After reboot by sysrq, bluetooth started to segfault, and system froze after a while (still sysrq rebootable). Dmesg:

That was fixed by 4 second power button, and boot to windows, and back to linux.

Does this part of the log correspond with the time you had a grey screen?

I think yes, given that during these 10 suspends, it happened multiple times

I think yes, given that during these 10 suspends, it happened multiple times

These look to me to be aborted suspends that didn't actually complete. I feel this is a separate bug from what was originally raised here. Something appears wrong with the display controller at this time that it's getting all of these timeouts. @ThatOneCalculator and @bnieuwenhuizen have you seen this at all too?

I guess you specifically were using the script and nothing notably different in your userspace setup during those attempts? Is this only happening in X? Or Wayland trips it too?

A gray screen? Nope, never. I am exclusively on Wayland though.

I notice a different EC version between @NOA_Labs and @ThatOneCalculator. @NOA_Labs can you please update your EC to latest?

I see it's 3.19 on their logs, and 3.22 on mine. How do I roll back?

Hmm, I'm not sure if they let you roll back or not. I guess another way to look is @ThatOneCalculator can check if upgrading things still work?

@ThatOneCalculator do you have a touchscreen model or one without digitizer? I know they have some difference in peripheral chips, different buck controller chips, etc.

Mine has a touchscreen, yeah. Finishing up lunch now, give me 10 mins and I'll be able to check everything

Mine doesn't have a touchscreen and I haven't had any resume errors that I can remember (though I also haven't done 10 in a row, think I've done 5 per boot at most at this point)

Can you check your OLED panel model number?

I never tried Wayland before.

I tied now with all power management disabled, and naked X session.

First suspend — grey screen, 2-5 OK, 6-7 grey screen, 8 ok, 9-10 grey screen

s2idle_report-2024-08-27.txt

20240828_003600.mp4

You can download it separately. I think the embedded player can't digest it

I can confirm now that the grey screen condition can happen by itself, without suspend.

I too am experiencing this issue:

Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ProArt PX13 HN7306WU_HN7306WU (ProArt PX13) running BIOS 5.35 (HN7306WU.308) released 07/22/2024 and EC 3.17
🐧 CachyOS
🐧 Kernel 6.11.0-rc5-2-cachyos-rc
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 98.97% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.9.0)
✅ USB4 driver `thunderbolt` bound to 0000:c7:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c7:00.6
✅ System is configured for s2idle
✅ NVME Sandisk Corp PC SN740 NVMe SSD (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU properly configured
How long should suspend cycles last in seconds (default 10)? 
How long to wait in between suspend cycles in seconds (default 4)? 
How many suspend cycles to run (default 1)?  
Started at 2024-08-30 15:00:59.539532 (cycle finish expected @ 2024-08-30 15:01:13.539555)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ Wakeup triggered from IRQ 9: ACPI SCI
○ Woke up from IRQ 9: ACPI SCI
○ gpe10 increased from 31 to 37
✅ Userspace suspended for 0:00:12.062162
❌ Did not reach hardware sleep state
🔋 Battery BAT0 lost 31000 µWh (0.04%) [Average rate 0.93W]

I just pulled the latest linux-firmware-git as of today.

s2idle_report-2024-08-30.txt

In your case DCN is not in the right low power state, which is odd because you have https://github.com/torvalds/linux/commit/f6098641d3e1e4d4052ff9378857c831f9675f6b (the fix for this).

I wonder if you're seeing a regression in https://gitlab.com/kernel-firmware/linux-firmware/-/commit/bec4fd18cc57b262241cd4578ed4533ca23ed0c3. Can you try to revert to https://gitlab.com/kernel-firmware/linux-firmware/-/commit/0600ef249c32e761d2f31d50fddc4f17e6676849?

I reverted to the commit you suggested and am still getting the same:

Location of log file (default s2idle_report-2024-08-31.txt)? 
Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ProArt PX13 HN7306WU_HN7306WU (ProArt PX13) running BIOS 5.35 (HN7306WU.308) released 07/22/2024 and EC 3.17
🐧 CachyOS
🐧 Kernel 6.11.0-rc5-2-cachyos-rc
🔋 Battery BAT0 (ASUSTeK ASUS Battery) is operating at 99.02% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 HX 370 w/ Radeon 890M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.9.0)
✅ USB4 driver `thunderbolt` bound to 0000:c7:00.5
✅ USB4 driver `thunderbolt` bound to 0000:c7:00.6
✅ System is configured for s2idle
✅ NVME Sandisk Corp PC SN740 NVMe SSD (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU properly configured
How long should suspend cycles last in seconds (default 10)? 
How long to wait in between suspend cycles in seconds (default 4)? 
How many suspend cycles to run (default 1)? 
Started at 2024-08-31 05:53:01.691633 (cycle finish expected @ 2024-08-31 05:53:15.691644)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ Wakeup triggered from IRQ 9: ACPI SCI
○ Woke up from IRQ 9: ACPI SCI
○ gpe10 increased from 33 to 39
✅ Userspace suspended for 0:00:12.076968
❌ Did not reach hardware sleep state
🔋 Battery BAT0 lost 32000 µWh (0.04%) [Average rate 0.95W]

s2idle_report-2024-08-31.txt

One other thought, this machine has an Nvidia 4050 as well. I've disabled it from the Windows side using MyAsus. It doesn't show up in lspci for example, but thought I would mention it in case it could somehow be preventing reaching sleep.

I upgraded to 6.11-rc6 and it sleeps successfully now!

Do you have a 24gb or 32gb RAM model?

I tried to disable memory scatter-gather, and it didn't help.

Vivobook S 16 (M5606WA) with Ryzen AI 9 365 also experiences the same problem.

➜  Downloads sudo python amd_s2idle.py
Location of log file (default s2idle_report-2024-09-09.txt)? 
Debugging script for s2idle on AMD systems
💻 ASUSTeK COMPUTER INC. ASUS Vivobook S 16 M5606WA_M5606WA (ASUS Vivobook S 16) running BIOS 5.35 (M5606WA.303) released 07/23/2024 and EC 3.2
🐧 Arch Linux
🐧 Kernel 6.11.0-rc6-00011-g0984ead949bf
🔋 Battery BAT1 (ASUS  A32-K55) is operating at 101.60% of design
Checking prerequisites for s2idle
✅ Logs are provided via systemd
✅ AMD Ryzen AI 9 365 w/ Radeon 880M (family 1a model 24)
✅ SMT enabled
✅ LPS0 _DSM enabled
✅ ACPI FADT supports Low-power S0 idle
✅ HSMP driver `amd_hsmp` not detected (blocked: False)
✅ PMC driver `amd_pmc` loaded (Program 9 Firmware 93.7.0)
✅ USB4 driver `thunderbolt` bound to 0000:65:00.5
✅ System is configured for s2idle
✅ NVME Samsung Electronics Co Ltd NVMe SSD Controller PM9C1a (DRAM-less) is configured for s2idle in BIOS
✅ GPIO driver `pinctrl_amd` available
✅ IOMMU disabled
How long should suspend cycles last in seconds (default 10)? 
How long to wait in between suspend cycles in seconds (default 4)? 
How many suspend cycles to run (default 1)? 
Started at 2024-09-09 15:26:19.351045 (cycle finish expected @ 2024-09-09 15:26:33.351065)
Results from last s2idle cycle
○ Suspend count: 1
○ Hardware sleep cycle count: 1
○ Wakeup triggered from IRQ 9: Disabled interrupt (acpi)
○ Woke up from IRQ 9: Disabled interrupt (acpi)
○ gpe04 increased from 16 to 22
✅ Userspace suspended for 0:00:12.395813
❌ Did not reach hardware sleep state
🔋 Battery BAT1 (ASUS  A32-K55) is operating at 101.60% of design

s2idle_report-2024-09-09.txt

I'll comment on a few things I've noticed.

2024-09-09 15:26:31,728 DEBUG: ACPI: _SB_.PCI0.GPP0.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0

Do you normally have something connected to GPP0 that is disconnected? I noticed in the logs that GPP0 wasn't in the right state.

2024-09-09 15:26:15,983 DEBUG: | 9: Disabled interrupt (acpi)

This is really weird - did you do something to artificially disable the ACPI SCI? Unserviced interrupts will block hardware sleep.

2024-09-09 15:26:15,826 DEBUG: /proc/cmdline: amd_pstate=passive amd_iommu=off nowatchdog nmi_watchdog=0 sysrq_always_enabled=1

What happens with IOMMU enabled and AMD-Pstate in active mode?

Thanks for quick response.

2024-09-09 15:26:15,983 DEBUG: | 9: Disabled interrupt (acpi)

Turns out to be my disabled watchdog (by blacklist sp5100_tco)

I removed amd_pstate, amd_iommu and watchdog related cmdline arguments and settings, then Interrupt 9 came back, but the laptop was still unable to reach deepest hardware sleep state. no_opts.watchdog.txt

2024-09-09 15:26:31,728 DEBUG: ACPI: _SB_.PCI0.GPP0.SWUS: LPI: Constraint not met; min power state:D3hot current power state:D0

I don't know anything connected to GPP0 so far. To exclude the possibility of the NPU, I recompiled the kernel with the xdna driver (from patch set). But results remained the same. s2idle_report-2024-09-10.txt

Here are DSDT and several logs for more information if needed. dsdt.dsl lspci.txt

➜  acpi cat /proc/acpi/wakeup                                  
Device  S-state   Status   Sysfs node
GPP0      S4    *enabled   pci:0000:00:01.1
SWUS      S4    *disabled
GPP1      S4    *disabled
SWUS      S4    *disabled
GPP3      S4    *enabled   pci:0000:00:02.1
GPP4      S4    *disabled
GPP5      S4    *enabled   pci:0000:00:02.3
GPP6      S4    *disabled
GPP7      S4    *disabled
GPP9      S4    *disabled
XHC1      S3    *enabled   pci:0000:63:00.4
XHC0      S3    *enabled   pci:0000:65:00.0
XHC3      S3    *enabled   pci:0000:65:00.3
XHC4      S3    *enabled   pci:0000:65:00.4
NHI0      S4    *enabled   pci:0000:65:00.5
NHI1      S4    *disabled
LID0      S0    *enabled   platform:PNP0C0D:00

I removed amd_pstate, amd_iommu and watchdog related cmdline arguments and settings, then Interrupt 9 came back, but the laptop was still unable to reach deepest hardware sleep state. no_opts.watchdog.txt

Thanks. The interrupt looks right now at least. The idle mask looks the same too.

I don't know anything connected to GPP0 so far. To exclude the possibility of the NPU, I recompiled the kernel with the xdna driver (from patch set). But results remained the same. s2idle_report-2024-09-10.txt

Actually don't use the XDNA driver right now. The v2 series has a bug on Strix where NPU prevents going into the proper state for s2idle. It's going to be fixed after v3 is posted IIRC.

BTW - are you dual booting? If so:

1. Could you cold boot Linux instead and see if this changes?
2. Does Windows work properly?

Does this laptop have an NV dGPU that is currently disabled in BIOS? If so; can you please enable it and see if anything changes? I'm wondering if that helps this GPP0 issue or not.

Could you cold boot Linux instead and see if this changes?

No noticeable changes.

Does Windows work properly?

Windows seems to act the same as Linux does.

---

Update: Solution Found.

On my ASUS laptop, there is a firmware HibernateHelper at WMI dev_id 0x0012008E, as my DSDT shows

If ((IIA0 == 0x0012008E)) // Hibernate helper
{
    Name (LAOB, Zero)
    Name (PBAB, Zero)
    Name (DBAD, Zero)
    Local0 = IIA1 /* \_SB_.ATKD.WMNB.IIA1 */
    Local1 = IIA2 /* \_SB_.ATKD.WMNB.IIA2 */
    LAOB = (Local0 & 0xFF)
    PBAB = (Local0 & 0xFF00)
    PBAB >>= 0x08
    Local2 = (Local0 & 0xFF000000)
    Local2 >>= 0x18
    Local3 = (Local0 & 0x00FF0000)
    Local3 >>= 0x08
    DBAD = (Local2 | Local3)
    Local1 &= One
    ^^PCI0.SBRG.EC0.MALD = LAOB /* LID \_SB_.ATKD.WMNB.LAOB */
    ^^PCI0.SBRG.EC0.MAPB = PBAB /* POWER \_SB_.ATKD.WMNB.PBAB */
    ^^PCI0.SBRG.EC0.MAGT = DBAD /* IDLE \_SB_.ATKD.WMNB.DBAD */
    ^^PCI0.SBRG.EC0.MAAE = Local1 // ENABLE
    Return (One)
}

It takes two arguments, arg1 = lid | (idle << 16) | (power << 8), arg2=enable .

lid and power are corresponding to Windows power settings LIDACTION and PBUTTONACTION.

with values mapping below, the default values of lid and power are both 2 (Sleep).

lid/power	LIDACTION/PBUTTONACTION	Name
1	0	Do Nothing
2	1	Sleep
3	2	Hibernate
6	3	Shut Down

idle in minutes, seems to be the timeout of forcing sleep. default value of idle is max(sleep_timeout-monitor_timeout,0) + 10. (timeout from Windows power settings).

For my case, calling DEVS(0x0012008E, 0x00000202, 0x1) (i.e. setting idle timeout to 0) fixes my sleep issue.

s2idle.lid=2.power=2.idle=0.enabled.txt

---

Current asus-wmi debugfs does not support calling DEVS with more than one arguments. If anyone wants to try, use this kernel patch0001-added-call2.patch and try following script.

# run as root
cd /sys/kernel/debug/asus-nb-wmi
echo 0x53564544 > method_id
echo 0x12008e > dev_id
echo 0x0202 > ctrl_param
echo 0x1 > ctrl_param2
cat call2

---

• Sometimes I need to close my lid or push power button to make the changes effect.
• After resuming, my display flickers sometimes.

@PisonJay great investigative work. I'm guessing the right solution here will be to have asus-nb-wmi call this is as part of the suspend dev_pm_ops.

CC @fluke. Take a look at the above comments ^

Is this similar to what Armoury crate does on the Allys by chance?

The method 0x0012008E looks to be a new addition. I have no records of it, but I also don't have any Zen or Vivo DLL to dive in to.

@PisonJay for the sake of my curiosity and to try and maintain complete records would I be able to get you to string search the asus DLL's available in Windows for things that might match this?

You may be able to find some containing GetBIOSWhisperMode which is almost always available as a debug string in the dlls. In the file I linked above there are other strings matching similar pattern that might also be found. I'd love a copy of the dlls you find.

You can also open with cutter and enable all options, then search for those strings. You might even hit some function names matching:

Asus also typically logs things with debug strings. So a wide string search could find some logging files providing clues about the args in the disassembly.

---

As for the actual issue here: we can definitely have this called as part of the suspend. It's almost guaranteed that if it exists and get is a valid value then it's going to be required.

I think that the wmi-bmof data captured from Linux passed into bmofdec (see https://docs.kernel.org/next/wmi/driver-development-guide.html) should also get you some of the information Luke is looking for probably.

@fluke Actually it's in an ASUS service called ASUSOptimization shipped in new ASUS models.

Don't know whether it's appropriate so I won't upload binary here. But I can provide the screenshot of corresponding decompile results.

These days I've analyzed all WMI calls in ASUSOptimization available on my model. Maybe later I'll make a PR for https://gitlab.com/asus-linux/reverse-engineering/-/blob/master/WMI_SPEC.md

You can also ping me in asus-linux discord (I'm using the same username).

Following up on https://lists.freedesktop.org/archives/amd-gfx/2025-January/118759.html

Here is what guaranteedly fix the issue:

• pcie_aspm=off
• amdgpu.dcdebugmask=0x200
• amdgpu.dcdebugmask=0x10

I am wondering, what is causing setting the screen refresh rate other than 60 Hz to spike power consumption and fix the memory clock at 937 MHz (even if you chose a value below 60 Hz)

mentioned in issue #3785

At any refresh rate other than 60Hz. It will stay constant at 937MHz

At 60Hz. The memory clock will wiggle around 600MHz

mentioned in issue #3917