ValveSoftware / ValveSoftware/SteamOS

[ROG Ally] TDP lock / power limit regression on wake from sleep in SteamOS 3.8

Open
#2,790 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
No language data
Stars
2.6k
Forks
83
Avg merge
4m
Merged PRs (30d)
3

Description

Your system information
Steam client version: Latest Stable

SteamOS version: 3.8.x (currently 3.8.16)

Opted into Steam client beta?: No

Opted into SteamOS beta?: No

Have you checked for updates in Settings > System?: Yes

Hardware Specs: ASUS ROG Ally (RC71L - Z1 Extreme), BIOS 342, Upgraded 2TB SSD

Please describe your issue in as much detail as possible:
What I expected to happen:

When waking the ASUS ROG Ally (RC71L - Z1 Extreme, BIOS 342) from sleep/suspend, the APU should restore the active TDP power limit (e.g. 15W/25W) and resume gameplay or system navigation smoothly.

What actually happened:

There is a severe regression across the entire SteamOS 3.8 branch (including 3.8.16) compared to 3.7.x releases. Upon waking the device from sleep, the APU gets hard-locked at the lowest possible TDP/power limit (~4-7W).

The power limit is so severely restricted that even the main SteamOS UI / Gamescope interface lags and stutters heavily—a game doesn't even need to be running to experience severe lag. If a game is active, frame rates drop to unplayable levels (5-15 FPS).

Toggling TDP sliders or performance profiles in the Quick Access Menu (QAM) does not recover the TDP tables. The occurrence of this bug has increased significantly in 3.8.x (happening on almost every resume).

The only way to force the system to reset the power tables is to either restart the device or plug/unplug an AC power adapter to trigger a hardware power-state change.

Questions for Valve developers:

Is this TDP table/governor lock on resume for Z1 Extreme/ROG Ally a known regression currently being worked on for upcoming 3.8/3.9 patches?

Is this issue caused by third-party ACPI/firmware limitations on ASUS hardware (specifically on BIOS 342), or is it a Gamescope/Linux kernel power management regression that can be resolved on the SteamOS side?

Steps for reproducing this issue:
Turn on the ASUS ROG Ally running SteamOS 3.8.x (unplugged on battery, BIOS 342).

Press the power button to suspend/sleep the device (either in the system UI or inside a game).

Wait a few moments and press the power button to wake the device up.

Observe that the entire system interface (Gamescope / QAM menu) stutters and lags heavily due to the APU being locked at minimum TDP (if in-game, FPS drops to 5-15 FPS).

Plug in an AC charger or restart the device to observe the TDP immediately returning to normal.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the suspend/resume sequence on the ASUS ROG Ally RC71L with BIOS 342 and SteamOS 3.8.16, then compare it with a 3.7.x release. Investigate the SteamOS power-management, Gamescope, and Linux kernel areas implicated by the regression. Done means the active TDP is restored after wake without restarting or reconnecting AC power, and the UI or game no longer stutters.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
operating-systems, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.