Laptop was in sleep connected to a charger all day. Just woke it up (so it’s cold), and it’s stuck in throttle status. EDC_CPU status shows while steam is compiling some shaders and the laptop is pretty sluggish. Pleading again for Framework to finally fix these issues.
1 Like
I was able to identify that most issues related to throttling are in fac in partt related to the AMD SMU firmware behaving rather oddly, and i was able to solve some by changing entries in the BIOS AMD CBS setup config (thanks to Smokeless UMAF, that allows access to hidden PBS & CBS config).
First, the PROCHOT_CPU & PROCHOT_GPU. These flags are not directly tied to the status of the physical prochot pin, but are internally set by the SMU firmware when the prochot pin is asserted during a possible overheating event. During normal use, it happens mostly when the EC transiently (< 1 second) activates the pin when an external power source is connected or disconnected, for a reason. Then, after the prochot pin is released, the SMU is supposed to clear those flags after a predefined duration, to resume normal operation. Unfortunately, the default delay seems to be set to infinite with the default SMU configuration. This issue is solved by manually setting a delay:
Set [AMD CBS] / [SMU Common Options] / [PROCHOT Control] to <Manual> (<Auto> by default)
Then set [PROCHOT Deassertion Ramp Time] that just appeared below to <1000> (<0> by default).
This will set the timeout to 1 seconds (1000 ms), which may be enough.
You might find this interesting @jared_kidd
4 Likes
I’m syncing the post with the github issue: FW16 7040 BIOS 4.03 - CPU power locked at 35W (45W with 240w PSU) max when dGPU is asleep · Issue #146 · FrameworkComputer/SoftwareFirmwareIssueTracker · GitHub
I discovered that the AMD SMU completely ignores the EC-adjusted SPL cap by default. It just applies its own caps, that are a lot more conservative.
To force the SMU to take into account the EC-driven settings:
Set [AMD CBS] / [SMU Common Options] / [STAPM Control] to ( by default)
Then set below:
[System Temperature Tracking] to <0> (the default). This is mandatory to prevent the SMU from overriding custom SPL values (EC or manual).
[STAPM Boost Override] to <1> so that changes to [STAPM Boost] will have an effect.
[STAPM Boost] to <0> (the default). IIRC setting it to <1> will allow the CPU to run at 45W anytime (with annoying spurious throttle during power transitions), which is probably not what you want…
[Tskin Time Constant (STAPM)] to <0> (I don’t remember if changing it makes a difference tho).
EDIT:
I identified the root cause of this issue.
When System Temperature Tracking is enabled, the AMD SMU uses the temperature sensors to dynamically adjust the STAPM LIMIT to control power consumption. By default, the sensors count STT_PCB_SENSOR_COUNT is set to 3, with the 3rd one attached to the dGPU (if you set STT_PCB_SENSOR_COUNT to 2, then the dGPU temp is ignored and the issue disappears).
However, when the dGPU is off, the temperature limit for the dGPU skin temperature sensor STT LIMIT dGPU is set to 0°C, while the measured value STT VALUE dGPU continues to stay at ambient 30-35°C. So the AMD SMU believes that the dGPU is overheating, and reduces the STAPM LIMIT accordingly, thus limiting the APU to 35W.
When the dGPU turns on, STT LIMIT dGPU is set to 51°C, which clears the overheating signal as STT VALUE dGPU becomes lower than STT LIMIT dGPU, so the AMD SMU is able to rise the STAPM LIMIT to reach the rated 54W for the APU.
To test if i could replicate it even when the dGPU is off, I first reverted back to default bios settings (to be sure that there were no interference from my specific settings), then i launched a CPU+iGPU stress test and compared the APU power limit/consumption while STT LIMIT dGPU is set to the default 0°C VS 51°C via ryzen_adj, and the results are pretty clear: STT LIMIT dGPU == 0°C => 35W /VS/ STT LIMIT dGPU == 51°C => 54W.
Then i wanted to identify which part of the firmware is responsible for controlling the STT LIMIT dGPU parameter of the AMD SMU PM table.
So i tried to see if the EC was able to alter STT LIMIT dGPU, however no AMD PMF command with the current AMD SMU firmware allows the EC to perform this specific operation (and i tested all the possible commands).
The next target is the ACPI firmware. Using acpi_call to call the method \_SB.PCI0.GP17.VGA.PX02 with a parameter 0/1 to turn the dGPU off/on, results in the STT LIMIT dGPU value changing accordingly (e.g. # echo '\_SB.PCI0.GP17.VGA.PX02 0' >/proc/acpi/call; cat /proc/acpi/call).
So far I’ve been able to track it down to a single method call, nicknamed KER-ASL-CpmWriteGpio, which presumably changes a Gpio pin:
# echo '\M010 9 1' >/proc/acpi/call => STT LIMIT dGPU = 51°C
# echo '\M010 9 0' >/proc/acpi/call => STT LIMIT dGPU = 0°C
This write seems to trigger logs in the EC, so maybe there is something else to look for in there…
5 Likes