Open IntinteDAO opened 4 years ago
it seems that psutil
doesn't recognize the battery state: power_plugged=None
.
How did u install it, did u use snap?
BTW: didn't we met on reddit (just recognized same CPU lol)?
Nope. I have MSI Alpha 15 with dual Radeon GPUs. That's why I bought it :P
I install AUR version, but snap also have this problem. Ofc. this is hipotetical problem, because everything works, but I don't know if the program will go into power-saving mode.
Oh, I see, than it's not due to the snap sandboxing.
So, there is same bug in the psutil
upstream
https://github.com/giampaolo/psutil/issues/1647
Nope. I have MSI Alpha 15 with dual Radeon GPUs. That's why I bought it :P
I bought a laptop recently, specifically with integrated AMDGPU only :)
Closing due to inactivity.
I'm running into roughly the same problem. I set my battery charge threshold to 80% using asusctl for everyday use. And when used with power-profiles-daemon, the battery status is Not charging
as expected. However, with auto-cpufreq
it keeps changing between Discharging
(thus dropping below 80%) and Charging
(charges back to 80%).
I'm not sure if this is some sort of incompatibility between asusctl and auto-cpufreq.
I'm not sure if this is some sort of incompatibility between asusctl and auto-cpufreq.
I'm thinking there's a conflict between these two, as it is for example GNOME power profiles or TLP which auto-cpufreq works on disabling automatically or warning about them.
Since I don't know anything about asusctl, simple way to verify this problem is to disable it and see if yo still have the same problem with auto-cpufreq ...
Since I don't know anything about asusctl, simple way to verify this problem is to disable it and see if yo still have the same problem with auto-cpufreq ...
I tried, yet the problem was still around. However, it has got even weirder, that it occurs only when using USB PD adapter to charge. It doesn't trigger when using the vendor-provided power brick...
Now I suspect this is a firmware problem or so. Maybe power-profiles-daemon
carries workaround for it?
I've made a change to the battery charging detection, you can install manually with git clone https://github.com/Angel-Karasu/auto-cpufreq.git
and follow the installation guide, give a feedback if it's repare this problem or not
@Angel-Karasu Thanks
The battery in your code have status "Not charging" however in CPU frequency scaling is an information: Battery is discharging
Battery is discharging
Currently using: schedutil governor
Suggestion: Use of "schedutil" governor
Total CPU usage: 8.1%
Total system load: 1.62
Average temp. of all cores: 55.00°C
Load optimal (load average: 1.62, 1.65, 1.91)
Optimal total CPU usage: 8.1%, high average core temp: 55.0°C
Suggestion: Set turbo boost off
Info: Currently turbo boost is on
@Angel-Karasu Thanks
The battery in your code have status "Not charging" however in CPU frequency scaling is an information: Battery is discharging
Battery is discharging Currently using: schedutil governor Suggestion: Use of "schedutil" governor Total CPU usage: 8.1% Total system load: 1.62 Average temp. of all cores: 55.00°C Load optimal (load average: 1.62, 1.65, 1.91) Optimal total CPU usage: 8.1%, high average core temp: 55.0°C Suggestion: Set turbo boost off Info: Currently turbo boost is on
Is this the result when the battery is charging ? When you use fastfetch/neofetch, is the battery status correct ?
@Angel-Karasu Battery: 92% [AC Connected]
I have changed the detection method Try again: https://github.com/AdnanHodzic/auto-cpufreq/issues/83#issuecomment-2143434956
I have changed the detection method Try again: #83 (comment)
Weren't these changes merged as part of #716 and should be available with latest changes on master
branch?
I have changed the detection method Try again: #83 (comment)
Works :)
Battery is charging
Currently using: schedutil governor
Suggestion: Use of "performance" governor
Total CPU usage: 30.8%
Total system load: 1.84
Average temp. of all cores: 64.00°C
High CPU load (load average: 1.84, 2.52, 2.59)
Suggestion: Set turbo boost on
Info: Currently turbo boost is on
Error output:
System information:
I don't know if it's an error (translation), but according to auto-cpufreq (as I understand it), the battery is discharged even when it is plugged in. In my opinion the program can take bad values in boost management and so on (although I don't see that it would change anything).
Unless I'm stupid and I misunderstand something.