Bug 704110

Does the new battery show up in /sys/class/power_supply on resume? If so, that's squarely a kernel bug IMO.

From a cold boot, I have only AC and BAT0 - but my AC has not been plugged in yet since booting up.

Suspend/Resume gives me an additional BAT1 entry. However using cat, the "present" file contains 0 and trying to read other entries returns a "No such device" message. Regardless of whether the kernel should be showing this device, I would imagine that if present is 0, then gpm should ignore it?


The other issue I had was that my machine went into hibernation based on the phantom battery (of 0%) and ignored the real battery level. Gpm was showing both batteries (the real on at 37%). 
Note, this last suspend/resume did not trigger hibernation even though both batteries are being reported - although my real battery is currently at around 91%.

Today my machine hibernated again. Just before it shut down I managed to confirm that /sys/class/power_supply/BAT1/present returned 0.

This time my real battery was fully charged up.

There doesn't appear to be much pattern - sometimes I resume the machine from suspend to ram and it will show the phantom battery, but not hibernate. Other times like today it will see that battery and hibernate - however this happens much less frequently.

Confirmed on my Dell D410. It has always had a phantom BAT0 and a real BAT1. But power-manager used to ignore it. In FC15 it shows it, which is annoying and it hibernates sometimes if I am not plugged in.

It would be nice if this could be given some priority. It happens fairly often to me and I have twice lost work (return from hibernation fails about 1 time in 20 for me). 

Gnome power manager just needs to add together the power of all available batteries and base its decision to hibernate on that. It should be an easy fix.

I can confirm this bug on HP 6550b and 8560p notebooks; again, the error is only after STR.

The issue this causes me is that on resume a second time, I'm notified that the battery is in a critical state as the second battery shows 0%. The first battery could be at 100%, but the system still goes into hibernation.

cat /proc/acpi/battery/BAT1/state shows the following:
present:                 no

Can't GPM just check this and not use the battery to make decisions if it's not present?

(In reply to comment #6)
> cat /proc/acpi/battery/BAT1/state shows the following:
> present:                 no
> Can't GPM just check this and not use the battery to make decisions if it's not
> present?

/proc isn't used by anything, it's deprecated and is going to be removed any day now. Look in /sys/class/power_supply for the same data.

Anyway, if /sys/class/power_supply/BATwhatever lists the battery as missing, does "upower -d" also detect the battery is missing?

(In reply to comment #7)
>
> Anyway, if /sys/class/power_supply/BATwhatever lists the battery as missing,
> does "upower -d" also detect the battery is missing?

I have the exactly same problem on my Dell Latitude E6400, and when BAT1 is missing in /sys/class/power_supply/BAT1/present, upower -d gives this output for BAT1:

Device: /org/freedesktop/UPower/devices/battery_BAT1
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:01/power_supply/BAT1
  power supply:         no
  updated:              Tue Jul 12 14:13:38 2011 (14 seconds ago)
  has history:          no
  has statistics:       no
  battery
    present:             no
    rechargeable:        no
    state:               unknown
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    percentage:          0%

Actually, this seems to be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=694482.

This also applies to the HP Compaq tc4400.

I had problems collecting the data, because it would hibernate too quickly on me. For now, I'm working around the hibernation via gsettings (since gnome-control-center power doesn't let me choose something other than hibernate/shutdown):

$ gsettings set org.gnome.settings-daemon.plugins.power critical-battery-action 'interactive'



Now, though, here's my system's info:
$ ls /sys/class/power_supply/
C1B2
C1B3
C1B4

C1B2:
type: Mains
online: 0

C1B3:
type: Battery
present: 0
manufacturer (ls sees the file): "cat: /sys/class/power_supply/C1B3/manufacturer: No such device"
status (ls sees it): "cat: /sys/class/power_supply/C1B3/status: No such device"
model_name: "cat: /sys/class/power_supply/C1B3/model_name: No such device"

C1B4:
type: Battery
present: 1
manufacturer: Hewlett-Packard
status: Discharging
model_name: Primary

Here is the output from "upower -d"
----------------------

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_C1B2
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/C1B2
  power supply:         yes
  updated:              Fri Jul 22 13:29:07 2011 (3002 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             no

Device: /org/freedesktop/UPower/devices/battery_C1B3
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:01/power_supply/C1B3
  power supply:         no
  updated:              Fri Jul 22 14:18:59 2011 (10 seconds ago)
  has history:          no
  has statistics:       no
  battery
    present:             no
    rechargeable:        no
    state:               unknown
    energy:              0 Wh
    energy-empty:        0 Wh
    energy-full:         0 Wh
    energy-full-design:  0 Wh
    energy-rate:         0 W
    percentage:          0%

Device: /org/freedesktop/UPower/devices/battery_C1B4
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/C1B4
  vendor:               Hewlett-Packard
  model:                Primary
  serial:               23574 2007/06/23
  power supply:         yes
  updated:              Fri Jul 22 14:19:09 2011 (0 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    energy:              21.384 Wh
    energy-empty:        0 Wh
    energy-full:         39.6144 Wh
    energy-full-design:  39.6144 Wh
    energy-rate:         19.71 W
    voltage:             11.341 V
    time to empty:       1.1 hours
    percentage:          53.9804%
    capacity:            100%
    technology:          lithium-ion
  History (charge):
    1311358719	53.980	discharging
    1311358679	54.471	discharging
    1311358664	54.716	discharging
    1311358646	54.962	discharging
  History (rate):
    1311358719	19.710	discharging
    1311358664	18.619	discharging
    1311358646	21.298	discharging

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

------------------

Life's not so bad now since I figured out how to set the critical action behaviour to interactive via gsettings, as noted at the top, though :)

(In reply to comment #7)

> /proc isn't used by anything, it's deprecated and is going to be removed any
> day now. Look in /sys/class/power_supply for the same data.

Yaiks. I hope this won't happen for some time to come. I noticed that if I execute:

   cat /proc/acpi/battery/BAT1/state

- then the missing phantom battery is no longer reported by GPM.

Just confirmed this by executing the following upon resume (hook in /etc/pm/sleep.d):

--- /etc/pm/sleep.d/10battery_state -----------------
#!/bin/bash
#
# /etc/pm/sleep.d/10battery_state

[ "$1" = 'resume' ] || exit 0

echo "=== Battery Hack Start ==="

echo "Batteries in /sys:" $(ls -C /sys/class/power_supply)
ls -l /sys/class/power_supply
echo "Reading battery state(s) through /sys"
for bat_dir in /sys/class/power_supply/*
do
    present=$(cat $bat_dir/present 2>&1)
    echo $(basename $bat_dir): $present
done
echo "Batteries in /sys:" $(ls -C /sys/class/power_supply)

echo "---"
echo "Reading battery state(s) through /proc"
for bat_dir in /proc/acpi/battery/BAT*
do
    bat=$(basename $bat_dir)
    echo "  $bat:"
    cat $bat_dir/state | sed -e 's/^/    /'
done

echo "---"
echo "Batteries in /sys:" $(ls -C /sys/class/power_supply)
echo "Reading battery state(s) through /sys"
for bat_dir in /sys/class/power_supply/*
do
    present=$(cat $bat_dir/present 2>&1)
    echo $(basename $bat_dir): $present
done
echo "Batteries in /sys:" $(ls -C /sys/class/power_supply)
echo "=== Battery Hack Done ==="
-----------------------------------------------------

After resume, I get the following in /var/log/pm-suspend.log:

--- /var/log/pm-suspend.log -------------------------
Running hook /etc/pm/sleep.d/10battery_state resume suspend:
=== Battery Hack Start ===
Batteries in /sys: AC BAT0 BAT1
total 0
lrwxrwxrwx 1 root root 0 Sep 20 17:47 AC -> ../../devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
lrwxrwxrwx 1 root root 0 Sep 20 17:59 BAT0 -> ../../devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
lrwxrwxrwx 1 root root 0 Sep 20 17:59 BAT1 -> ../../devices/LNXSYSTM:00/device:00/PNP0C0A:01/power_supply/BAT1
Reading battery state(s) through /sys
AC: cat: /sys/class/power_supply/AC/present: No such file or directory
BAT0: 1
BAT1: 0
Batteries in /sys: AC BAT0 BAT1
---
Reading battery state(s) through /proc
  BAT0:
    present:                 yes
    capacity state:          ok
    charging state:          discharging
    present rate:            1817 mA
    remaining capacity:      1335 mAh
    present voltage:         11014 mV
  BAT1:
    present:                 no
---
Batteries in /sys: AC BAT0
Reading battery state(s) through /sys
AC: cat: /sys/class/power_supply/AC/present: No such file or directory
BAT0: 1
Batteries in /sys: AC BAT0
=== Battery Hack Done ===
-----------------------------------------------------

Interestingly, upon resume, /sys/class/power shows BAT1. It's "present" file shows "0". After reading /proc/acpi/battery/BAT1 the "BAT1" entry in /sys/class/power_supply is completely gone.

For now, this helps to set GPM straight on which batteries are in the system. I no longer see any ghost batteries on resuming.

Incidentally, I also have a Latitude E6500.

(In reply to comment #12)
> Interestingly, upon resume, /sys/class/power shows BAT1. It's "present" file
> shows "0". After reading /proc/acpi/battery/BAT1 the "BAT1" entry in
> /sys/class/power_supply is completely gone.

This sounds very much like a kernel bug; Does this still happen in F16? Thanks.

Haven't seen it so far.