It’s been about 3 months since this issue has been reported and many Framework AMD users seem to be affected by it.
Is there any update on resolving the bug? I’d highly appreciate it!
It’s been about 3 months since this issue has been reported and many Framework AMD users seem to be affected by it.
Is there any update on resolving the bug? I’d highly appreciate it!
This is something the engineering team is working on. Firmware specifically.
Will this benefit windows users too? Also having the same issue but on windows 11 OS.
It is firmware, so it will have an impact on the hardware regardless of the OS.
I have the same problem and it is really annoying for me and for my colleagues in the office.
How confident are you that this issue will be resolved?
I’m still within the return period on my device and as much as I like the Framework for all its other features and qualities, this is a bit of a deal breaker for me.
Hi, I have a new Framework 13 AMD and noticed this issue too on Windows 11. I updated to BIOS 3.05 just now, and the issue remains. I am doing nothing demanding, I have HWiNFO64 open to monitor the CPU temperatures, there are no spikes visible, and suddenly Framework turns on the fan to high speed for about 1 second, and then they turn off completely again.
What can we do to help you debug and fix this issue?
It is clearly a bug, because when I run benchmarks that make the CPU go to 95°C, the fans take about 30 seconds to turn on and stay on for quite a while. So where are these sudden fan spikes coming from when the system is in idle?
I updated to the 3.05 bios and I’m still experiencing this.
@Matt_Hartley Is it safe to assume that this is still in-progress for the firmware eng team?
Also, given the latest Framework email announcing more dedicated engineering teams, I assume there’ll be more frequent firmware fixes coming?
I’m seeing the same with my Framework 13 AMD on Ubuntu. At random points the fan will kick into high for maybe a second and then reduce fan speed again immediately. I’m on the latest bios version as well.
This is not a bug, but whether it’s desired is up to interpretation.
I found a way to replicate this. The “turn off completely again” is actually turned to 3% (the lowest PWM) then 0%.
If you are in a cold environment and just benchmark the CPU i.e sensor temperature passes the fan_off temp quickly, the fan will speed up gradually and if you then stop the benchmarking the CPU will slow down smoothly untli a complete stop.
However, if you are in a warm environment doing nothing demanding, the sensor’s temperature might stay at exactly at the fan_off i.e 313K for local_f75303@4d
and/or 319K for cpu_f75303@4d
and if the temperature changes very very slowly i.e. changing from 312K to 313K or from 313K to 314K in several minutes, the fan controller might freak out, sending 100% PWM in a fracton of second.
I am observing the same thing. It is happening when the local sensor temperature is around 40°C, which is the threshold for fan activation. However, sometimes it turns the fan on silently, keeping it around 2500 rpm, and sometimes it seems to spin up a lot only to reach the fan off threshold immediately and turn them off again. This then results in the weird on/off pulsating behavior.
There might be 2 problems at play at the same time:
I think @Kieran_Levin is the person who could shed some light into this issue. He’s signed off on this EC commit that touches fan behavior, including the hysteresis, timeout, and RPM / fan duty adjustments. I believe we could 1) increase the hysteresis, and 2) make sure that the fan does not spin up too fast if it was previously off.
If you’re still seeing this and can provide steps to achieve this, please open a ticket and ask it to be sent to me to vet it and then I can escalate to engineering once we have the steps to repro and have it in the ticketing system.
It is actually very easy to reproduce for me, it happens whenever the temperature sensor is around 40°C, which is the fan activation threshold.
I got in touch with support and they asked me to kindly provide a video of the issue with a removed input cover, zoomed in on the fan. They would like to see the fan turning on at high RPM and immediately down again on the video.
I do not have time to do these experiments right now, but if anyone here has the time, please upload the video to YouTube and send a link here, and either send it to support or I would forward it to support myself!
I think I found where the bug is
$ sudo ectool temps all
--sensor name -------- temperature -------- ratio (fan_off and fan_max) --
local_f75303@4d 314 K (= 41 C) 3% (313 K and 343 K)
cpu_f75303@4d 318 K (= 45 C) 0% (319 K and 327 K)
ddr_f75303@4d 313 K (= 40 C) N/A (fan_off=401 K, fan_max=401 K)
cpu@4c 329 K (= 56 C) 0% (376 K and 378 K)
$ sudo ectool pwmgetfanrpm
Fan 0 RPM: 2229
$ sudo ectool fanduty 3
Fan duty cycle set for all fans.
$ sudo ectool pwmgetfanrpm
Fan 0 RPM: 0
$ sudo ectool fanduty 10
Fan duty cycle set for all fans.
$ sudo ectool pwmgetfanrpm
Fan 0 RPM: 980
As shown, there are two sensors responsible of the fan speed, the local_f75303@4d
and thecpu_f75303@4d
. The temperature sensor can only output intergers. Thus the first sensors output 3% per C, the second ones output 12.5% per C. However if you $ sudo ectool fanduty 10
then $ sudo ectool pwmgetfanrpm
and change the 10 to other value, you discover that the fan RPM is 0 if the duty cycle is at or below 10%. Thus for the fan controller to work as these temperatures, the first sensor might output an arbitary value when the temperature is below 316K, since in 314K the fanduty us 3% but there’s no way that the fan is spinning at 3% duty, and the fan is more like 20% duty actually
--sensor name -------- temperature -------- ratio (fan_off and fan_max) --
local_f75303@4d 319 K (= 46 C) 20% (313 K and 343 K)
cpu_f75303@4d 323 K (= 50 C) 50% (319 K and 327 K)
ddr_f75303@4d 310 K (= 37 C) N/A (fan_off=401 K, fan_max=401 K)
cpu@4c 369 K (= 96 C) 0% (376 K and 378 K)
$ sudo ectool temps all
--sensor name -------- temperature -------- ratio (fan_off and fan_max) --
local_f75303@4d 320 K (= 47 C) 23% (313 K and 343 K)
cpu_f75303@4d 324 K (= 51 C) 62% (319 K and 327 K)
ddr_f75303@4d 310 K (= 37 C) N/A (fan_off=401 K, fan_max=401 K)
cpu@4c 367 K (= 94 C) 0% (376 K and 378 K)
This also explains that why the fan appears to be spinning up and down when gaming, when gaming, the second sensor is hotter than the first sensor. Due to the window is narrower on the second sensor, the fan speed is changing 12.5% when the temperature is 1C hotter or cooler, this is very noticable, it feels like the fan motor is controlled by bypassing resistor banks instead of PWM, but actually it’s PWM. If you $ sudo ectool fanduty 80
then 81, 82, 83,… 90 you’ll find the fan speed completely not noticable, and if you from 90 back to 85 then 80 the noise change is barely noticable.
I am seeing this behavior on my Framework 13 11th Gen Intel laptop. Is this issue specific to AMD laptops, or will my laptop benefit from the future ec firmware fixes, too?
@Matt_Hartley Given the excellent write up from @Charlie_6, can this issue be handed off to engineering for a hopeful fix?
I can replicate on my fresh install (Fedora Kinoite 40 on Framework 13" AMD 7040)
I am tracking this for a resolution to the issue. The fan noise is changing my experience from “have recommended framework to others who bought one”, to: “going to set up a desktop and just use this machine when necessary, because the fan is so annoying”.
I hope there is a solution that can bring the computer into an acceptable function.
Is this fixable by setting your own values via ectool for the fan curve? I believe you can customize the whole table.
I have not tried yet but I do get pulses sometimes. I have not attempted to rectify the issue.
actually the real problem is this Fan_off temperature 376 K, which is 103 DegC! Thus the fan never speeds up before frequency throttling. Reasonable fan_off temp should be 40-60C, i.e. 313 K - 333 K