New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLP wrongly starting in battery mode #313

Closed
twifty opened this Issue Dec 30, 2017 · 9 comments

Comments

Projects
None yet
3 participants
@twifty

twifty commented Dec 30, 2017

A recent kernel upgrade from 4.9 to 4.14 has triggered a power issue on my audio card. I've tracked the problem down to TLP correctly starting in AC mode for the 4.9 kernel and BAT mode for the 4.14. In my case power_save was enabled for the audio card causing a speaker buzz.

I use a desktop PC, so there is no battery. TBH I'm not even sure if my system needs TLP, it came with the default Manjaro install. However, I do use a wireless keyboard (Logitech K800) and wireless mouse (Logitech Performance MX rechargable). I'm guessing, combined with the newer kernel, TLP is detecting the state of these batteries and incorrectly thinking the system is battery powered.

Please let me know if there is any other debugging information I can provide.

tlp-stat 4.9
tlp-stat 4.14

@linrunner

This comment has been minimized.

Show comment
Hide comment
@linrunner

linrunner Dec 30, 2017

Owner

Hi,

obviously a regression from kernel 4.9 to 4.14. Just for the record please show power supply data:

tlp-stat --psup

(for 4.9 and 4.14).

I suggest you file a bug report against the kernel.

I'd try a BIOS update too.

In the meantime you may change TLP's configuration as a workaround:

TLP_DEFAULT_MODE=AC
TLP_PERSISTENT_DEFAULT=1

(forces TLP into AC mode).

Owner

linrunner commented Dec 30, 2017

Hi,

obviously a regression from kernel 4.9 to 4.14. Just for the record please show power supply data:

tlp-stat --psup

(for 4.9 and 4.14).

I suggest you file a bug report against the kernel.

I'd try a BIOS update too.

In the meantime you may change TLP's configuration as a workaround:

TLP_DEFAULT_MODE=AC
TLP_PERSISTENT_DEFAULT=1

(forces TLP into AC mode).

@twifty

This comment has been minimized.

Show comment
Hide comment
@twifty

twifty Dec 30, 2017

The power supply data for the 4.14 kernel:

/sys/class/power_supply/hidpp_battery_0/type:Battery
/sys/class/power_supply/hidpp_battery_0/online:1
/sys/class/power_supply/hidpp_battery_1/type:Battery
/sys/class/power_supply/hidpp_battery_1/online:1

I'm guessing confirmed that these two batteries correlate to my keyboard and mouse by powering them off and re-running the command.

For the 4.9 kernel, there is no output.

--- TLP 1.0 --------------------------------------------

+++ Power supply diagnostic

My BIOS is already up to date, in fact the board is an old ASUS M4A78LT-LE, a new BIOS hasn't been released in years.

Do you really think this is a kernel bug? I don't know how TLP distinguishes between AC and BAT, but if the kernel is reporting to TLP that my desktop PC is battery powered then I'll most certainly file a bug report. I came here first since TLP is changing my power settings.

I'll try your suggested config changes. I changed SOUND_POWER_SAVE_ON_BAT=0 as a workaround though a full AC mode sounds better.

twifty commented Dec 30, 2017

The power supply data for the 4.14 kernel:

/sys/class/power_supply/hidpp_battery_0/type:Battery
/sys/class/power_supply/hidpp_battery_0/online:1
/sys/class/power_supply/hidpp_battery_1/type:Battery
/sys/class/power_supply/hidpp_battery_1/online:1

I'm guessing confirmed that these two batteries correlate to my keyboard and mouse by powering them off and re-running the command.

For the 4.9 kernel, there is no output.

--- TLP 1.0 --------------------------------------------

+++ Power supply diagnostic

My BIOS is already up to date, in fact the board is an old ASUS M4A78LT-LE, a new BIOS hasn't been released in years.

Do you really think this is a kernel bug? I don't know how TLP distinguishes between AC and BAT, but if the kernel is reporting to TLP that my desktop PC is battery powered then I'll most certainly file a bug report. I came here first since TLP is changing my power settings.

I'll try your suggested config changes. I changed SOUND_POWER_SAVE_ON_BAT=0 as a workaround though a full AC mode sounds better.

@twifty

This comment has been minimized.

Show comment
Hide comment
@twifty

twifty Dec 30, 2017

I've just had a look at the get_sys_power_supply function and I think I see the problem.

My /sys/class/power_supply directory contains only two links to both my keyboard and mouse. The loop in the above function detects these and detects the battery, but it continues looking for a 'Mains'. Since there is no mains, it thinks 'Battery' is correct. The problem is, they are peripheral batteries.

Perhaps the loop could read and ignore a 'Logitech' value in the 'manufacturer' file. Or, you could read a combination of manufacturer and model_name ('K800' and 'Performance MX' in my case). I see something similar is already being done for the 'MacBook Pro 2017 sbs-charger'. Logitech only create peripheral devices as far as I'm aware, so ignoring them should not cause any problems.

I only discovered this problem because my speakers started making a buzzing sound with the new kernel. I'm going to guess many more people on desktop PC's are running in battery mode without even knowing it (just because a wireless battery powered device is being detected but a 'Mains' device is not).

twifty commented Dec 30, 2017

I've just had a look at the get_sys_power_supply function and I think I see the problem.

My /sys/class/power_supply directory contains only two links to both my keyboard and mouse. The loop in the above function detects these and detects the battery, but it continues looking for a 'Mains'. Since there is no mains, it thinks 'Battery' is correct. The problem is, they are peripheral batteries.

Perhaps the loop could read and ignore a 'Logitech' value in the 'manufacturer' file. Or, you could read a combination of manufacturer and model_name ('K800' and 'Performance MX' in my case). I see something similar is already being done for the 'MacBook Pro 2017 sbs-charger'. Logitech only create peripheral devices as far as I'm aware, so ignoring them should not cause any problems.

I only discovered this problem because my speakers started making a buzzing sound with the new kernel. I'm going to guess many more people on desktop PC's are running in battery mode without even knowing it (just because a wireless battery powered device is being detected but a 'Mains' device is not).

@jonathonf

This comment has been minimized.

Show comment
Hide comment
@jonathonf

jonathonf Jan 2, 2018

I don't think this is a kernel regression as Bluetooth devices will also report their battery status. Instead, TLP should probably make a distinction between HID devices and internal batteries.

A selection of random but related web links:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/1153488
https://lists.freedesktop.org/archives/devkit-devel/2013-September/001495.html
https://www.phoronix.com/scan.php?page=news_item&px=UPower-0.99.7-Released
https://askubuntu.com/questions/53880/is-there-any-way-to-check-the-battery-percentage-of-apple-wireless-peripherals

jonathonf commented Jan 2, 2018

I don't think this is a kernel regression as Bluetooth devices will also report their battery status. Instead, TLP should probably make a distinction between HID devices and internal batteries.

A selection of random but related web links:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/1153488
https://lists.freedesktop.org/archives/devkit-devel/2013-September/001495.html
https://www.phoronix.com/scan.php?page=news_item&px=UPower-0.99.7-Released
https://askubuntu.com/questions/53880/is-there-any-way-to-check-the-battery-percentage-of-apple-wireless-peripherals

@linrunner

This comment has been minimized.

Show comment
Hide comment
@linrunner

linrunner Jan 2, 2018

Owner

@twifty: thanks for your data. So the solution is to exclude devices named "hidpp_battery_*".

Owner

linrunner commented Jan 2, 2018

@twifty: thanks for your data. So the solution is to exclude devices named "hidpp_battery_*".

@linrunner linrunner self-assigned this Jan 2, 2018

@linrunner linrunner added this to the 1.1 Release milestone Jan 2, 2018

@linrunner linrunner added the planned label Jan 2, 2018

linrunner added a commit that referenced this issue Jan 2, 2018

Issue #313: don't detect wireless input devices' batteries as power
supply

Rationale: wireless input devices - e.g. Logitech mice and
keyboards - expose their batteries below /sys/class/power_supply
with recent kernels.

Solution: ignore /sys/class/power_supply/hidpp_battery*.

Refererence:
* Issue #313: #313
@linrunner

This comment has been minimized.

Show comment
Hide comment
@linrunner

linrunner Jan 2, 2018

Owner

Power supply detection keeps tricky ... sigh.

@twifty: please test the fix. You may use the 1.1 beta packages from AUR or apply by hand to your 1.0.

Owner

linrunner commented Jan 2, 2018

Power supply detection keeps tricky ... sigh.

@twifty: please test the fix. You may use the 1.1 beta packages from AUR or apply by hand to your 1.0.

@twifty

This comment has been minimized.

Show comment
Hide comment
@twifty

twifty Jan 2, 2018

@linrunner I can confirm 1.1 beta works correctly.

twifty commented Jan 2, 2018

@linrunner I can confirm 1.1 beta works correctly.

@linrunner

This comment has been minimized.

Show comment
Hide comment
@linrunner

linrunner Jan 3, 2018

Owner

Thanks for your feedback. Have a nice day.

Owner

linrunner commented Jan 3, 2018

Thanks for your feedback. Have a nice day.

@linrunner

This comment has been minimized.

Show comment
Hide comment
@linrunner

linrunner Jan 24, 2018

Owner

Released.

Owner

linrunner commented Jan 24, 2018

Released.

@linrunner linrunner closed this Jan 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment