Description of problem: Resuming my machine from suspend, gpm detected a second battery at 0%. As this was "critically low" gpm triggered hibernation. My machine has only one battery and this was reported at 37%. After resuming from hibernate, the phantom battery is no longer reported Version-Release number of selected component (if applicable): gnome-power-manager-3.0.0-2.fc15.x86_64 kernel-2.6.38.5-24.fc15.x86_64 I have a Dell E6500 and running current F15 state installed using pre-upgrade How reproducible: First time hibernation has happened, but the phantom battery has been periodically reported. Steps to Reproduce: 1. Suspend to ram 2. Resume Actual results: Phantom battery is reported as 0% and hibernate kicks in Expected results: No phantom battery. No automatic hibernate for phantom battery level Additional info:
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.