Debian User Forums

Sorry, i am currently to "noob" to currently do this and will definitely look into this, i cant really promise but will definitely reply if i get any progress

If you compile or use experimental(or use other kernel sources without installing their meta package), they basically stay fixed, nothing else gets upgraded, and you would only get updates to that kernel, but you may as well use debian 11, it is still supported fairly well

As i understand, this patch is (atleast currently) not in consideration to be backported, though they told battery life being decreased as a serious regression, best thing if you want it to be backported is to probably reply in the linked mail thread
If you are using a device which is effected (to check if at idle your cpus go to lower c states or not via powertop(or powerstat(though i believe with powerstat you would get a little more than idle)), dont check htop, as for these effected devices ...

Sorry for a silly and not really importnt question, but why is cpp-13 (~180 MiB) so much bigger than cpp-12 (~30 MiB), It cannot have really gained so much more code to get the size so big, so possibly (hypothesis) it is compiled for multiple architectures (how in android an apk can be compiled for for multiple aarchs and package size grows)
(Please dont reply saying storage space is cheap or something)
Sorry again

No it has been not backported, so unless that is done, 6.1 is no go, problem was due to the fact that, for some devices, if it would reach lower c states, and suspend, it may not wake up, and so they pushed a fix which fixed that by not letting it enter lower c states, but it affected many more devices

The problem was not fixed by updating to latest 6.1, but 6.4.0.1 (in testing) (and for unrelated reasons, i upgraded my whole system to testing)

for anyone still looking, this was a problem related to https://lore.kernel.org/all/20230627062 ... intel.com/

and as of today, kernels version 6.4+ are again working as inteded (though htop may still report incorrectly), both cpu scaling and C states are working

Thank You everyone

There is no load as when i do most of my power measurement, it is either a cold boot (with or without x), or leave my machine for like 5 mins untouched so that all the things that can be suspended (like browser tabs, text editor, or something else which is not constantly running other than the tool for measurement), so load is not high, using htop to get the cpu % usage, usually in such idle condition is like <0.1%. the power consumption at idle is essentially nothing but a number, (like if i ...

Old kernel cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 4294.55 ms.
hardware limits: 400 MHz - 3.70 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 400 MHz and 2.00 GHz ...

Booting into graphics(by adding kernel parameter 3), almost same power draw as that with graphics (1.973w vs 3.287w (best foot forward)), all other things are kept same (same daemons, same autostarts)(adding htop pictures from different boots(on a sidenote, how to save output of htop in aclearly formated text file, or take a screenshot in tty)), my claim is that it is the cpu governor being broken (or it previously being broken and now implemented differently), 1 thing powertop can do is guess ...

I have also tested with the 6.1 kernel (when it was in testing, and now when it is in stable), same behaviour as other newer kernels
i am using upower -d | grep energy-rate ( well i dont exactly use this one, i use a variant with the specificid of my baatery but it is effectively same, use this(upower -e) to get the ids and then use upower -i <id>), as far as i know, this method is just using the data as using /sys/class..... path for battery related stuff (for me /sys/class/power_supply/BAT0 ...

i forgot to mention, but i have been using testing since january 23, and unless i upgrade my kernel, it had no major impact on power draw (marginally reduced by maybe about 0.1 w on idle)
I am using a very non standard lxqt environment, and system as of today is almost exclusively bookworm stable only (other than kernel)

I am debian user since about August last year(2022), and a "linux" user since about feburary last year, but i am still fairly new (noob) and feel free to corect me for any of my mistakes, and I beg your pardon in advance for my poor spellings (or grammar)

I have experienced increased power usage in my device (an HP laptop notebook, from june 2022, Intel 11th gen i3, using kernel drivers + nonfree wifi drivers, no discrete gpu, only an igpu, the laptop seems to be well supported no other major ...