When Gaming or doing something intensive (like a stress test) the system sets the PROCHOT flag to 1 despite the CPU temperature being 85 degrees celsius or less.
I tried to set a TDP limit for the CPU to around 30W but the flag is set also at 60 degrees celsius.
I use a 180W charger and the PROCHOT flag is set after 5-10 minutes.
How can i solve this issue? I already created an issue on the Framework Git for maybe bios related issue.
When the PROCHOT flag is raised the system goes around 25W consumption at 2500 MHz frequency.
To reproduce i can start OCCT and perform a FULL Load test with the discrete GPU and after 5-10 minutes the issue persists.
The system is brand new and uses PTM. I donât know if i have a defective unit or something else
Hi @Simone_Zurlo welcome to the community. Open a support ticket and keep in contact with Framework support.
This is probably a BIOS issue however it might be a physical issue with the thermal interface material too. These devices always run hot under load so it is harder to tell unless it shoots up and thermal throttles in a very short period of time. Support will be the best avenue for guidance on this though.
If it is a BIOS issue then it is going to take their team time to test a fix and come up with a fix for this and several other issues that are a priority for them right now. Their team is very talented however they are quite small and have lots on their plate.
Great that you started an issue on the GitHub, that will give the team some more specific data to work with. We are all just end users here on the forums. Hopefully they can come up with a solution soon for you. Let us know how it goes. Others might be in the same boat as you.
That is great to know that PROCHOT_EXT is triggered by RAM temps at 80+ degrees C. I would still contact support and get a ticket started with them. I do not blame you for wanting to return the device if it fails to meet your expectations.
Surely Framework tested the Framework 16 under full load for extended periods of time with a similar setup as yours. Others on the forum have Framework 16 laptops running full tilt with games and other applications for extended periods of time. There is the possibility that this specific laptop is not cooling itself as designed. Sorry to hear about these issues.
For full transparency: Yesterday, after cleaning up everything, I requested a return, and the support team has since escalated to RMA. I will continue to update this thread for the sake of completeness.
Itâs unfortunate you have to return it, but I totally understand. For the price these cost, they should prioritize making them function properly. We have all been suffering with these same firmware/bios bugs since it was released and I hope Framework realizes they are losing sales because of their lack of urgency.
Truly unfortunate, yet there is a silver lining: the support team already provided RMA labels (1 working day as expected) despite initially warning of potential delays in the process. Thatâs a good news.
I hope that in a few years, when Framework Laptops have matured sufficiently, I may purchase another one from them.
Came home and got on my FW16 tonight only to find itâs stuck in the 544MHz bug. Itâs been connected to my dock all day and was never put to sleep. Disapointing that itâs still an issue on 4.03:
âamdgpu_topâ display a lot of different types of PROCHOT, but it never displays the PROCHOT from the EC GPIO.
sudo ectool gpioget | grep h_prochot
Out put is:
1 h_prochot_l 0xA0006 â No PROCHOT from the EC GPIO.
0 h_prochot_l 0xA0006 <-PROCHOT from the EC GPIO.
For example, on a FW16 AMD 7840HS, setting the EC PROCHOT causes 544Mhz clocks across all CPU cores and the laptop is noticeably slower. I tested this manually by modifying the EC firmware with a test command that can set/reset the PROCHOT.
So, I would be interested for people to also report the output from the above command when the system is throttling itself.
We can then determine whether the source of the PROCHOT is the APU/CPU or the EC.
Other than that, the laptop appears to be functioning âproperlyâ in that it is limited to only 35W while my dgpu is not being used (which frustrates me Framework dismisses it and doesnât seem to care to fix).
I donât know what impact the PROCHOT_CPU and PROCHOT_GPU.
After a new boot, they are off. As the first prochot event happens, they come on and just seem to stay on, event when the prochot event finishes.
I have not seen them cause any performance impact, so I donât really know what they are for.
The âSPLâ one appears when the system has reached it âsustained power limitâ. It depends on what SPL the EC has set, and that also depends on which model you have selected âPower Save, Balanced, Performanceâ.
For example, I think the âh_prochot_lâ from the EC is asserted for a very short time when you insert a PSU. It is supposed to de-assert it less than 1 second later, but if you do this close to a suspend, it can cause the EC to forget to de-assert it. I donât know if recent BIOS updates have fixed this. It is because of that that I suggest keeping suspend events and remove/insert psu events some time apart. e.g. 20 seconds between the two.
I.e. close the lid, quickly followed by removal of the PSU, could be avoided.
So it has a race condition, probably multiple. They NEED to fix these. Itâs ridiculous for a bios to be this buggy. Specially years after release.
I took a look through the power selections the ec makes in the code once to see what it was doing. And all I can say is it is a complete mess. Instead of smartly or dynamically setting the limits based on the amount of power available, it has every rate HARD CODED, and separate paths for AC/BATT/AC+BATTâŚ..so if you connect the 180w psu, it takes a very specific path, basically âif 180w connected, do this stuffâ. Terrible design. It didnât even have anything for above 180w prior to FW releasing one so anyone who connected a 240w psu got the settings for a 100w or something. Someone smart would have programmed it to calculate power distribution based on a set formula taking into account the available power at the time, avoiding the need to hard code 60w, 100w, 140w, 180w, etc.
I can probably agree with you about the EC code not being the best.
But, to be fair, FW inherited it from Chromebook Google EC, and so they did not exactly have a good place to start from, but it was better than them writing a complete EC code base themselves. That would have taken forever.
I think this thread is pretty ambiguous though. The âoverheatsâ in the title. I am assuming that is not really getting too hot, but rather just the various PROCHOTs messages when one is not expecting them.
For my part, I donât wait for FW to fix EC stuff. The bugs that are important to me, I fix myself in the EC code. So far, I have fixed the battery cycling and games stutter. Some others I will fix when I get a moment.
Just to provide an update, the package arrived at the facility in Germany (Iâm from Italy) on January 22nd, and today I received a full refund without any restocking fees or additional charges (the refund was issued on the 24 January). Everything went smooth.
I am delighted that the customer support was exceptional and hope to become a customer of theirs once again in the future.
