TDEPowersave loads CPU at 99% #136

Basic information

TDE version: Trinity R14.1.1
Distribution: Q4OS 5.2.1-n1 Aquarius, based on Debian Bookworm
Hardware: DELL Latitude E5450, Intel Core i5-5300U
https://i.postimg.cc/V6BkYq20/System-information-1.png
https://i.postimg.cc/Fzrs1fQW/System-information-2.png

Description

Good day!
This bug was confirmed by Q4OS Team: https://www.q4os.org/forum/viewtopic.php?id=4579
They asked me to report it here.

I have left my laptop unplugged from AC power. It was running on battery without my presence for about 10 minutes. When i came back, I was amazed! The fan was spinning like crazy, but when I opened Htop, the CPU usage was 99%!!
The process, which consumed all CPU power was tdepowersave [tdeinit].
I have not changed any TDEPowersave settings. Everything was default. Thank God, I came back quickly. I'm afraid to leave my laptop running on battery only. With constant 99% CPU, it can be easily overheated!
Please watch this video at 1080p quality:
https://drive.google.com/file/d/112ccu_4DjH-lBqXdLXuaKwkW_dcg1BW5/view?usp=drive_link
The system becomes completely irresponsible to any keyboard or mouse key-presses.
At the end I got this window:
https://drive.google.com/file/d/1151gTwesFPS8c3PwJdyUqC3OcKxa-nI4/view?usp=drive_link

Also, this man has similar bug like me.
https://www.q4os.org/forum/viewtopic.php?id=4566

Steps to reproduce

Install TDEPowersave application, do not change the default settings.
Leave Laptop without AC power adaptor plugged in running only from battery power for 10-15 minutes.
Notice, that CPU Usage was increased to 99%.
Open Htop and check the processes. You will see, that tdepowersave [tdeinit] consumes 99% of at least one CPU core.

Screenshots

Please watch this video at 1080p quality:
https://drive.google.com/file/d/112ccu_4DjH-lBqXdLXuaKwkW_dcg1BW5/view?usp=drive_link

## Basic information - TDE version: **Trinity R14.1.1** - Distribution: **Q4OS 5.2.1-n1 Aquarius, based on Debian Bookworm** - Hardware: **DELL Latitude E5450, Intel Core i5-5300U** https://i.postimg.cc/V6BkYq20/System-information-1.png https://i.postimg.cc/Fzrs1fQW/System-information-2.png  ## Description Good day! **This bug was confirmed by Q4OS Team: https://www.q4os.org/forum/viewtopic.php?id=4579 They asked me to report it here.** I have left my laptop unplugged from AC power. It was running on battery without my presence for about 10 minutes. When i came back, I was amazed! The fan was spinning like crazy, but when I opened Htop, the CPU usage was 99%!! The process, which consumed all CPU power was **tdepowersave [tdeinit]**. I have not changed any TDEPowersave settings. Everything was default. Thank God, I came back quickly. I'm afraid to leave my laptop running on battery only. With constant 99% CPU, it can be easily overheated! Please watch this video at 1080p quality: https://drive.google.com/file/d/112ccu_4DjH-lBqXdLXuaKwkW_dcg1BW5/view?usp=drive_link The system becomes completely irresponsible to any keyboard or mouse key-presses. At the end I got this window: https://drive.google.com/file/d/1151gTwesFPS8c3PwJdyUqC3OcKxa-nI4/view?usp=drive_link Also, this man has similar bug like me. https://www.q4os.org/forum/viewtopic.php?id=4566 ## Steps to reproduce 1. Install TDEPowersave application, do not change the default settings. 2. Leave Laptop without AC power adaptor plugged in running only from battery power for 10-15 minutes. 3. Notice, that CPU Usage was increased to 99%. 4. Open Htop and check the processes. You will see, that **tdepowersave [tdeinit]** consumes 99% of at least one CPU core. ## Screenshots Please watch this video at 1080p quality: https://drive.google.com/file/d/112ccu_4DjH-lBqXdLXuaKwkW_dcg1BW5/view?usp=drive_link

I can confirm I have come across this (or a similar) bug on my laptop. It did not involve watching a video but doing other tasks.

Hi @Rademes,
when does the CPU start to run at 100%? is it immediate? is it after a while? is it after a specific timer in TDEPowersave (perhaps the autodimm timer as in the Q4OS bug report)?

Also, does the problem only happens on battery or also on AC adapter (maybe need to change some of the settings to activate autodimm on AC power)?

Hi @Rademes,
when does the CPU start to run at 100%? is it immediate? is it after a while? is it after a specific timer in TDEPowersave (perhaps the autodimm timer as in the Q4OS bug report)?

CPU does not starting to run 99% immediately. As I figured out, it starts to run 99% after the autodimm timer activates autodimm feature. If I disable autodimm feature as Q4OS Team advised, the CPU does not run 99%.
Here is a video, which shows, that I have set the autodimm timer at 1 minute, and after 1 minute the CPU started to run 99%: https://drive.google.com/file/d/107QDrRnJibS8D0GSu4Z2JWDTZRWk-wf4/view?usp=drive_link

Also, does the problem only happens on battery or also on AC adapter (maybe need to change some of the settings to activate autodimm on AC power)?

Yes, exactly the same problem happens, when the laptop is working on AC power adapter.
Autodimm settings:
https://i.postimg.cc/9XnRMhMW/TDEPowersave-ACSetting.png
https://i.postimg.cc/dtZ7ZxkG/TDEPowersave-ACSetting1.png
After 1 minute without touching the laptop:
https://i.postimg.cc/3wYW6rLZ/TDEPowersave-CPU100.png
Then I had to reboot the system.

@Rademes
thanks for the detailed feedback, very useful. I can't reproduce the bug on my system, but will try to look through the code of tdepowersave to see if I can get a clue of what is happening.
I noticed other processes are also using lots of CPU when the problem happens, so it is possible the problem is in the tdehw library rather than in tdepowersave itself.

I also noticed dbus-daemon going a bit crazy in the video, so maybe the problem is between tdehw lib and the tdehw dbus daemon. Do you have the org/trinitydesktop/hardwarecontrol dbus system service running on your computer? If so, could you try disabling it and see if the problem still happens?
Also are you a standard user? or have you join specific groups or elevated to sudoer? Don't expect to make a difference, but just trying to collect more info.

@MicheleC
there was an issue with high CPU before and you mentioned it was fixed. Unfortunately I do not remember the number, but I think it was 1-2months ago.
Could it be you have the updated code on your machine?

I experience similar issue with kontact. after switching back and forth between knode and kmail at some point of time it uses 100% cpu.

It could be something from tqt, but I did not have the time to compile and test recently - will wait for September.

I am on debian bullseye and 14.1. I'm not sure if my comment helps in a meaningful way.

@Rademes
I also noticed dbus-daemon going a bit crazy in the video, so maybe the problem is between tdehw lib and the tdehw dbus daemon. Do you have the org/trinitydesktop/hardwarecontrol dbus system service running on your computer? If so, could you try disabling it and see if the problem still happens?

No, but I have running /opt/trinity/bin/tde_dbus_hardwarecontrol
https://i.postimg.cc/xjNwhwXk/hardwarecontrol1.png
https://i.postimg.cc/QC7v7T2g/hardwarecontrol2.png

Also are you a standard user? or have you join specific groups or elevated to sudoer? Don't expect to make a difference, but just trying to collect more info.

No, I am a standard user:
https://i.postimg.cc/tTwL75MC/id-valentina.png

@deloptes

there was an issue with high CPU before and you mentioned it was fixed.

That was with tdehwdevicemonitor, so it may or may not be related to this one.

@Rademes,

No, but I have running /opt/trinity/bin/tde_dbus_hardwarecontrol

Ok, this is the executable registering those dbus interfaces, so you do have the tdehw dbus daemon running :-) if you kill that process, does the problem still happens?
Also do you know your exact TDE version? R14.1.1 is not officially released, it's still in development, so it would be good to know what version of tdelibs your system has been build from. To find this, open Konqueror, go to /opt/trinity/bin, find the file dcop, right click and open the Properties dialog. In the Meta Info tab, look for SCM Revision and copy-paste the related string here.

Ok, this is the executable registering those dbus interfaces, so you do have the tdehw dbus daemon running :-) if you kill that process, does the problem still happens?

When I kill this process, it automatically relaunches again with another PID.

tdelibs.png

43 KiB

@Rademes thanks for all the feedback. I may have more question when I look into the code, see if I can understand what is wrong.

@Rademes
I have take a look at the code. Could you help doing a test as per following steps?

enable autodimm and set a dimm level (for example 80%)
lower your screen brightness to a level less than the autodimm level (for example 60%)
wait for the autodimm timer to expire. Do you still see the CPU going to 100%?

Also could you provide the output of the following command before autodimm is active and also when the CPU is running at 100%.?
dcop tdepowersave tdepowersaveIface brightnessGet

Can you also look into /sys/devices/ subsystem, find your backlight device(s) and let me know the contents of the files max_brightness, brightness and actual_brightness?
To quickly identify the backlight devices, you can open the Device manager from the Trinity Control Center and look up the system path of the devices under Backlight.

Good afternoon!
I am sorry for late reply, I had another important things to do.

OK, I had set up a dimm level at 80% and screen brightness level at 60% in TDEPowersave application. After autodimm timer expired, the CPU did not go to 99%.

Then I had set up a dimm level at 80% in TDEPowersave application, and then lowered screen brightness to 62% using Fn+F11 hotkey. After autodimm timer expired, the CPU did not go to 99%.

But, when I set up a dimm level at 80% and screen brightness level at 100% in TDEPowersave application, when timer expires, the CPU goes to 99%.

dcop tdepowersave tdepowersaveIface brightnessGet when the CPU is at 99%:
https://i.postimg.cc/VsMp8sSy/IMG-20230811-183001.jpg

dcop tdepowersave tdepowersaveIface brightnessGet when autodimm is inactive:
https://i.postimg.cc/rs6Hr3PY/IMG-20230811-183245.jpg

My Backlight device:
https://i.postimg.cc/BnhwgXzF/IMG-20230811-184937.jpg

When the screen brightness is at 100%, the files max_brightness, brightness and actual_brightness has the same content - number 937.
https://i.postimg.cc/ht45T92g/IMG-20230811-185357.jpg
https://i.postimg.cc/Qx3PxL5F/IMG-20230811-185412.jpg
https://i.postimg.cc/sD4LMn9w/IMG-20230811-185432.jpg

When I lower screen brightness at 50%, the files brightness and actual_brightness change the number to 469. max_brightness still has number 937.

I discovered another problem: When TDEPowersave is not running, The Fn+F11, F12 hotkeys does not working :( I can not change screen brightness.

Hi @Rademes,
thanks a lot for the detailed feedback. This will allow me to further progress the analysis since your answers confirm some of my initial finding. Expect more questions in coming days.

I am sorry for late reply, I had another important things to do.

No worries :-)

When TDEPowersave is not running, The Fn+F11, F12 hotkeys does not working :( I can not change screen brightness.

Yes, currently those hotkeys are provided by kmilo and they rely on tdepowersave for the actual actions. So if tdepowersave is not running, they won't work.

@Rademes
if I create a patch, are you able to build tdepowersave and test if it fixes the issue? if not, are you able to get Q4OS team to test it?

EDIT: I may have an easy solution for the 100% CPU usage, but then we will need to check whether autodimm works or not. That may require further testing/patches, so if you have the ability to build and test tdepowersave on your system that would be great. If not, you can ask Q4OS team to look at this bug report and help in troubleshooting by testing eventual patches.

EDIT 2: the reason for "then we will need to check whether autodimm works or not" is that in your video it did not look like autodimm worked, so once we are able to keep the CPU under control, then we can check whether that was a genuine problem or simply a consequence of the original 100% CPU issue.

@Rademes could you also do another quick test as follow? Thanks

set your screen brightness to a certain level (for example 90%)
enable autodimm and set a dimm level that is 1% less than the level above (for example 89%)
wait for the autodimm timer to expire. Do you still see the CPU going to 100%? if not, do you see any change in the luminosity of the display (should be 1% but it may be hard to spot)
if the CPU does not go to 100%, could you give me the output of dcop tdepowersave tdepowersaveIface brightnessGet?

I have tested it.
1. Dimm level 1% less than 90% actual brightness level.
CPU Load was 8%: https://i.postimg.cc/SRz1R0QQ/1-Load.png
brightnessGet: https://i.postimg.cc/KzWsmc2s/Brightness-Get1.png
2. Dimm level 5% less than 90% actual brightness level.
CPU Load was 30% on all cores: https://i.postimg.cc/hhWy7ChL/5-Load.png
brightnessGet: https://i.postimg.cc/3wncbCbh/Brightness-Get5-2.png
3. Dimm level 10% less than 90% actual brightness level.
CPU Load was 46% on all cores: https://i.postimg.cc/fWtMmJJy/10-Load.png
brightnessGet: https://i.postimg.cc/vBTNRgpV/Brightness-Get10.png
In all of above tests I have not noticed any change in the luminosity of the display.

@Rademes
if I create a patch, are you able to build tdepowersave and test if it fixes the issue? if not, are you able to get Q4OS team to test it?

It is a bit shame to say, but I never compiled packages, so I am not sure, will I be able to compile it correctly. Probably not.
I will write to Q4OS Team, but looks like they are busy now, so this can take some time for them to test it. As far as I know, now, they are testing MX Tools, so thew would work with Q4OS.

EDIT: I may have an easy solution for the 100% CPU usage, but then we will need to check whether autodimm works or not. That may require further testing/patches, so if you have the ability to build and test tdepowersave on your system that would be great. If not, you can ask Q4OS team to look at this bug report and help in troubleshooting by testing eventual patches.

I am not sure, I have never built any packages before. Better to ask Q4OSTeam to build and test it.

EDIT 2: the reason for "then we will need to check whether autodimm works or not" is that in your video it did not look like autodimm worked, so once we are able to keep the CPU under control, then we can check whether that was a genuine problem or simply a consequence of the original 100% CPU issue.

Yes, I have also noticed, that autodimm does not working when I use TDEPowersave. I have never noticed any changes in display luminosity. Just CPU usage jumps to high levels.

Update:
Q4OSTeam agreed to build and test tdepowersave: https://www.q4os.org/forum/viewtopic.php?pid=25178#p25178

@Rademes thanks again for testing, this confirms we are moving in the right direction. There are at least two problems:

CPU going 100%: this is likely a TDEPowersave issue and should be relatively easy to fix. I will prepare a patch for it today.

2. brightness values seems to be wrong (negative in your case): this is likely a problem somewhere in tdehw lib and will need further investigation to understand why it happens. This is probably why autodimm doesn't work on your computer.
EDIT: previous sentence is probably not correct, I need to investigate further but the problem may be limited to tdepowersave only. In that case it would be even better :-)

Good that Q4OS will help in building/testing. It will be useful if they can pass the patched code to you for testing on your local machine too.

There is also a set of debian-based scripts that makes building TDE packages extremely simple once the initial configuration is done. If you are willing to give it a try, I will point you to them (probably after I do a review of the instructions to make sure everything is up to date). This would simplify collecting information when looking into the tdehw lib issue.

@Rademes good news, I am able to reproduce the problem on a test machine, that will allow me to test patches or get debug info locally.

@Rademes good news, I am able to reproduce the problem on a test machine, that will allow me to test patches or get debug info locally.

That is really good news! This will make testing and fixing easier for both of us.

brightness values seems to be wrong (negative in your case):

Yes, I also wondered, why all brightness values are negative.

brightness values seems to be wrong (negative in your case):

Yes, I also wondered, why all brightness values are negative.

This is actually caused by what I think is a tdepowersave bug. Will probably rework this to provide a result in the range 0-100%, but it will need parallel changes into tdeutils, so I will do this after fixing the CPU/dimm issue.

@Rademes
PR TDE/tdepowersave#14 fixes the issue with CPU going to 100% and with autodimm functionality (and a couple of other minor things). I tested locally and seems to work fine but will be good to have further feedback. Can you get Q4OS team to try it out on their hardware and report whether the problem is fixed for them too?

@Rademes
if you want to test locally on your computer, I have attached a compiled package. It can be installed on the current Q4OS acquarius build and used for testing. This will let you test on your computer without the need to compile, as long as your architecture is amd64.

To test follow these steps:

download the package and rename the file from .txt to .deb
install the package with sudo dpkg -i --force-all tdepowersave-trinity_14.2.0~pre7-0debian13.0.0+0~a_amd64.deb from Konsole. You need --force-all to overwrite depedency issues, but I tested it in Q4OS Acquarius and it works fine (basically it overwrites existing tdepowersave files)
exit tdepowersave and launch it again. Setup autodimm and test as usual.

This package is a test package, so it prints quite a bit of info when autodimm is active. If for any reason autodimm still have issues, please relaunch tdepowersave from Konsole, capture the text during the test and upload it here so that I can see what tdepowersave is doing.

If the test is successful, I suggest you revert to the official tdepowersave package and wait till the patched new version becomes available (or you can use the existing test package till then if you can live with the extra messages during autodimm).

tdepowersave-trinity_14.2.0~pre7-0debian13.0.0+0~a_amd64.txt

2.7 MiB

Currently the package contained in PSB repository is built with a patch from TDE/tdepowersave#14. If I understand correctly, Q4OS Acquarius uses apt source PSB, so to test there it should be enough to make an update.

PSB means Preliminary Stable Builds

Currently the package contained in PSB repository is built with a patch from TDE/tdepowersave#14. If I understand correctly, Q4OS Acquarius uses apt source PSB, so to test there it should be enough to make an update.

No, Q4OS Aquarius uses its own repository.
deb http://q4os.org/qtderepo bookworm main
deb-src http://q4os.org/qtderepo bookworm main

@Rademes
if you want to test locally on your computer, I have attached a compiled package. It can be installed on the current Q4OS acquarius build and used for testing. This will let you test on your computer without the need to compile, as long as your architecture is amd64.

I am very sorry, but now I have to use this notebook as my work computer, so now I can not test anything on it. I will test when my work will be finished, but this will take some time. Probably, Q4OS team will test faster than me. https://www.q4os.org/forum/viewtopic.php?pid=25192#p25192

Ok, will wait for Q4OS testing before we merge the fix, no worries. Please ping us here once the testing has been done.

Good news!
Q4OSTeam have tested your patch, and it solves the issue!
https://www.q4os.org/forum/viewtopic.php?pid=25259#p25259

PR #14 merged. Thanks all for reporting and testing.