What PSU are you using?
Frameworks 180W
I’m only getting 3756pts on bios 4.01, with 180w psu connected, and everything that uses cpu closed.
EDC_CPU throttle status flags when I start the cinebench run, which seems to limit my cpu speeds to 1400MHz.
Framework…..WHY WONT YOU FIX THESE ISSUES??!?!?
s-tui screenshot while in stress mode:
Looks like it is limiting it to 10 watts when all cores are stressed. Which is insane. This is at a 5 day uptime. I think a reboot will mitigate the issue, but that should not be needed. Why are they not fixing it?
The messages “set AP throttling type 1 to on (0x00000008)]” are the EC setting a gpio that forces the cpu to its lowest 550 frequency. When this happens, no prochot message appears in amdgpu_top.
I tried to get amd to add it to amdgpu_top, but FW support refused to help with words like “it is connected to a special pin on the CPU”, when all we needed was an exact pin number.
So, all this means is amdgpu_top does not show all throttle flags.
My FW16 is a 7940HS with 7700S dGPU, 64GB ram, both ssd slots populated. Wifi card is a Qualcomm WCN785x. 2xRGB LED matrix and RGB keyboard installed in input deck. Nothing really custom unless the RGB matrix or wifi card are considered custom. I will gladly provide further info if it would help.
I had the official Framework 180w connected when taking those s-tui screenshots.
EDIT: looks like your post was deleted while I was responding. To further explain, I think it gets into this state when I connect a generic 60-100w adapter I use in the bedroom. Problem is, it stays in this weird state until I power off the machine for a while (sleeping does not even work). This should not happen. If for some reason a charger ever puts it into a weird state, it needs to go back to normal once that charger is disconnected. Because it doesn’t do this, the laptop has to be powered off all the time to “reset” something. Anyway, that’s just my suspicions.
I will gladly test anything asked in order to help narrow down and resolve these issues.
Sorry about that, I deleted it because I realized I was missing some information from your original post. I am checking the system again now.
i think it might have something to do with it changing the state on/off every few milliseconds. When this flickering occurs, a lot of low level programs will start exhibiting erratic behavior because of the erratic cpu clocks.
Do you have a simmilar issue as well?
After the 4.01 upgrade, my machine will perform well while gaming (HellDivers 2) for about 5m, and then the GPU power will throttle from a steady 85-100w abruptly down to 10-30w.
7840hs | 7700s | 96gb RAM | 180w FW adapter | CalDigit TB4 dock | External 4k monitor via 7700s port | Windows 11 (Best Performance Mode)
You’re likely discharging the battery, and when it hits 95%, the laptop goes into recharge mode killing performance. Switch to Balanced mode and try again.
are you comfortable with reading the ec? Want to confirm, because sounds simmilar to mine
One of the programs I’ve been using to test the functionality of the BIOS versions is Battlefield 6, given how resource demanding it is on the FW 16. It would appear that the game has a bug where performance will drop if you’re not in Fullscreen mode, kind of like games limited fps when you’re tabbed out, but working in reverse. This doesn’t explain all the issues I’ve had (especially in apps like cinebench), but switching to fullscreen has alleviated some of them.
I have identified a problem specifically with the beta bios!
Sadly i wasent able to get a log yet, and narrow down trigger conditions. But there is a communication issue where the log says something like (from memory, wasent fast enough yet to take picture)
Mailbox error 4
PD does not respond even tho its powered on
system gets near unresponsive and then shortly after a memory management bsod.
After restart its ok again.
Happened 3 times alredy and only with beta bios. Will i update once i am fast enough with getting picture/happens again. sorry for not being able to give more info.
Can confirm this behavior isn’t present on Balanced mode. GPU maintains a steady 60ish watts.
Been running this for a few days. Just upgraded to Fedora 43 running kernel 6.17.6. GPU throttling is completely gone, but sleep-wake will almost always lock the CPU at 988Mhz regardless of power profile or charging/not charging. Reboot is required to fix it.
Putting the laptop to sleep while plugged in, unplugging it, and then waking it up will lock the CPU to 544Mhz.
i’m not seeing locks to 544MHz on this version like you are (that was happening on beta 3.06 for me), but mine DOES limit the cpu power permanently after a power change (connect/disconnect power or dGPU activate/deactivate), which destroys my cpu performance and it never gets above about 75 degrees with all cores being stressed to the max, capped between 10w and 35w depending on how it feels (ie. it should not be throttling yet). Power off and restart fixes it.
I thought at first it was a specific power supply causing it, but upon further testing I see it just happens irrespective of the power supply, even if I am only using the official 180w.
I want Framework to realize I paid a lot extra for the Ryzen 9 7940HS. Big mistake as it’s being crippled by their own firmware. And now they are releasing an updated processor.
I can’t express how frustrated I am with their lack of fixes for this….almost 2 years now?
EDIT: Here is something repeatable (FW 180w connected, battery at 100% if that matters):
- run “stress-ng -c16” to start a stress, and launch “s-tui” to monitor cpu.
- Sleep and then wake laptop.
Note the wattage used in s-tui (very bottom left). Should be above 60w and then settle down into the 50s as cpu temp maxes out. The dGPU will also be awake after the sleep/wake cycle while s-tui is running. Your fans should be taking off. - Now close s-tui, but leave stress going. Wait at least 3 seconds for the dGPU to go back to sleep.
- Bam! cpu now capped down to 35w! Launch s-tui again to see it capped at 35w.
- You can sleep the laptop, leaving the stress and s-tui active and upon waking up, it should be uncapped again with the dGPU held awake. If you slept it with s-tui NOT running, when waking the cpu will be uncapped for a couple seconds until the dGPU “sleeps” again and then immediately caps it at 35w again.
So, in summary. When the dGPU goes to sleep, the cpu gets capped to 35w and will stay that way until a sleep or reboot is performed.
If you do not have something holding the dGPU awake while waking the laptop, then the 35w cap is applied when the dGPU sleeps again a couple seconds after wake.
I’ve seen the same or similar 35W capping behavior with my R7 7840HS, I’ll see if I can reproduce this issue on BIOS 3.05. Thanks for the detailed steps! If it’s reproducible on other builds, that might be the key to effectively communicating the problem to Framework.
This is a bugger of a problem to reproduce consistently. I’ll be a little more detailed in the spirit of helping the framework team figure this out.
@jared_kidd I tried following your steps to reproduce and couldn’t replicate it, but it sounds like the right approach. What’s your OS/Kernel/specs?
I think I see the CPU throttling happen most often when the battery drains in sleep. So sleep, unplug, carry to work, maybe wait a few hours, wake, CPU throttling, plug in power, still throttling.
Today I tried a few different scenarios that I suspected would trigger the issue but none of them did:
Steps tried in vain to reproduce
Balanced:
- Drain battery to below 90%
- Unplug power
- Sleep
- Plug in power
- Wake
Performance:
- Unplug power
- Set performance profile to “Performance”
- Sleep by closing the lid
- Plug in power
- Wake
Performance + VM
- Set performance profile to “Performance”
- Launch a windows 11 VM
- Unplug power
- Sleep by closing the lid
- Open the lid
- Plug in power
Performance + VM 2
- Set performance profile to “Balanced”
- Unplug
- Set performance profile to “Performance”
stress-ng -c 16until CPU throttles to ~3.8GHz- Sleep by closing the lid
- Open the lid and plug in power at the same time
Performance again:
- Unplug
- Set power profile to balanced
- Set power profile to performance
- Launch a game
- Sleep
- Wake
Power profile boogie
- Unplug power
- Set PP to balanced
- Sleep by closing lid
- Wait a minute
- Set PP to performance
- Sleep by closing lid
- Wait a minute
- Plug in laptop
- Wake
Apps
- Load the GPU with ollama:
ollama run gemma3n:e4b - Unplug the power
- Sleep by closing the lid
- Wake
- Sleep by closing the lid
- Plug in power
- Wake
- Set PP to Power Save
- Set PP to Performance
- Sleep
- Plug in power
- Open the lid
- Wake the laptop
More Apps
- Start Pika backup
- Unplug
- Sleep
- Wake
My specs are:
Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.1
KDE Frameworks Version: 6.19.0
Qt Version: 6.10.0
Kernel Version: 6.17.6-300.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 9 7940HS w/ Radeon 780M Graphics
Memory: 103 GB of RAM (92.6 GB usable)
Graphics Processor 1: AMD Radeon 780M Graphics
Graphics Processor 2: AMD Radeon RX 7700S
Manufacturer: Framework
Product Name: Laptop 16 (AMD Ryzen 7040 Series)
System Version: AJ
I never use sleep functionality on windows or linux and have seen the 35W cap on a fresh boot, so I’m not convinced that’ a necessary component to replicate. I was able to witness 35W cap on BIOS 4.01 on windows with a fresh boot just running cinebench after waiting for the OS to finish starting. I never tested how reproducible that is though, and have since gone back to 3.05.
I’ve gotten my FW16 (7940 CPU, Windows 11, dGPU) stuck in a low wattage/low CPU clock state twice but both times plugging/unplugging the charger seems to have fixed the issue. I’ve been apprehensive of installing this BIOS update since so many folks are reporting flaky performance, I can’t really afford to lose work hours to laptop troubleshooting. Maybe I’ll try it out during winter vacation. I hope a new candidate that is more stable is available by then.
This issue did not occur on 3.05 and can not be reproduced on it. It does, however, appear it may have started on 3.07 and was carried over into 4.01 without being fixed.
Kernel: 6.17.7-arch1-1 on an updated Arch Linux, and I mentioned my specs up above in another post but the FW16 only has one mainboard so far which is what matters.
Do you have the dGPU installed? My reproducible steps seem to rely on the dGPU changing power states.
I’ll be honest, it has been VERY hard to narrow down the cause. These problematic throttling have been happening for the life of the product. It has just gotten worse on every bios update. Where it used to happen after about 5 days of uptime for me on past bios requiring a reboot to resolve, it now happens constantly on 4.01.
I honestly think they have several bugs in their power management and every time they make a change it just compounds the issues.
Here is a short video to show the process.
-Top konsole shows dGPU power state (D3Cold is off).
- start stress and s-tui (package power is already limited in this case to 35w).
- sleep, then wake (package power now good, between 50w-65w).
- close s-tui, wait for dGPU to enter sleep (D3cold), then re-launch s-tui.
- See the package power is limited back down to 35w.
- Repeat 2-4 as many times as you want to repeat it.
https://www.youtube.com/shorts/rKd8w53GIxc
