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

battery management on thinkpad yoga 12 #183

Closed
voland66 opened this Issue Jan 26, 2016 · 20 comments

Comments

Projects
None yet
2 participants
@voland66

voland66 commented Jan 26, 2016

Hi,

I have some problems with charging thresholds on thinkpad yoga 12 (2nd generation). It is possible that these issues eventually led to battery being permanently turned off (at least as far as anything I knew to try).

First issue:
I installed acpi-call (without tp-smapi as that one seems to be inactive anyway) and could set charging thresholds to, say, 76-80. First thing I noticed was that the thresholds have some "favorite" values and generic values won't be set. More importantly, changing thresholds in any way is unreliable. For example running "tlp fullcharge" with battery at 80% does not usually work. Changing thresholds in the configuration file and then restarting tlp does not work. Restarting laptop (with changed thresholds) does not work. I needed to let the battery discharge (not sure how far, probably below the start threshold but certainly at least a bit) before it would start charging (at that point tlp fullcharge would work).

Potentially related issue:
Later I noticed that sometimes unplugging laptop would immediately turn it off as if there is no battery. Similarly, sometimes I would notice that battery is not charging even when it is below the start threshold. Eventually, I ended up with battery stuck at around 15% and fully disconnected (i.e. it would neither charge nor discharge, uplugging or "tlp discharge" would turn off the laptop). I believe uninstalling acpi-call did not help. Changing the battery did not help (Windows would not see new battery at all, Linux reported completely discharged battery with 0 capacity etc.). I ended up changing motherboard under warranty but the first issue above came back so for now I uninstalled acpi-call.

I did not associate the two issues at first but then googling for reports of similar problems I noticed that even Lenovo's own windows software/firmware may have been reported as having a potential of turning off the battery. One of Lenovo technicians mentioned that as a possibility...
I am not sure if the two issues are related but if they are, it is probably important to either fix them or blacklist hardware that may have problems.

@linrunner

This comment has been minimized.

Owner

linrunner commented Jan 26, 2016

Hi, sorry to read of such issues.

Fix: only Lenovo can and should(!) fix their faulty firmware.

Blacklisting: i need the output of

tlp-stat -s
cat /sys/class/dmi/id/{product_version,product_name,bios_version}

EDIT:

  • Please provide me with some links to the mentioned "similar problems"
  • Is Yoga 12 the only affected model?

EDIT2: please be more specific about "favorite thresholds":

  • Do your symptoms correspond to the quirky behaviour mentioned in the FAQ?
  • Which values did you configure and what was the output of tlp-stat -b?

@linrunner linrunner self-assigned this Jan 26, 2016

@voland66

This comment has been minimized.

voland66 commented Jan 26, 2016

Just to clarify one comment in your reply: you are saying that this is a
firmware bug, right? Does it also mean that in your opinion two issues
are related or could the second issue just be a faulty motherboard?

Anyway, output of requested commands is below (run without acpi-call
installed, should be enough for blacklisting?):

tlp-stat -s
--- TLP 0.8 --------------------------------------------

+++ System Info
System = LENOVO ThinkPad S1 Yoga 12 20DL0032US
BIOS = JEET71WW (1.20 )
Release = "Fedora release 23 (Twenty Three)"
Kernel = 4.3.3-301.fc23.x86_64 #1 SMP Fri Jan 15 14:03:17 UTC
2016 x86_64
/proc/cmdline = BOOT_IMAGE=/vmlinuz-4.3.3-301.fc23.x86_64
root=/dev/mapper/fedora_woland-root ro rd.lvm.lv=fedora_woland/root rhgb
quiet LANG=en_US.UTF-8 acpi_osi=Linux resume=/dev/sdb1
Init system = systemd

+++ System Status
TLP power save = enabled
power source = AC

cat /sys/class/dmi/id/{product_version,product_name,bios_version}
ThinkPad S1 Yoga 12
20DL0032US
JEET71WW (1.20 )

On 01/26/2016 11:26 AM, linrunner wrote:

|cat /sys/class/dmi/id/{product_version,product_name,bios_version}|

@linrunner

This comment has been minimized.

Owner

linrunner commented Jan 26, 2016

I have no opinion yet if the two issues are related. Please answer my above edits too.

@voland66

This comment has been minimized.

voland66 commented Jan 26, 2016

  1. I will try to find links again. They were only possibly related: they referred to other yoga's and/or thinkpads; problems described were similar but I'm not sure they were exactly the same. The closest was a statement to me from lenovo techician (still indirect, it was the guy who came to fix the laptop but he got information from someone at lenovo proper) that it is possible lenovo software was set to prevent battery charging (that, of course, would be windows software).
  2. Yoga 12 is currently the only machine with tlp that I have, so I would not know if any other hardware is affected. (Except the google searches I mentioned referred other yogas/thinkpads)
  3. I can't find the same symptoms. I always assumed that "battery is charging" (shown with upower) was not an issue. "Battery constantly showing X% remaining" might be somewhat related: mine would show X% and charging but the charging rate (as shown by upower) would be zero (or nearly zero). At the end the would even be extremely slowly discharging from, e.g., 28% while on AC power.
  4. I think the values that worked were 76-80 and they were shown correctly by tlp-stat -b. There were some other value pairs that worked but I do not remember them. My recollection is that when I tried different ones, tlp-stat -b would show 76-80 (possibly 96-100 and a few other pairs would sometimes show) but not the ones I tried to set. This has been a while ago -- once I realized that 76-80 mostly works, I settled on it (or 96-100 when I needed full charge). As a result I forgot details.
@linrunner

This comment has been minimized.

Owner

linrunner commented Jan 26, 2016

Does the new system board still show the erratic threshold behaviour?

@voland66

This comment has been minimized.

voland66 commented Jan 26, 2016

Yes. After installing new motherboard I tried acpi-call again and noticed at least one feature of the old behaviour: I needed to discharge the laptop at least somewhat before it would start charging again. I got worried and removed the acpi-call to be safe.

@voland66

This comment has been minimized.

voland66 commented Jan 26, 2016

Just to clarify: by discharge somewhat I mean that it would not start charging when charged to a stop threshold if I either issued "tlp fullcharge" command or restarted tlp with higher thresholds.

@linrunner

This comment has been minimized.

Owner

linrunner commented Jan 26, 2016

To further clarify:

You're aware that charging will never start when the charge level is equal or higher than the lower threshold?

May we summarize your symptoms as follows

  • tlp-stat -b always shows the thresholds correctly as configured and written by tlp start or tlp setchargeor tlp fullcharge
  • actual charging does not obey the thresholds as designed, i.e. start below lower / stop at upper threshold, even with 96/100, but works with approx. 76/80
  • a charging rate of 0 is shown as status "charging" by tlp-stat -b

?

If you're not shure about tlp-stat -b output vs. configured thresholds please retest.

@voland66

This comment has been minimized.

voland66 commented Jan 26, 2016

Let me first clarify. Let's say the thresholds are 76-80 and battery is at 80%. I then issue tlp fullcharge command or reset the thresholds to 96-100 and run tlp start. Should the laptop start charging? I was assuming that charging in this situation would be a design behavior but it's not what was happening. If the start threshold were 76% (or any other number that worked), changing thresholds would have no effect until laptop discharges below 76% once.

I have reinstalled acpi_call and will test to give you better answers.

From my recollection the answer to the first question was yes, but as you will see from the output of tlp-stat -b below, right now thresholds are not reported correctly. (Probably my recollection was wrong.)

The answer to the second question is complicated. Generally, thresholds would be obeyed. But if I were to change thresholds, I would need to go below old charge threshold once before new threshold behavior takes over.

And then there was intermittent behavior when the laptop was below (far below) start threshold but would not start charging. It would say "charging" but the rate would be zero (sometimes it would be .001, sometimes it would be similarly small negative number). I understood this in situations when it was at/near stop threshold, but as I said, it also happened far below start threshold. And again, here I do not know whether it was an issue with tlp, firmware or faulty motherboard. But I hope this answers your third question.

Below is the output of tlp-stat -b shortly after installing acpi_call.
For the moment I noticed one thing which I did not remember correctly: when 76-80 threshold is set, tlp-stat -b shows both start and stop thresholds at 76% (see below). When the thresholds are set to 96-100 tlp-stat -b reports them correctly.

--- TLP 0.8 --------------------------------------------

+++ ThinkPad Extended Battery Functions
tp-smapi = inactive (kernel module 'tp_smapi' not installed)
tpacpi-bat = active

+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer = SONY
/sys/class/power_supply/BAT0/model_name = 45N1705
/sys/class/power_supply/BAT0/cycle_count = (not supported)
/sys/class/power_supply/BAT0/energy_full_design = 47060 [mWh]
/sys/class/power_supply/BAT0/energy_full = 47060 [mWh]
/sys/class/power_supply/BAT0/energy_now = 45870 [mWh]
/sys/class/power_supply/BAT0/power_now = 0 [mW]
/sys/class/power_supply/BAT0/status = Unknown (threshold effective)

tpacpi-bat.BAT0.startThreshold = 76 [%]
tpacpi-bat.BAT0.stopThreshold = 76 [%]
tpacpi-bat.BAT0.forceDischarge = 0

@voland66

This comment has been minimized.

voland66 commented Jan 26, 2016

One more question -- how do I reset things to factory default if I decide to uninstall acpi_call again?

@linrunner

This comment has been minimized.

Owner

linrunner commented Jan 28, 2016

I would need to go below old charge threshold once before new threshold behavior takes over.

I don't believe in that, it's just the new lower threshold.

As you already admitted, your memory is betraying you. Could we agree that from now on you only write about new test results on your current hardware?

Things that may have happened in the past on a defective systemboard are irrelevant. Only current evidence and results you can reproduce are acceptable for a bug report. And please be brief. OK?

I suggest you set some new thresholds like [1]

tlp setcharge 50 70

then [2] discharge on battery to 45% and check if charging starts when AC is connected and stops at 70%. Next [3]

tlp fullcharge

and check if charging starts immediately.

One more question -- how do I reset things to factory default if I decide to uninstall acpi_call again?

It's in the FAQ :-) You don't need to uninstall anything. Just comment out the config threshold values and issue

tlp fullcharge
@voland66

This comment has been minimized.

voland66 commented Jan 29, 2016

So here is what happens.

  1. "tlp set charge 76 80", followed by the removal of AC power:
    a) "tlp-stat -b" shows both thresholds as 76%
    b) laptop discharges as it should
  2. Plug in AC (once it is below start threshold):
    Laptop charges up to about 79% and stops there as it should. upower command shows that the laptop is charging with energy rate of a faction of 1W but the total energy does not change with time anymore.
  3. "tlp fullcharge":
    At this time the command has no effect. Two hours after the command is issued the laptop still sits at 79% showing energy rate of about 0.01W (it may actually be consumption rather than charging rate as the total energy seems to have gone down slightly).
  4. Unplug laptop briefly, let it discharge to, say, 78%, run "tlp setcharge 96 100", plug it back in:
    upower command shows laptop charging. However, the number reported for energy rate is the same as the last reported energy rate during the discharge interval. The total energy is not changing. I only monitored charging in this last step for a few minutes.
  5. Unplug laptop again, let it discharge to 75%. Plug it back in. The laptop is charges all the way to the new stop threshold of 100%.
@linrunner

This comment has been minimized.

Owner

linrunner commented Jan 29, 2016

Interesting. Seems to me that unplugging/plugging the AC actually activates newly written thresholds. You could as well try to unplug a few seconds only [1]. Powering off and on (not rebooting!) is another option [2].

I think you'll have to live with this quirky behaviour. I can't do anything about it in TLP.

Btw: tlp setcharge 96 100 and tlp fullcharge are equivalent.

EDIT: third option to activate the thresholds may be to issue tlp discharge and abort with Ctrl+C after a few seconds [3]. Test it.

@voland66

This comment has been minimized.

voland66 commented Jan 29, 2016

Thanks, I guess I will have to live with that. I just worried that this quirk and maybe other firmware bugs could have cause my not-charging at all problem.

Btw, this is even quirkier than you think. To clarify: tlp setcharge X Y, then discharge to Z (either running on battery or with tlp discharge, I tried both on the old motherboard), then tlp fullcharge and plug/unplug (tlp fullcharge and replugging can be ussied any number of times in any order; can reboot in between, poweroff-unplug-plug-boot, anything I could think of). The results:
a) if at any point there was Z<X, the laptop will charge to 100%.
b) if Z was always greater than X, the laptop will not charge fully.
So it looks like laptop notices new thresholds only after it goes below the old start threshold once. As I said, rebooting does not change this behavior.

I was wondering whether this somehow could be related to tlp-stat -b reporting the same start and stop thresholds unless those thresholds are defaults.

@linrunner

This comment has been minimized.

Owner

linrunner commented Feb 3, 2016

What happens in case you apply new thresholds that are higher than before i.e. Y' > X' > Y. Does charging start immediately?

@voland66

This comment has been minimized.

voland66 commented Feb 3, 2016

No, the charging does not start until I go below original X (at least) once. I am actually not sure if it is just once -- I am checking whether somehow 76% start threshold stuck. At least at the moment, my tlp-stat -b shows 96% and 100% thresholds and yet when I plug in the laptop upower shows no charging. So I 'm figuring out how low I need to go for charging to start.

@linrunner

This comment has been minimized.

Owner

linrunner commented Feb 3, 2016

And in the opposite change direction X'< Y'< X : you have to discharge Z < X'. Z < X is not sufficient, right?

I'll try to put a simple explanation in the FAQ. Not sure if anyone will grasp the meaning ...

@voland66

This comment has been minimized.

voland66 commented Feb 3, 2016

To be honest I'm slightly afraid to check the opposite direction. Right now I'm at 88% and if I plug the laptop in, upower shows laptop as charging but the number for charging rate is the last discharge number and the total energy is not increasing. I am worried that if lower threshold stick permanently, putting X'<X will permanently change my start threshold to something below 76%.
A possibly related battery quirk (but clearly not directly related to tlp): when the laptop wakes up from hibernation, upower often (always?) shows energy-full number 4-6 times higher than the battery capacity.

@linrunner

This comment has been minimized.

Owner

linrunner commented Feb 3, 2016

OK, then let's quit the subject here. To be frank: i'm fed up with analyzing other developers strange bugs right now.

@linrunner

This comment has been minimized.

Owner

linrunner commented Mar 15, 2016

Description added to FAQ.

@linrunner linrunner closed this Apr 12, 2016

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