From: Andrey Borzenkov <arvidjaar@mail.ru>
To: hal@lists.freedesktop.org
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: kpowersave stuck at battery charging
Date: Wed, 2 Jan 2008 12:48:49 +0300 [thread overview]
Message-ID: <200801021248.55844.arvidjaar@mail.ru> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3090 bytes --]
This is did not happen before; I am not sure right now what caused this (i.e.
battery aging or some software change) nor whether this is kernel/HAL/kpowersave
issue.
kpowersave is stuck at assuming battery is loading and at 94%. Sysfs displays
battery state as Full:
UEVENT[1199264702.345795]
change /devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1
(power_supply)
ACTION=change
DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1
SUBSYSTEM=power_supply
POWER_SUPPLY_NAME=BAT1
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Full
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=10800000
POWER_SUPPLY_VOLTAGE_NOW=11340000
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=38880000
POWER_SUPPLY_ENERGY_FULL=37530000
POWER_SUPPLY_ENERGY_NOW=35640000
POWER_SUPPLY_MODEL_NAME=XM2038P04
POWER_SUPPLY_MANUFACTURER=
SEQNUM=6472
HAL did not set (dis-)charging either:
{pts/0}% lshal -l -u /org/freedesktop/Hal/devices/computer_power_supply_0
udi = '/org/freedesktop/Hal/devices/computer_power_supply_0'
battery.charge_level.current = 35640 (0x8b38) (int)
battery.charge_level.last_full = 37530 (0x929a) (int)
battery.charge_level.percentage = 94 (0x5e) (int)
battery.charge_level.rate = 0 (0x0) (int)
battery.current = 0 (0x0) (int)
battery.present = true (bool)
battery.rechargeable.is_charging = false (bool)
battery.rechargeable.is_discharging = false (bool)
battery.reporting.current = 35640 (0x8b38) (int)
battery.reporting.design = 38880 (0x97e0) (int)
battery.reporting.last_full = 37530 (0x929a) (int)
battery.reporting.technology = 'Li-ion' (string)
battery.reporting.unit = 'mWh' (string)
battery.technology = 'lithium-ion' (string)
battery.type = 'primary' (string)
battery.vendor = '' (string)
battery.voltage.current = 11340 (0x2c4c) (int)
info.capabilities = {'battery'} (string list)
info.category = 'battery' (string)
info.parent = '/org/freedesktop/Hal/devices/computer' (string)
info.product = 'Li-ion' (string)
info.udi = '/org/freedesktop/Hal/devices/computer_power_supply_0' (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'power_supply' (string)
linux.sysfs_path
= '/sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1' (string)
Kernel 2.6.24-rc6, HAL 0.5.10, kpowersave 0.7.3.
I suspect this is kpowersave which ignores is_(dis)charging attribute and just
compares energy_full with energy_now. According to ACPI spec, energy_full
gives "predicted full charge capacity" - actually it is called Last Full Charge
Capacity. At least this is what ACPI battery code implements. As such this is
purely informational and cannot be relied upon for deciding when charging is
complete. Actually HAL /proc/acpi/battery code did not even use this property.
So
- does ACPI battery code misuse POWER_SUPPLY_PROP_ENERGY_FULL?
- does HAL misuse .../energy_full?
- does kpowersave misuse battery.charge_level.last_full?
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next reply other threads:[~2008-01-02 9:48 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-02 9:48 Andrey Borzenkov [this message]
2008-01-02 10:42 ` kpowersave stuck at battery charging Alexey Starikovskiy
2008-01-02 13:10 ` Andrey Borzenkov
2008-01-02 16:18 ` Alexey Starikovskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801021248.55844.arvidjaar@mail.ru \
--to=arvidjaar@mail.ru \
--cc=hal@lists.freedesktop.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox