upower gives incorrect data/misleading data

Bug #594852 reported by am
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
upower (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: upower

I am using lucid. I have a dell inspiron 6000

upower gives data that is inconsistent with acpi.

 > acpi
Battery 0: Charging, 27%, 01:25:50 until charged

this agrees with the bios, so I believe it to be correct.

> upower --dump
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0003:00/power_supply/AC
  power supply: yes
  updated: Tue Jun 15 22:34:20 2010 (754 seconds ago)
  has history: no
  has statistics: no
  line-power
    online: yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:00/power_supply/BAT0
  vendor: Sanyo
  model: DELL F51267
  serial: 1410
  power supply: yes
  updated: Tue Jun 15 22:46:25 2010 (29 seconds ago)
  has history: yes
  has statistics: yes
  battery
    present: yes
    rechargeable: yes
    state: charging
    energy: 14.8962 Wh
    energy-empty: 0 Wh
    energy-full: 79.92 Wh
    energy-full-design: 79.92 Wh
    energy-rate: 26.3514 W
    voltage: 11.64 V
    time to full: 2.5 hours
    percentage: 18.6389%
    capacity: 67.375%
    technology: lithium-ion
  History (charge):
    1276638385 18.639 charging
    1276638355 18.347 charging
    1276638325 18.042 charging
  History (rate):
    1276638385 26.351 charging
    1276638355 29.393 charging
    1276638325 27.728 charging

Daemon:
  daemon-version: 0.9.1
  can-suspend: yes
  can-hibernate yes
  on-battery: no
  on-low-battery: no
  lid-is-closed: no
  lid-is-present: yes

the incorrect stat is percentage. Note that it is 18%, i.e. different from what acpi reports. this battery is an older battery and only holds about 65% of the design capacity when full. So, energy-full seems to be wrong as well. I don't know what capacity is, but as I said the last full capacity is about 2/3 of the design capacity, so it could be that. In fact, 18%/67%= 27% agrees with acpi, so that is probably what capacity means.

Anyways, this is causing my gnome-power-manager to report the wrong charge as well.

Revision history for this message
David Mack (barid42) wrote :

Something similar is happening to my computer. Not only is the charge information inconsistent, the reporting technology of the battery also changes inexplicably from Li-ion to Nimh. I believe, in my case, these issues may be related. I have been looking into writing a udev rule to force the correct battery type, but I don't know if this will correct the charge information.

System: HP Pavilion dv5-1125nr
OS: Ubuntu Lucid Lynx 10.04, all updates applied (6-16-10)

Dave

Revision history for this message
am (juniper1982) wrote :

I didn't notice if mine gives inconsistent reporting of technology, but I can check. Yes, my impression is that upower is a bit buggy.

Revision history for this message
David Mack (barid42) wrote :

I've been digging further. It appears my issue may not be with upower.

First, my acpi data is consistent with upower --dump. Percentages match, etc.

Second, I have found notes from other users (even those using winblows) about battery information being incorrect with my BIOS.

Therefore, I believe my problem is with HP, not with upower. I recently updated to the latest (allegedly greatest) BIOS firmware version F.38, and my problems got worse. I assume that is the issue.

Sorry to put the blame where it didn't belong.

Also on a side note, I was able to create a udev rule to force the battery type to Li-ion, and that did not solve the problem, so it appears the BIOS is the root cause.

Next time, I'm buying a computer with Ubuntu out of the box. I've had it with shoehorning a decent OS into a crappy box.

Thanks for everything,

Dave

Revision history for this message
Dmitry Gulevich (mitrg) wrote :

I am on Alienware M15X, Ubuntu 10.10. UPower does not register that the lid closed after first suspend/resume, while acpi does:

> yes "upower --dump | grep lid-is-closed; cat /proc/acpi/button/lid/*/state; sleep 2" | sh

  lid-is-closed: yes
state: closed
  lid-is-closed: yes
state: closed

After suspend/resume:

  lid-is-closed: no
state: closed
  lid-is-closed: no
state: closed

acpi correctly says "state: closed", while upower says "lid-is-closed: no".

Tried to dig for 4 hours, but could not solve this bug...

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in upower (Ubuntu):
status: New → Confirmed
Revision history for this message
monochromec (monochromec) wrote :

Same thing 12.10.

acpi shows 43% full, but according to upower the battery should be almost empty as "upower --dump" reports a percentage of 3.8%.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.