Same here. I tested under windows with charge limit and battery extender activated. After about 20mins Satisfactory i was down to 73% in high performance, but the gpu stood solid at 100w. I am currently using the ugreen 500w
1 Like
This from another thread.. anyone willing to check into this as well since FW is monitoring issues?
This was an issue before the 3.06 bios. I cant forget where, but this was reported earlier (like, weeks ago).
After my poweroff (with it unplugged to fix the “known issue” of usb3 issues), I had this.
However, I unplugged/plugged in my power cable and it was fine.
Pulling 105w on GPU, 60+ on the CPU playing Deadzone Rogue on high, with loseless scaling (linux version) and held a solid 165 fps for about 40 minutes. Battery level never dropped.
2 Likes
well… i got the new BIOS 3.06 and the new Driver Pack installed but….. the stuttering is still there, dose somebody else have an Framework 16 (AMD R9 7940HS / AMD Radeon RX 7700S) with the new BIOS and Drivers installed and an UGREEN Nexode 500W charger ? if there is somebody here how is your ingame performance in Sons of the Forest ? or other games
1 Like
I have go the 7840hs and 7700s with the ugreen but after installing the framework driver pack i upgraded to the newest genuine gpu and chipset driver and tested with satisfactory. Stuttering is gone. Stable 100w from the gpu.
1 Like
I have the R9 with 7700S,new bios, nexode 500w. But on Linux. I do get stutter, but it may be due to other things (steam overlay? Mouse polling rates?) I just couldn’t play BG3, it made me angry. Actually, I might just try switching back to 180w charger to try… the stutter for me happens only while the mouse is moving, and especially when it’s a menu and the cursor goes over the options.
Don’t have Sons of the Forest, so can’t try.
Did you use LACT and set the power limit to 120W? I had to reduce it back to the stock 100W or else I get stuttering issues on the new bios version.
I think is better for the developers to block the CPU/GPU from peaking 450W i.e reduce max peak power.
At higher power the efficiency gets lower, double the power only gets 20% if from above the max power according to the V/F curve regardless of using “curve optimizer” or not. Therefore it’s meaningless to draw 450W even for short peaks as it won’t get you more practical performance. If battery drain is allowed, the peak power should still be lowered to a reasonable wattage like 300W.
2 Likes
Thanks for pointing out the BIOS 3.06 beta note on fixing the battery drain in balanced mode. That’s definitely promising news, but since it’s still beta, some users may not want to rely on it yet for daily stability. A dedicated 240W PD adapter could still be valuable for consistent performance, especially under heavy workloads or gaming. Even if the BIOS fix becomes stable, extra power headroom would be a big plus. If enough people are on board, we could make the R&D cost more manageable.
The 3.05 was moved from Beta to Full Release despite their known bugs AND it was not able to be rolled back and it was by far the worst bios to date
Also to add in to what PSierra was saying, 3.05 also made performance under loads with a 240W charger less than ideal, with major stutter and frame pacing issues. 3.06 as a beta so far is significantly more stable than 3.05 as a “full release”
2 Likes
And they left it like that for 8 months. This 3.06 is even worse so far. It locks to 500MHz after waking from sleep. I just hope they don’t decide to “mark is stable” and put it on the back-burner for another 8 months.
1 Like
Well for me its not that bad. I don’t use sleep. 
4 Likes
I had more lock to 544 mhz with 3.05… I don’t think he had it even once since updating. I flashed the bios using the bootable usb method
I know the EC code quite well.
To exit 500Mhz mode:
-
Power off laptop.
-
remove PSU.
-
Wait 2 minutes (it needs this delay before it resets the EC)
-
Insert PSU
-
Power on laptop. (It should now go above 500Mhz)
The 500Mhz is maybe caused by the USB-C PD negotiation.
So, my questions will be around whether it is doing USB-C PD negotiation or not.
-
If you suspend then resume with the PSU unplugged. I.e. On battery only, does it go to 500Mhz? Without the PSU plugged in, is cannot have gone through an USB-C PD negotiation.
-
If you suspend then resume with the PSU plugged in but with very little delay between suspend and resume? This might not result in a USB-C PD negotiation as the cycle was too quick.
-
If you suspend, wait 10 minutes, then resume with the PSU plugged in? This will result in a USB-C PD negotiation.
Please let me know which of 1-3 causes the 500Mhz.
2 Likes
Yes, it seems to do this about 90% of times while testing. Also, when I sleep it on battery, it sits in sleep while I also sleep 8 hours, then wake it up the next morning on battery, it has done the 500MHz thing every single time since the bios update.
Yes, this causes it to go into 500MHz mode.
I can undo the 500MHz issue pretty reliably by disconnecting PSU, sleeping the laptop, reconnecting PSU, then waking it back up. Also, a simple reboot resets it back to normal as well. No need to power off and let sit for 2 minutes.
Note, all my testing here was with the Framework 180W PSU.
There a 3 ways for the CPU to get force to go slow. I.e. 500Mhz.
-
EC setting GPIO prochot
-
EC sending low performance limits via SMBUS.
-
EC restricting the PSU momentarily to 0.5 Amps / 2.5W.
All three are set momentarily when you plug the PSU in, or when exiting sleep.
So, I was trying to see from your answers if there was any pattern based on the different scenarios.
But, you mentioned that you were seeing the problem occur, even with the PSU unplugged. So that points to something else entirely being the cause. That something else is unknown at the moment.
I was hoping that the problem was not presenting itself if the PSU was not present, and only occurred when the PSU was plugged in.
I’m having a hard time narrowing down the cause myself. It just seems like multiple things can cause it or the EC/bios is extremely buggy. Did they use AI to write it? 
Another note, right now I have my 180w connected in addition to my dock which provides 100w when used alone. This seems like the only way I can get it to act properly and not lock down to 500MHz when using the dock. Throttle status in amdgpu_top has nothing set which i would expect for normal opperation.
As soon as I disconnect the 180w PSU, the dock disconnects and reconnects (should not do this as it is disruptive), and I see Throttle status show “PROCHOT_CPU, PROCHOT_GPU” but it is NOT stuck to 500MHz. It does seem to be partially throttled though. It is nowhere near overheating so these throttles do not make sense to me.
If I then reconnect the 180w PSU, nothing changes, it remains with those throttles in place.
EDIT: Come to think of it, I’m pretty sure amdgpu_top has ALWAYS had something there in the throttling section on the previous bios version 3.05. I have never seen Throttle status showing blank like I do now (power off, reconnect 180w psu, power on will clear it on this 3.06 version). There has always been a Throttle setting set as far as I can remember. I thought it was just normal for this laptop to always be in some throttle status.
Just to clarify.
During the 3 tests, did you have nothing plugged in except the FW180W PSU. or was the dock plugged in at the same time?
The 3 tests needed to be done with nothing plugged in except the FW180W PSU. The reason is that the dock looks to the laptop as a PSU, so with the FW 180W PSU, it looks like it has 2 PSUs plugged in at the same time, and the laptop can only use one of them.
Also, amdgpu_top is not very useful here. It cannot detect the “EC setting GPIO prochot”. When set, nothing appears in amdgpu_top.
All the tests I did last night were with only the 180w PSU, no dock.