Incorrect 0% remaining battery detected forcing suspend

[Dave Chiluk]

Ubuntu is detecting that my battery has depleted to low or 0% which results in the OS forcing suspend. Normally this would be correct behavior, but in my case the battery has closer to 90% of remaining battery left.

I have experienced this with 4.4.0-22 and 4.4.0-23, and am currently running 4.4.0-21 to see if it reproduces there as well.

I do have -proposed enabled so it's a bit hard to determine if this is the kernel or something higher up the stack.

This does seem to be mildly reproducible. 4.4.0-23 being the most problematic kernel so far.

Of course this is a relatively new laptop so this could be a hardware issue as well.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: linux-image-4.4.0-21-generic 4.4.0-21.37
ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6
Uname: Linux 4.4.0-21-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: chiluk 2462 F.... pulseaudio
CurrentDesktop: Unity
Date: Fri Jun 3 14:07:17 2016
HibernationDevice: RESUME=UUID=4f4ea88e-642e-4be5-bdf0-bbc7f47f5628
InstallationDate: Installed on 2016-04-25 (38 days ago)
InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Release amd64 (20160420.1)
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 003: ID 04f2:b531 Chicony Electronics Co., Ltd
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 20FBCTO1WW
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-21-generic root=UUID=249f91bb-7789-41cc-9cc0-8ba25d7f55bb ro quiet splash pcie_aspm=force vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-4.4.0-21-generic N/A
 linux-backports-modules-4.4.0-21-generic N/A
 linux-firmware 1.157
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/18/2016
dmi.bios.vendor: LENOVO
dmi.bios.version: N1FET40W (1.14 )
dmi.board.asset.tag: Not Available
dmi.board.name: 20FBCTO1WW
dmi.board.vendor: LENOVO
dmi.board.version: SDK0J40709 WIN
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: None
dmi.modalias: dmi:bvnLENOVO:bvrN1FET40W(1.14):bd04/18/2016:svnLENOVO:pn20FBCTO1WW:pvrThinkPadX1Carbon4th:rvnLENOVO:rn20FBCTO1WW:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrNone:
dmi.product.name: 20FBCTO1WW
dmi.product.version: ThinkPad X1 Carbon 4th
dmi.sys.vendor: LENOVO

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.7-rc1 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.7-rc1-yakkety/

[Dave Chiluk (chiluk)]

Sorry Joe, this may be related to userspace as well, as I was able to reproduce this with other kernels as well. Although not as reliably.

[Dave Chiluk (chiluk)]

So as I haven't really messed with power monitoring, I discovered upower --monitor-detail.

After having been unplugged for a few minutes the below state change occurred. I'm open to advice on how to continue looking into this. My first guess is to open the upower sources to see where it's getting this information. I'm guessing it will be dbus. How dbus is monitoring it though is anyone's guess.

chiluk@x1:~$ sudo upower --monitor-detail
[sudo] password for chiluk:
Monitoring activity from the power daemon. Press Ctrl+C to cancel.

[13:31:28.826] device changed: /org/freedesktop/UPower/devices/battery_BAT0
  native-path: BAT0
  power supply: yes
  updated: Tue 07 Jun 2016 01:31:28 PM CDT (0 seconds ago)
  has history: yes
  has statistics: yes
  battery
    present: yes
    rechargeable: yes
    state: empty
    warning-level: none
    energy: 0 Wh
    energy-empty: 0 Wh
    energy-full: 0 Wh
    energy-full-design: 0 Wh
    energy-rate: 0 W
    percentage: 0%
    capacity: 100%
    icon-name: 'battery-empty-symbolic'

[Dave Chiluk (chiluk)]

Here's a log of me pulling power, and plugging it back in.

[Dave Chiluk (chiluk)]

Just to circle back around. Due to the above upower output I really started to suspect hardware. I ended up checking the release iso, and subsequently a certain Microsoft OS. Both also saw the same issues. Lenovo is over-nighting me a new battery. Apparently the electronics in the battery died fantastically. Shame on me for suspecting our beloved OS.

[Dave Chiluk (chiluk)]

In case anyone else hits this on their laptop and would like to disable the auto-suspend, I installed dconf-editor, and changed critical-battery-action to nothing.