Bug 974993
| Summary: | Power management with multiple batteries broken | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Amit Shah <amit.shah> |
| Component: | kde-workspace | Assignee: | Lukáš Tinkl <ltinkl> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | amit.shah, dvratil, jgrulich, jreznik, kevin, ltinkl, mbriza, ptg, rdieter, rnovacek, than |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-03-26 11:15:14 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Amit Shah
2013-06-17 10:32:43 UTC
$ rpm -q kde-workspace (In reply to Lukáš Tinkl from comment #1) > $ rpm -q kde-workspace 4.10.4-1.fc19.x86_64 Sorry for missing this! fwiw, I have multiple batteries without problems as described here.
What does 'upower --dump' say?
Me, at the moment, for example:
$ 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: Mon Jun 17 08:56:22 2013 (552 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: SMP
model: DELL PD6858
serial: 297
power supply: yes
updated: Mon Jun 17 09:05:33 2013 (1 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
energy: 86.58 Wh
energy-empty: 0 Wh
energy-full: 86.58 Wh
energy-full-design: 86.58 Wh
energy-rate: 0.0111 W
voltage: 12.573 V
percentage: 100%
capacity: 96.2436%
technology: lithium-ion
Device: /org/freedesktop/UPower/devices/battery_BAT1
native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:01/power_supply/BAT1
vendor: Sony
model: DELL 0M7870
serial: 10633
power supply: yes
updated: Mon Jun 17 09:05:33 2013 (1 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
energy: 22.5552 Wh
energy-empty: 0 Wh
energy-full: 22.6884 Wh
energy-full-design: 46.62 Wh
energy-rate: 0.0111 W
voltage: 12.377 V
percentage: 99.4129%
capacity: 48.6667%
technology: lithium-polymer
History (charge):
1371477928 99.413 fully-charged
1371477928 0.000 unknown
History (rate):
1371477928 0.011 fully-charged
1371477928 0.000 unknown
Daemon:
daemon-version: 0.9.20
can-suspend: yes
can-hibernate: yes
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
upower output while on AC power, and batteries fully charged is below.
Can't show when battery is discharged; it keeps 'hibernating', but doesn't resume fine -- effectively a reboot. That's a separate bug, though.
$ upower --dump
Device: /org/freedesktop/UPower/devices/line_power_AC
native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/ACPI0003:00/power_supply/AC
power supply: yes
updated: Wed Jun 19 13:34:28 2013 (370 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/PNP0A08:00/device:08/PNP0C09:00/PNP0C0A:00/power_supply/BAT0
vendor: Panasonic
model: 42T4847
serial: 1311
power supply: yes
updated: Wed Jun 19 13:34:34 2013 (364 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
energy: 39.4494 Wh
energy-empty: 0 Wh
energy-full: 39.4494 Wh
energy-full-design: 43.29 Wh
energy-rate: 0 W
voltage: 12.392 V
percentage: 100%
capacity: 91.1282%
technology: lithium-ion
Device: /org/freedesktop/UPower/devices/battery_BAT1
native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/PNP0C0A:01/power_supply/BAT1
vendor: SONY
model: 51J0508
serial: 1122
power supply: yes
updated: Wed Jun 19 13:40:34 2013 (4 seconds ago)
has history: yes
has statistics: yes
battery
present: yes
rechargeable: yes
state: fully-charged
energy: 20.1096 Wh
energy-empty: 0 Wh
energy-full: 20.304 Wh
energy-full-design: 31.32 Wh
energy-rate: 0 W
voltage: 12.46 V
percentage: 99.0426%
capacity: 64.8276%
technology: lithium-polymer
Daemon:
daemon-version: 0.9.20
can-suspend: no
can-hibernate: no
on-battery: no
on-low-battery: no
lid-is-closed: no
lid-is-present: yes
is-docked: no
can-suspend: no can-hibernate: no This is weird and should never happen... Could you try the above with an updated kernel _and_ on battery? (In reply to Lukáš Tinkl from comment #5) > can-suspend: no > can-hibernate: no > > This is weird and should never happen... Could you try the above with an > updated kernel _and_ on battery? Curiously, this comes up when I issue 'upower --dump' via an ssh connection. When I do this on the laptop itself, I see those two properties set to 'yes'. This is with upower --dump on the laptop, on battery: Device: /org/freedesktop/UPower/devices/line_power_AC native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/ACPI0003:00/power_supply/AC power supply: yes updated: Fri Jun 21 11:20:22 2013 (96 seconds ago) has history: no has statistics: no line-power online: no Device: /org/freedesktop/UPower/devices/battery_BAT0 native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/PNP0C0A:00/power_supply/BAT0 vendor: Panasonic model: 42T4847 serial: 1311 power supply: yes updated: Fri Jun 21 11:21:57 2013 (1 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 39.4272 Wh energy-empty: 0 Wh energy-full: 39.4383 Wh energy-full-design: 43.29 Wh energy-rate: 0 W voltage: 12.328 V percentage: 99.9719% capacity: 91.1026% technology: lithium-ion History (charge): 1371793823 99.972 discharging 1371793822 0.000 unknown History (rate): 1371793822 0.000 unknown Device: /org/freedesktop/UPower/devices/battery_BAT1 native-path: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:08/PNP0C09:00/PNP0C0A:01/power_supply/BAT1 vendor: SONY model: 51J0508 serial: 1122 power supply: yes updated: Fri Jun 21 11:21:57 2013 (1 seconds ago) has history: yes has statistics: yes battery present: yes rechargeable: yes state: discharging energy: 19.224 Wh energy-empty: 0 Wh energy-full: 20.304 Wh energy-full-design: 31.32 Wh energy-rate: 9.2124 W voltage: 11.988 V time to empty: 2.1 hours percentage: 94.6809% capacity: 64.8276% technology: lithium-polymer History (charge): 1371793917 94.681 discharging 1371793887 95.106 discharging 1371793857 95.532 discharging 1371793826 96.436 discharging 1371793824 96.543 discharging 1371793823 96.755 discharging 1371793822 0.000 unknown History (rate): 1371793917 9.212 discharging 1371793887 9.569 discharging 1371793857 16.027 discharging 1371793826 17.950 discharging 1371793824 17.539 discharging 1371793823 16.513 discharging 1371793822 0.000 unknown Daemon: daemon-version: 0.9.20 can-suspend: yes can-hibernate: yes on-battery: yes on-low-battery: no lid-is-closed: no lid-is-present: yes is-docked: no Oh, then it makes sense, only local users get the polkit privilege to suspend/hibernate AFAIK. Still no idea about why you're hitting the original problem, I can't (and rdieter neither) reproduce it :/ I'm now running this: $ rpm -q kde-workspace kde-workspace-4.10.5-2.fc19.x86_64 and I'm not seeing this anymore. It's not the same install, however. Earlier, I had installed only the KDE desktop. I had to wipe the h/d and re-install, and the 2nd time I installed with the defaults (gnome), and installed the KDE Plasma Workspaces group later. Don't know if that changed anything, though. I don't really want to wipe the h/d again. Hm, still happens w/o any updates. 1. Keep running the system till one battery drains completely, and other is less than 100% 2. Shutdown, restart and login into KDE 3. KDE keeps suspending laptop I believe this is a duplicate of BZ #822304. I realize BS #822304 is for Fedora 17 and this one is for Fedora 19, however I have experienced the same problem in Fedora 17, 19, and 20 (I did not use Fedora 18, so I cannot speak to that, but my assumption would be that it existed there too). There doesn't seem to be anyway to create a "virtual battery" to create a test case for this, but perhaps someone knows better than I. I was hoping to recreate this issue in a virtual machine so it would be easier to detect and resolve. The details of my setup are: GNOME Desktop HP ProBook 6455b laptop w/ external extended life battery (hooks on to the bottom) This was the setup for Fedora 17, 19, and 20 alike. acpi -V shows the following: Battery 0: Discharging, 81%, 01:11:09 remaining Battery 0: design capacity 4000 mAh, last full capacity 2511 mAh = 62% Battery 1: Unknown, 95% Battery 1: design capacity 5100 mAh, last full capacity 1283 mAh = 25% Note that battery 0 is the external battery, which you would want to drain first. However, if the external battery is removed, the internal battery becomes "battery 0": Battery 0: Discharging, 94%, 00:35:15 remaining Battery 0: design capacity 5100 mAh, last full capacity 1283 mAh = 25% A problem like this puts more wear on a battery than normal as the usual fix is to just plug in the AC adapter which isn't good over time for a battery. Note that no prior warning is given. Once it drops below 5% it tells you that it will power off very soon and just does it. Sometimes you can switch to a console, plug in the power, wait a few minutes, and then switch back and avoid the shutdown. The only "workarounds" that I am aware of are to remove the external battery or plug in the power prior to reaching below 5%. There have been rare cases where I have seen it hit 0% and it not immediately be a problem, but again that is not the norm. *** This bug has been marked as a duplicate of bug 822304 *** |