Re: kpowersave stuck at battery charging
Andrey Borzenkov wrote: On Wednesday 02 January 2008, Alexey Starikovskiy wrote: Andrey Borzenkov wrote: 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: Frequent battery charging shortens lifetime of the battery, so some (may be all now) notebook manufacturers do not start charging battery until it discharge to some degree (~90%). I thought Li-Ion batteries do not have memory effect. Actually I remember to have read recommendation to avoid deep discharges of Li-Ion battery, it was adviced to charge it as often as possible. IBM has advice to not re-charge battery until it discharged to 95%. It was implemented in their batteries/notebooks. There is no memory effect in Li-Ion batteries, there is only limited number of charge cycles -- about 1000 times, thus "as often as possible" is advice of the battery seller :) It could be your case. Please try to discharge battery to, say, 89% and then check if it charges to the 100%. That is exactly the question - how do you compute 100%? As far as I can tell the only possibility is - when battery stops charging. At this point you have to assume battery is fully charged. Last charge would be good reference. Think of the battery as constantly degrading resource. I tried to discharge battery (it was around 78%) and plug AC in again. It went on Charging until the same limit after that state changed to Full (well, in case of ACPI battery we really only can state - not (dis-)charging, there is no special Full state flag); kpowersave still believes battery is not fully charged. Main interface shows 84% (no Charging) - tooltip states it is being charged. So, that is the state of your battery. If you buy new one, it will go high again. Regards, Alex. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kpowersave stuck at battery charging
On Wednesday 02 January 2008, Alexey Starikovskiy wrote: > Andrey Borzenkov wrote: > > 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: > > > > > Frequent battery charging shortens lifetime of the battery, so some (may > be all now) > notebook manufacturers do not start charging battery until it discharge > to some degree (~90%). I thought Li-Ion batteries do not have memory effect. Actually I remember to have read recommendation to avoid deep discharges of Li-Ion battery, it was adviced to charge it as often as possible. > It could be your case. Please try to discharge battery to, say, 89% and > then check if it charges to the > 100%. That is exactly the question - how do you compute 100%? As far as I can tell the only possibility is - when battery stops charging. At this point you have to assume battery is fully charged. I tried to discharge battery (it was around 78%) and plug AC in again. It went on Charging until the same limit after that state changed to Full (well, in case of ACPI battery we really only can state - not (dis-)charging, there is no special Full state flag); kpowersave still believes battery is not fully charged. Main interface shows 84% (no Charging) - tooltip states it is being charged. 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=1080 POWER_SUPPLY_VOLTAGE_NOW=1134 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_ENERGY_FULL_DESIGN=3888 POWER_SUPPLY_ENERGY_FULL=3753 POWER_SUPPLY_ENERGY_NOW=3564 POWER_SUPPLY_MODEL_NAME=XM2038P04 POWER_SUPPLY_MANUFACTURER= This would indicate that my battery lost 6% of capacity in new year, but question still remains - how should user tools properly calculate charge level? > > - does ACPI battery code misuse POWER_SUPPLY_PROP_ENERGY_FULL? > > - does HAL misuse .../energy_full? > > - does kpowersave misuse battery.charge_level.last_full? > > > > signature.asc Description: This is a digitally signed message part.
Re: kpowersave stuck at battery charging
Andrey Borzenkov wrote: 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: Frequent battery charging shortens lifetime of the battery, so some (may be all now) notebook manufacturers do not start charging battery until it discharge to some degree (~90%). It could be your case. Please try to discharge battery to, say, 89% and then check if it charges to the 100%. - does ACPI battery code misuse POWER_SUPPLY_PROP_ENERGY_FULL? - does HAL misuse .../energy_full? - does kpowersave misuse battery.charge_level.last_full? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kpowersave stuck at battery charging
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=1080
POWER_SUPPLY_VOLTAGE_NOW=1134
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=3888
POWER_SUPPLY_ENERGY_FULL=3753
POWER_SUPPLY_ENERGY_NOW=3564
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?
signature.asc
Description: This is a digitally signed message part.
kpowersave stuck at battery charging
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=1080
POWER_SUPPLY_VOLTAGE_NOW=1134
POWER_SUPPLY_CURRENT_NOW=0
POWER_SUPPLY_ENERGY_FULL_DESIGN=3888
POWER_SUPPLY_ENERGY_FULL=3753
POWER_SUPPLY_ENERGY_NOW=3564
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?
signature.asc
Description: This is a digitally signed message part.
Re: kpowersave stuck at battery charging
Andrey Borzenkov wrote: 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: Frequent battery charging shortens lifetime of the battery, so some (may be all now) notebook manufacturers do not start charging battery until it discharge to some degree (~90%). It could be your case. Please try to discharge battery to, say, 89% and then check if it charges to the 100%. - does ACPI battery code misuse POWER_SUPPLY_PROP_ENERGY_FULL? - does HAL misuse .../energy_full? - does kpowersave misuse battery.charge_level.last_full? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kpowersave stuck at battery charging
On Wednesday 02 January 2008, Alexey Starikovskiy wrote: Andrey Borzenkov wrote: 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: Frequent battery charging shortens lifetime of the battery, so some (may be all now) notebook manufacturers do not start charging battery until it discharge to some degree (~90%). I thought Li-Ion batteries do not have memory effect. Actually I remember to have read recommendation to avoid deep discharges of Li-Ion battery, it was adviced to charge it as often as possible. It could be your case. Please try to discharge battery to, say, 89% and then check if it charges to the 100%. That is exactly the question - how do you compute 100%? As far as I can tell the only possibility is - when battery stops charging. At this point you have to assume battery is fully charged. I tried to discharge battery (it was around 78%) and plug AC in again. It went on Charging until the same limit after that state changed to Full (well, in case of ACPI battery we really only can state - not (dis-)charging, there is no special Full state flag); kpowersave still believes battery is not fully charged. Main interface shows 84% (no Charging) - tooltip states it is being charged. 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=1080 POWER_SUPPLY_VOLTAGE_NOW=1134 POWER_SUPPLY_CURRENT_NOW=0 POWER_SUPPLY_ENERGY_FULL_DESIGN=3888 POWER_SUPPLY_ENERGY_FULL=3753 POWER_SUPPLY_ENERGY_NOW=3564 POWER_SUPPLY_MODEL_NAME=XM2038P04 POWER_SUPPLY_MANUFACTURER= This would indicate that my battery lost 6% of capacity in new year, but question still remains - how should user tools properly calculate charge level? - does ACPI battery code misuse POWER_SUPPLY_PROP_ENERGY_FULL? - does HAL misuse .../energy_full? - does kpowersave misuse battery.charge_level.last_full? signature.asc Description: This is a digitally signed message part.
Re: kpowersave stuck at battery charging
Andrey Borzenkov wrote: On Wednesday 02 January 2008, Alexey Starikovskiy wrote: Andrey Borzenkov wrote: 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: Frequent battery charging shortens lifetime of the battery, so some (may be all now) notebook manufacturers do not start charging battery until it discharge to some degree (~90%). I thought Li-Ion batteries do not have memory effect. Actually I remember to have read recommendation to avoid deep discharges of Li-Ion battery, it was adviced to charge it as often as possible. IBM has advice to not re-charge battery until it discharged to 95%. It was implemented in their batteries/notebooks. There is no memory effect in Li-Ion batteries, there is only limited number of charge cycles -- about 1000 times, thus as often as possible is advice of the battery seller :) It could be your case. Please try to discharge battery to, say, 89% and then check if it charges to the 100%. That is exactly the question - how do you compute 100%? As far as I can tell the only possibility is - when battery stops charging. At this point you have to assume battery is fully charged. Last charge would be good reference. Think of the battery as constantly degrading resource. I tried to discharge battery (it was around 78%) and plug AC in again. It went on Charging until the same limit after that state changed to Full (well, in case of ACPI battery we really only can state - not (dis-)charging, there is no special Full state flag); kpowersave still believes battery is not fully charged. Main interface shows 84% (no Charging) - tooltip states it is being charged. So, that is the state of your battery. If you buy new one, it will go high again. Regards, Alex. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
