linux-kernel - Re: kpowersave stuck at battery charging

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200801021610.45582.arvidjaar@mail.ru>
Date:	Wed, 2 Jan 2008 16:10:40 +0300
From:	Andrey Borzenkov <arvidjaar@...l.ru>
To:	hal@...ts.freedesktop.org
Cc:	Alexey Starikovskiy <aystarik@...il.com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: 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=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=

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?
> >   
> 
> 

Download attachment "signature.asc " of type "application/pgp-signature" (190 bytes)