Wrong START and STOP threshold reads on some laptops

[teleshoes]

this bug concerns ONLY the output of "tpacpi-bat -g ST" and "tpacpi-bat -g SP". setting thresholds and the actual charging behaviour work properly.

on the affected laptops, the thresholds are set correctly and are honored, but they are reported incorrectly by the BIOS. {the last call to -s either ST or SP is reported for both -g}

as the bug is actually in the BIOS, there is no known workaround.

[teleshoes]

known affected models:

• ThinkPad S430
• ThinkPad Edge E130

to test if this is true on your laptop+BIOS, run:

tpacpi-bat -s ST 1 60
tpacpi-bat -s SP 1 80
tpacpi-bat -g ST 1 # should print: 60 (relative percent)
tpacpi-bat -g SP 1 # should print: 80 (relative percent)

if both "-g"s print the SAME number instead of 60 and 80, your laptop is affected.

[dkasak]

Also affected: ThinkPad Edge E520

EDIT: Actually, the bug seems to be a bit different on E520. Only the ST setting seems to change the output of both ST and SP while changing SP leaves the output of both unchanged.

[kljohann]

X131e also seems to be affected. I have not checked yet whether the charge behaviour is correct and only the output of -g is wrong.

(maybe unrelated but tp-smapi also only has a stop threshold here)

$ cat /sys/devices/platform/smapi/BAT0/stop_charge_thresh
80
$ cat /sys/devices/platform/smapi/BAT0/start_charge_thresh
cat: /sys/devices/platform/smapi/BAT0/start_charge_thresh: Operation not supported

[Gee-Bee]

S440 is also affected.

[jmstark]

L540 seems also affected, however I didn't check yet if the charge behaviour itself is correct.

[sgh]

Could be the case on Lenovo Yoga 15 as well. I get "218 (unknown)" on both ST and SP. Does match with the wrong values from the other models that you have mentioned?

[heyvoon]

Lenovo Ideapad Z500... This is so messed up! I will have to end up installing Windows just to get this battery setting working! Unbelievable! My battery is stuck at 59% on Linux Mint 17.

Error: AE_NOT_FOUND for ASL base: _SB.PCI0.LPCB.HKEY
Error: AE_NOT_FOUND at ./tpacpi-bat line 409.

[teleshoes]

ideapads dont have this interface at all. which sucks, because afaik, no one has found a way to control the batteries on linux at all for ideapads. (could be wrong about that, i dont have an ideapad)

as for getting it unstuck, you can get windows 8 on a thumbdrive, boot from it, unset the thresholds, then burn the USB stick as it will be forever tainted.

note however, THIS bug (which you do not have because you dont have a thinkpad) occurs only on select thinkpads, and affects only the output of tpacpi-bat -g ST and tpacpi-bat -g SP

[teleshoes]

you could also try restting the CMOS to see if it clears your threshold. (remove laptop battery, unplug the AC, and hold the power button down for 30s, then press it again briefly 10 times, then hold it down for 30s)
this should reset all BIOS settings, etc, and may or may not fix your problem

[heyvoon]

Would be nice to try to run the Lenovo Energy Management under Wine!

http://support.lenovo.com/gb/en/downloads/ds037135
http://support.lenovo.com/gb/en/downloads/ds029488

Even dough I don't like to een have Wine installed. But I think is a easy path to try.
Let u guys know soon.

[alexpeits]

Is there anything new regarding this issue? When I set ST and SP, the same threshold is shown with -g, and I the battery gets stuck in the stop threshold (thinkpad 13, using a fork that has the acpi path hardcoded)

[teleshoes]

@alexpeits the bug concerns ONLY the output of -g ST and -g SP.
to the best of my knowledge, the actual starting and stopping works as intended, even on the affected laptops.

as for fixing this bug (the display of the -g commands), its impossible without reverse engineering the bios.

[alexpeits]

@teleshoes thanks for the answer. The weird thing that happens is that the battery gets charged up to the stop threshold, and then just stays there. tlp reports unknown status and enabled battery thresholds.

I guess it is just my thinkpad model (TP 13 is actually S2, which is closer to a yoga pad).

[teleshoes]

heh, that is exactly what the stop threshold means. i dont know what you think its supposed to do...

[alexpeits]

So if the percentage stays at this value, it is safe to just leave the AC connected (which means that the battery is not used at this point, and the laptop operates from AC)? (sorry for the off-topic)

[teleshoes]

yup, thats the point of the thresholds. if you leave your laptop plugged in all the time, your battery will last an extra year or so if you leave it at 80% instead of 100%. (when youre going to travel or whatever, just remove the threshold and charge it up to 100%).
also, if you unplug the laptop, it will still switch instantly to battery, so no risks.

[linrunner]

thinkpad 13, using a fork that has the acpi path hardcoded

Please tell us that path. How did you find it?

[alexpeits]

this is the fork I am using. The maintainer told me in a reddit discussion that the auto discovery is not working, but setting aslBase to '\_SB.PCI0.LPCB.EC.HKEY' makes it work (relevant commit).

[teleshoes]

@alexpeits interesting, i didnt know the autodetect was broken for some folks.
can you do me a favor and run this in a bash terminal and paste the results (if any):
for x in /sys/class/power_supply/{BAT0,BAT1,AC,ADP0,ADP1}/device/path; do if [ -f $x ]; then echo -n "$x: "; cat $x; fi; done

[alexpeits]

No problem, here it is:

$ for x in /sys/class/power_supply/{BAT0,BAT1,AC,ADP0,ADP1}/device/path; do if [ -f $x ]; then echo -n "$x: "; cat $x; fi; done
/sys/class/power_supply/BAT1/device/path: \_SB_.BAT1

[emariz]

I recently purchased a Thinkpad E470 and this week I installed and configured tpacpi-bat.
As other users have noted, the thresholds themselves seem to be correctly set (I am still testing different scenarios, but it works so far), but the 'view/ get' command is borked. This confused me at first, for I thought that I had misunderstood and mixed up the 'set' parameters, yet the issue persisted after reviewing and resetting the command.
The system is running Debian Testing.
4.17.0-1-amd64 #1 SMP Debian 4.17.8-1 (2018-07-20) x86_64 GNU/Linux

In my case, if the output of the first issue of '-g' is wrong, the output of the successive issues of the same command is correct. If the parameters of '-g' are changed, the problem repeats: the first output is wrong, and the successive ones are correct.

$ systemctl status tpacpi-bat
Loaded: loaded (/etc/systemd/system/tpacpi-bat.service; enabled; vendor preset: enabled)
   Active: active (exited) since Thu 2018-08-16 18:59:53; 41min ago
  Process: 539 ExecStart=/usr/bin/tpacpi-bat -s stop 1 80 (code=exited, status=0/SUCCESS)
  Process: 514 ExecStart=/usr/bin/tpacpi-bat -s start 1 40 (code=exited, status=0/SUCCESS)
 Main PID: 539 (code=exited, status=0/SUCCESS)

The first output is wrong:

# tpacpi-bat -v -g start 1
Call    : \_SB.PCI0.LPC.EC.HKEY.BCTG 0x1
Response: 0x350lled
80 (relative percent)

But the following outputs are correct:

# tpacpi-bat -v -g start 1
Call    : \_SB.PCI0.LPC.EC.HKEY.BCTG 0x1
Response: 0x328lled
40 (relative percent)

# tpacpi-bat -v -g start 1
Call    : \_SB.PCI0.LPC.EC.HKEY.BCTG 0x1
Response: 0x328lled
40 (relative percent)

When the -g parameters are changed, the output is once again mixed up:

# tpacpi-bat -v -g stop 1
Call    : \_SB.PCI0.LPC.EC.HKEY.BCSG 0x1
Response: 0x328lled
40 (relative percent)

But it is correct afterwards:

# tpacpi-bat -v -g stop 1
Call    : \_SB.PCI0.LPC.EC.HKEY.BCSG 0x1
Response: 0x350lled
80 (relative percent)

# tpacpi-bat -v -g stop 1
Call    : \_SB.PCI0.LPC.EC.HKEY.BCSG 0x1
Response: 0x350lled
80 (relative percent)

Some information from dmidecode.

System Information
	Manufacturer: LENOVO
	Product Name: 20H1A01XAC
	Version: ThinkPad E470

BIOS Information
	Vendor: LENOVO
	Version: R0DET95W (1.95 )
	Release Date: 06/16/2018

Portable Battery
	Location: Front
	Manufacturer: SMP
	Name: 01AV413
	Design Capacity: 45280 mWh
	Design Voltage: 11100 mV
	SBDS Version: 00.00
	Maximum Error: Unknown
	SBDS Serial Number: 1C84
	SBDS Manufacture Date: 2017-09-30
	SBDS Chemistry: LiP
	OEM-specific Information: 0x00000000