You are not logged in.
Hello,
powertop reports the following three problems when I boot into graphical target:
Wireless Power Saving for interface wlan0
VM writeback timeout
Enable Audio codec power management
when I boot into the multi-user.target powertop tells me that these three settings are good.
I'm using systemd and in /etc/sysctl.conf I have the following line
vm.dirty_writeback_centisecs = 1500
which at least for the multi-user.target seems to set the VM writeback timeout.
I've appended the following line to my /boot/syslinux/syslinux.cfg
snd_hda_intel.power_save=1
which also seems to work when booting into the multi-user.target . The snd_hda_intel driver is compiled into the initial ramdisk by adding snd_hda_intel to the MODULES section of /etc/mkinitcpio.conf.
Can anybody give me some hints on how to find out what causes that the values are overwritten when I boot into the graphical target?
My first idea was to boot into the multi-user target, set a monitor to /sys/module/snd_hda_intel/parameters/power_save and then switch to the graphical target to find out which process writes to the power_save entry. But I haven't found how to monitor which processes are trying to access a file.
The next attempt was a brute force search in all files which searched for "power_save". I was hoping to find a process with that contained that string. Perhaps I was a little bit too naive here, but this search didn't return anything interesting.
Now I'm lost and stuck because I have no idea what I could do next to find out what causes that these values are overwritten. Any suggestions would be gladly appreciated.
Best regards
Martin
Offline
Are you using pm-utils? What DE are you using?
ps: i do not use systemd, but i don't think your problem is related to it!
Offline
Hi Nierro,
You're right I'm using pm-utils and systemd wasn't the culprit. I have pm-utils installed on my system as it is a dependency of upower which in turn is a dependency of kdelibs.
A quick fix for the problem can be found here: Laptop power saving script for #! & Debian
I think I understand now what happens:
There are several places where the power management options get changed:
You can use systemd to set several power setting options: Power Saving With Systemd. There is also the commented file "/etc/sysctl.conf" where you can change some settings.
Kernel boot parameters, for example the snd_hda_intel.power_save=1 mentioned above
Settings by pm-utils
What happened on my system was the following: The kernel booted with the power setting set by the kernel command line parameter. When the graphical.target was started upower was started which signaled pm-utils that the laptop was on AC-power. This triggered some scripts which are located in /usr/lib/pm-utils/power.d/.
One of these scripts is called intel-audio-powersave and it will disable powersave for audio if the Laptop is on AC-power.
I have created a script where I took this one as a reference: Laptop power saving script for #! & Debian. This script will overwrite the values written by the scripts in /usr/lib/pm-utils/power.d/. This is where I'm at right now.
Now I've read about laptop-mode-tools which seem to be an even better fit for customizing what happens if the laptop is running on battery or ac-power.
Out of curiosity I have a question though: Is this the order in which the power management changes are propagated?:
Without laptop-mode-utils installed:
upower detects a change and sends an event
Event is registered by pm-utils which in turn executes the power management scripts
With laptop-mode-utils installed:
upower detects a change and sends an event
Event is registered by laptop-mode-utils which will execute the events configured in laptop-mode.conf
pm-utils will only execute the scripts according to the configuration of laptop-mode-utils
Offline