I am running Fedora 39 on my new Framework Laptop and I am experiencing bad battery life and high Temperatures in idle. For example while i am writing this I temps of around 42 °C with only Firefox open and the fans are running.
While I was locking into the issue I noticed in lm_sensors that the GPU is drawing roughly 10 Watts all the time.
I took this screenshot with the command watch sensorson a Live image of Fedora 39 so that I can verify that non of my installed packages cause this issue but I see the same behavior on my Silverblue 39 install.
I am on the bios version 3.03 and the only change I made in bios is enabling secure boot and setting Advanced->iGPU Configuration->UMA_GAME_OPTIMIZED because of this issue. But the issue was there before changing the VRAM allocation.
I have not found anyone else talking about this issue on here but maybe I am not the only one experiencing this issue.
I’m not on silverblue but noticed that the default f 39 install kept ;nomodeset’ kernel param after install which meant that I was seeing high draw because kms was not being used properly. (Amongst other poor performance)
@jwp I checked and ran the commands in the picture below and did not see nomodeset in the output. I’m not sure if those are the correct commands to see the kernel param, these are just the ones a quick google search brought up first. I also checked /etc/default/grub and didn’t see it in there.
Thanks for being so welcoming, did not expect this much support.
Based on your post I did not test the Ublue image idea from @jwp for now.
I did install powerstat and ran it with only the GNOME wayland season running, on battery, power saver profile and a terminal window open and this is the result:
The power draw is much lower then reported by watch sensors and I don’t really have any context to evaluate this result properly. My instinct tells me thats 5.5 Watts in idle is still to high.
Regarding my browser, Firefox report to be using hardware acceleration.
Because of TLP / PPD i did not change anything from the stock Silverblue experience, this is the tests I ran to check whats running on my Laptop and it seems correct to me.
Okay that’s sounds like good news, but how can 5 watts cause the temperatures to be at 40 °C. Shouldn’t passive heat participation work better than that? Because even a small load makes the fans kick on.
40 Deg is absolutely freezing by inner working of IC perspective. Also amdgpu reports a Junction (hot spot) and package temp. You can pretty much ignore the Junction Temp.
For reference an rdna3 desktop core is designed to operate at 80-90deg’s in normal operating load conditions. On my desktop 7900xtx I get idle temps between 50-70degs for desktop use and that’s with a huge heatblock and fan setup
Okay you are making very good point there. Seems like a lot has change in the last 5 years since I bought my last Laptop. I suppose then that everything I describe is totally normal and that the lm_sensors reading refers to something other then power consumption.
I thank you both for your time and effort and apologies for wasting it!
And now after looking a bit into it in general I found this post in another thread, so my experience is not unusual but seems to have nothing to do with Framwork or my individual Laptop itself and rather is a poor AMD Linux kernel driver for this chipset. I would have hoped because this chipset seems similar to the Steam Decks chipset that the driver would be finished, but I stand corrected.
This is probably why people are alarmed at seeing 5.5w.
I’ve seen many references where the Ryzen 6xxx series are consuming less power for the soc. I understand package power may be higher on the Framework but it does seem like the 7040 series could be idling lower.
For example, in suspend, the machine drains about 10%/hr which is another indication that perhaps ASPM isn’t being fully utilized.
For reference using powertop to monitor; on plain ol fc39 my idle with browser open and bluetooth off and Screen backlight set at 20% is around 5-6W
It’s dropped a bit with the rawhide kernel and mesa-git (about a watt or so in same scenario) to be around 3.5-4.5W ; which is currently using the 6.7 upstream kernel.
5.5W overall seems right. But your sensors output readings are very very normal looking. The PPT value isn’t a Watt draw it’s a composite thermal performance per watt draw reported by the APU die based on it’s current power state setting. For reference it should likely go up to something like 65W when running games etc (although i’m not sure it may be lower for the Zen4 mobile chip vs the Zen3 APU i’m comparing it too). For My desktop RDNA this sits similarly between 10W and 144W.
If you want to look at instaneous Package and core per watt reporting use turbostat; and for overall power monitoring powertop. Plasma also has a nice graph in the Energy section of it’s info-centre.
For reference mixed usage should be around 6hrs estimated. And optimized power saving Idle around 9-10hrs (without Sleep/Hibernate states) .
Newer kernels will have a few more optimizations as 6.7 introduces some APU/CPPC state telemetry which isn’t in 6.5 at the moment which is probably why i’m getting slightly lower idle use from 6.7 rawhide kernel (despite it being a debug enabled build).
So long as you have amd_pstate-epp as your cpu freq driver listed in the output of : cpupower frequency-info you’re in a good place.
@Matt_Hartley ublue is working just fine on fw13 - just don’t use the -framework ostree overlay and just the default ublue:latest overlay and you’re golden.
This script is super helpful, I found some information not divulged in dmesg (which randomly shows i2c errors and amdgpu:drm errors that I cannot reliably reproduce).
I’ll try out rtc_cmos.use_acpi_alarm=1 for a bit and see how suspend goes.
✅ Userspace suspended for 0:00:11.917288
✅ Kernel suspended for total of 0:00:07.247000 (60.81%)
✅ In a hardware sleep state for 0:00:06.705047 (56.26%)
🔋 Battery BAT1 ( ) is operating at 91.94% of design
🚦 RTC driver `rtc_cmos` configured to use ACPI alarm
Explanations for your system
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
This one seems to jump all over the place but never does settle into the lower ranges described in the output. Is this a reporting error or can this apu really clock down to 400mhz?
mikey@mopbook:~/Downloads$ cpupower frequency-info
analyzing CPU 12:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 12
CPUs which need to have their frequency coordinated by software: 12
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 5.92 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 5.92 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.79 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: no
mikey@mopbook:~/Downloads$ cpupower frequency-info
analyzing CPU 1:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 5.29 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 5.29 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 1.79 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: no
mikey@mopbook:~/Downloads$ cpupower frequency-info
analyzing CPU 13:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 13
CPUs which need to have their frequency coordinated by software: 13
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 5.92 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 5.92 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 2.85 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: no
You need to run it as root to get accurate reports from cpupower;
boost states mean mostly will clock down individual cores to 0 (run turbostat to see this); and 400mhz is a low power pstate ; part of the way zen3/4 work is that using CPPC hints per core the algorithm internally calculates what limits seem safe/attainable and dynamically changes the reported pstates 400mhz . There is a concept of power/perf ratings which is the metric number you see in the middle of the Pstate reporting in the output attached.
If you want to understand how the amd-pstate module works the kernel documentation is your goto for detailed info.
Strangely, this has dramatically improved my s2idle power consumption (20% after two days of suspend).
However my base power consumption when on has doubled, the laptop now idles at 7-10w, with the nic pinged at 100% according to powertop, but very little network activity reported by gnome system monitor.
