My question with this is… why is Framework giving up on their 16 customers and not trying to fix this issue themselves? It’s a pretty major performance issue on what is marketed as a performance/gaming laptop.
1 Like
Cause we’re all gonna buy the next big thing that rolls around anyway. No matter how pissed off everybody is now.
@Matt_Hartley - I saw in a FW13 forum post you provided some information about how to provide feedback for similar issues on the FW13
But outside of the community (namely, @James3 ) not much has been said about the FW16s EC issues.
The gitlab bug for this has not been updated in MONTHS by anyone from FW, and the general concensus by many is that their $2500+ laptops cannot be used for CPU+GPU intensive tasks (gaming) for more than a few minutes before the game becomes unplayable due to the stuttering issues.
I am more than willing to flash 3rd party EC firmware if FW isn’t planning to work on/fix this. But, ideally, James has done a lot of work, testing, and research to try and solve this issue.
Myself, and others, are well aware that this is not a formal means to get support. However, first-line email support is COMPLETELY lost when trying to share this issue with them, and does not appear to get to the right party.
All we would really like to know is:
Is FW aware of the issue, and trying to fix?
Is FW aware of the issue, and not going to fix?
Is FW unaware of the issue, and now will try and fix?
The answer seems common sense, as there is a github issue open for this, and this thread has over 300 comments - mostly after the issue with the stuttering was found - so we assume FW is aware.
It would just be nice to know if FW is working on checking out the changes James3 has made and finding a way to push this to customers.
Again, $2500 for a laptop that I can game on for about 20 minutes before it becomes a stutterning mess kinda sucks - as much as I love this laptop - I havent been able to actually enjoy a decent gaming session in months - which sucks.
7 Likes
I’d love to actually use the 240W charger I bought 6 months ago, but the dGPU goes stupid when plugged into it. So, where is the community fix? Can I use it on Windows? Can we get it stickied, both for ease of use and as a monument to Framework’s shame.
What do you mean buy “dGPU goes stupid” ?
We have already found ectool commands that help and ectool works on both windows and Linux.
2 Likes
The dGPU’s power draw oscillates between 27 and 50W when connected to my delta 240W charger. The 180W does not exhibit this issue, and the 240W charger is not cured by the following command:
ectool.exe --interface=winring0 chargecontrol idle
This command is also only about 75% effective on allowing good dGPU performance with the battery discharged below 95% in my experience. There’s obviously other issues that need to be addressed.
I’ve been poking at ectool.exe but have little spare time to devote to this. Then, in this thread, I found reference to a “community fix” but no reference or link other than it’s in this thread. After scrolling for a while, I’m just as in the dark as I was before and I asked for help.
How are you using it in Windows?
Last time I tried to figure it out it appeared that you could not do it without turning off driver signing or ignoring Microsoft’s banned driver list.
Here’s what I’m using. No need to disable driver signing, but you do need another program to create the interface.
There is one more command which prevents charging battery. It should help you. See James comment from 5th of May A call on 240w adapter - #258 by James3
I think that’s just another version of forcing charging to idle.
To refresh my memory, I dug out my Delta 240W charger and tried again. The dGPU clocks are all over the place. Is there a way to force a power state for the dGPU with the 240W charger?
Forcing the laptop to idle should fix the issue with the dGPU clocks, because the laptop shouldn’t be trying to charge the battery. I’m using the custom ec firmware from James3, and I have a script with the following that I run after swapping to RW:
sudo ectool chargecontrol3 1 30 80 255
sudo ectool chargecontrol idle
sudo ryzenadj --set-coall=-30
the COall works because I have the ryzen 9 configuration, not sure if it works on 7 (according to AMD it shouldn’t, last I checked)
If that doesn’t resolve it you could always see if LACT or adrenaline (depending on OS) can lock the power state.
That’s true with the Framework 180W power supply, but the Delta 240W causes the dGPU to behave erratically for me. There does not seem to be any way to force a power state for the dGPU through Windows or AMD’s Adrenaline software.
Since I’m also using a CalDigit TS4 dock, I’m using chargeoverride to make sure it only charges on port 2 instead of switching between ports 1 and 2. Even with normal charging, on the 240W power supply it’s not discharging the battery because the dGPU can’t draw enough power. On the 180W Framework power supply, the dGPU runs at 80-90W continuously, and I end up discharging the battery. With chargecontrol idle, it usually behaves and allows the battery to discharge below 95%.
I’m not sure if this is an EC problem, or a power supply problem, and the craptastic state of Framework’s EC code makes sure it’s near impossible to determine a root cause.
1 Like
I’m also using the 240W charger, and I’ve managed to get the laptop to pull a peak of 497W, with the dGPU spiking to around 170W using the above configuration. I’m not sure if the win ring0 configuration of ectool creates different behaviours as compared to the linux configuration.
If I don’t set these parameters when I boot the laptop, I also get erratic dGPU behaviour where it cycles between VRAM power states with the 240W delta charger.
The following command does not appear to work on windows:
ectool.exe --interface=winring0 chargecontrol 3 1 30 80 255
ERROR: Bad sub-command
Usage: chargecontrol
Get current settings.
Usage: chargecontrol normal|idle|discharge
Set charge mode (and disable battery sustainer).
Usage: chargecontrol normal <lower> <upper>
Enable battery sustainer. <lower> and <upper> are battery SoC
between which EC tries to keep the battery level.
On the chance that chargecontrol3 was what you were intending, that’s also not a valid command.
Chargecontrol3 is a part of James3’s fork of ectool, and alongside the custom firmware version it will charge the battery to 80% and set it to idle automatically after reaching that state.
I’m surprised that setting the charger mode to idle isn’t working for you, though. That’s all I have to do for my dGPU issues to go away. Are you using the battery saver bios setting or a battery limit in the bios?
The uGreen 500W charger with a 240W-capable port is now on Amazon and shipping within the USA.
2 Likes
But isn’t winring0 the old winring0 driver that creates a series of massive security holes?
yes, it is but it is better then disabling secure boot and driver signature. Framework is working on backporting new EC driver which is available for AMD AI version.
for me winring0 is viable option and I’m using it because I’m playing with undervolting
Even that is debatable.
Thanks for posting this. But $250 lol, thay are insane.