Bug 15979 - Eeepc 900 reports incorrect battery status
Eeepc 900 reports incorrect battery status
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Battery
All Linux
: P1 normal
Assigned To: Zhang Rui
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-15 19:30 UTC by Ferry Toth
Modified: 2010-11-02 02:55 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.32
Tree: Mainline
Regression: No


Attachments
acpidump (114.77 KB, text/plain)
2010-05-20 16:44 UTC, Ferry Toth
Details
dmesg (122.81 KB, text/plain)
2010-05-20 16:45 UTC, Ferry Toth
Details
patch: support percentage battery remaining capacity (2.23 KB, patch)
2010-06-29 06:27 UTC, Zhang Rui
Details | Diff
patch: support percentage battery remaining capacity (2.20 KB, patch)
2010-07-12 07:45 UTC, Zhang Rui
Details | Diff
acpidump of patched kernel (114.77 KB, text/plain)
2010-07-20 21:43 UTC, Ferry Toth
Details
dmesg of patched kernel (54.94 KB, text/plain)
2010-07-20 21:45 UTC, Ferry Toth
Details
debug patch (2.35 KB, patch)
2010-07-22 01:14 UTC, Zhang Rui
Details | Diff
Contents of /sys/class/power_supply/BAT0 (110.00 KB, application/x-tar)
2010-08-24 10:50 UTC, Sitsofe Wheeler
Details
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00 (1.59 KB, text/plain)
2010-10-09 09:11 UTC, Sitsofe Wheeler
Details
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00 with patch (1.59 KB, text/plain)
2010-10-09 09:16 UTC, Sitsofe Wheeler
Details
patch v2: support percentage battery remaining capacity (1.80 KB, patch)
2010-10-11 05:57 UTC, Zhang Rui
Details | Diff
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00 with patch v2 (1.59 KB, text/plain)
2010-10-11 22:33 UTC, Sitsofe Wheeler
Details
debug patch (2.74 KB, patch)
2010-10-12 01:35 UTC, Zhang Rui
Details | Diff
dmesg after applying debug patch (36.72 KB, text/plain)
2010-10-12 07:58 UTC, Sitsofe Wheeler
Details
patch v3: support percentage battery remaining capacity (2.99 KB, patch)
2010-10-12 08:19 UTC, Zhang Rui
Details | Diff
patch v3: support percentage battery remaining capacity (3.31 KB, patch)
2010-10-12 08:33 UTC, Zhang Rui
Details | Diff

Description Ferry Toth 2010-05-15 19:30:43 UTC
On eeepc 900 (and possibly other variants) the battery status is incorrectly reported, possibly do to a mixup of units.

With power plugged in and battery fully charged:
$ cat /proc/acpi/battery/BAT0/info 
present:                 yes
design capacity:         5200 mAh
last full capacity:      100 mAh
battery technology:      rechargeable
design voltage:          8400 mV
design capacity warning: 20 mAh
design capacity low:     10 mAh
capacity granularity 1:  52 mAh
capacity granularity 2:  52 mAh
model number:            900
serial number:            
battery type:            LION
OEM info:                ASUS

$ cat /proc/acpi/battery/BAT0/state 
present:                 yes
capacity state:          ok
charging state:          charged
present rate:            unknown
remaining capacity:      100 mAh
present voltage:         8326 mV


last full capacity remaining capacity are reported by asus in %
there may be a similar problem with granularity

As a result of the above ubuntu reports a broken battery on each login and remaining battery time is incorrectly estimated.

Additional info might be obtained from asus linux kernel sources?

Ferry
Comment 1 Zhang Rui 2010-05-19 06:51:31 UTC
please attach the acpidump output.
please attach the dmesg output after boot.
Comment 2 Ferry Toth 2010-05-20 16:44:15 UTC
Created attachment 26464 [details]
acpidump
Comment 3 Ferry Toth 2010-05-20 16:45:19 UTC
Created attachment 26465 [details]
dmesg
Comment 4 Zhang Rui 2010-05-21 02:40:04 UTC
this looks like a BIOS bug to me.

According to the ACPI spec, "Notice that when the battery is a primary battery (a non-rechargeable battery) and cannot provide accurate information about the battery to use the calculation of the remaining battery life, the Control Method Battery can report percentage to OS directly. It does so by reporting the Last Full Charged Capacity=100 and BatteryPresentRate=0xFFFFFFFF. This means that Battery Remaining Capacity directly reports the battery's remaining capacity as a value in the range 0 through 100"

It seems that this BIOS follow this guide although it's a rechargeable battery.

Alexey,
I tried to fix this in the ACPI battery driver, but find that you have some code to fix the battery.rate_now=0xFFFFFFFF issue, i.e the ACPI_BATTERY_QUIRK_SIGNED16_CURRENT quirks, is this true?
do you think we should follow the spec to handle this kind of BIOS?
Comment 5 Ferry Toth 2010-05-21 07:54:37 UTC
I may be useful to note that ASUS has sources for the eeepc linux version (kernel 2.6.21) available here:

http://dlsvr01.asus.com/pub/ASUS/EeePC/SourceCode/p900-1.1-src.tgz (1.8GB).

Ferry
Comment 6 Zhang Rui 2010-05-24 07:04:37 UTC
(In reply to comment #0)
> On eeepc 900 (and possibly other variants) the battery status is incorrectly
> reported, possibly do to a mixup of units.
> 
> last full capacity:      100 mAh

> remaining capacity:      100 mAh
 
> 
> last full capacity remaining capacity are reported by asus in %
> there may be a similar problem with granularity
> 
> As a result of the above ubuntu reports a broken battery on each login and
> remaining battery time is incorrectly estimated.
> 
I re-read the ACPI spec, it's true that we can not calculate the remaining battery life in this case.
But this doesn't sound like an ACPI bug.
In stead, ubuntu should be able to handling this and report something more user friendly.

what do you think?
Comment 7 Ferry Toth 2010-05-24 20:52:48 UTC
1)Me, I'm just an electronics engineer.

From that point of view the kernel reports 100 mAh, where it actually is 100% (of the capacity).

There is no way higher levels can or should doubt the reported value - including the unit.

So if the kernel spec allows the unit %, ubuntu should interpret that and calculate the correct capacity. But then the kernel should report 100% (when full)

If only mAh is allowed the correct value should be calculated by the kernel and reported in mAh. But then the kernel should report capacity * design capacity = 100% * 5200mAh = 100 / 100 * 5200 = 5200mAh.

2) I don't know why you can not calculate the remaining capacity. In my reported data the eeepc was connected to the charger and full. Therefore the discharge rate is unknown. The calculations are not different then with other batteries. Or?

3) Both windows xp and the the original asus supplied linux have no problem reporting the battery state.

Ferry
Comment 8 Zhang Rui 2010-05-28 03:20:10 UTC
(In reply to comment #7)
> 1)Me, I'm just an electronics engineer.
> 
> From that point of view the kernel reports 100 mAh, where it actually is 100%
> (of the capacity).
> 
Right.

> There is no way higher levels can or should doubt the reported value -
> including the unit.
> 
> So if the kernel spec allows the unit %, ubuntu should interpret that and
> calculate the correct capacity. But then the kernel should report 100% (when
> full)
> 
I agree.

> If only mAh is allowed the correct value should be calculated by the kernel and
> reported in mAh. But then the kernel should report capacity * design capacity =
> 100% * 5200mAh = 100 / 100 * 5200 = 5200mAh.
> 
No, in this case,

battery remaining capacity = last full charge capacity * remaining battery percentage / 100
as the last full charge capacity is not a absolute value, we can not get the batttery remaining capacity.

battery remaining life = battery remaining capacity / battery present rate (0xFFFFFFFF) = unknown

So we should be able to show the correct battery remaining percentage in this case, but we can not report a meaningful battery remaining life.

> 2) I don't know why you can not calculate the remaining capacity. In my
> reported data the eeepc was connected to the charger and full. Therefore the
> discharge rate is unknown. The calculations are not different then with other
> batteries. Or?
> 
Other batteries reports an absolute value for the last full charge capacity.
Say, if last full charge capacity = 5100


> 3) Both windows xp and the the original asus supplied linux have no problem
> reporting the battery state.
> 
do they provide the battery remaining life?
If yes, maybe they use some other tricks that we should be aware of.
Comment 9 Ferry Toth 2010-05-28 17:57:26 UTC
I will ask a friend running the original asus linux to do  cat /proc/acpi/battery/BAT0/info  and cat /proc/acpi/battery/BAT0/state 

Windows XP report "battery % remaing", nothing else.

Meanwhile: the problem under ubuntu is not "battery remaining life", but the fact that "last full capacity" == 100mAh triggers a message that the battery is broken and needs to be replaced.

It is quite a download, but if you want I can download the asus sources, if yu can tell me which file you need.

Ferry
Comment 10 Zhang Rui 2010-06-09 07:48:08 UTC
(In reply to comment #9)
> I will ask a friend running the original asus linux to do  cat
> /proc/acpi/battery/BAT0/info  and cat /proc/acpi/battery/BAT0/state 
> 
great.
And please ask him what does Asus Linux report about the battery status.
If I'm right, Asus Linux should report the battery % remaining only, just like windows, as it can not predict how much battery life left.

> Windows XP report "battery % remaing", nothing else.
> 
we can also report a correct battery % remaining in Linux, if we can workaroudn the "last full capacity" == 100mAh issue.

> Meanwhile: the problem under ubuntu is not "battery remaining life", but the
> fact that "last full capacity" == 100mAh triggers a message that the battery is
> broken and needs to be replaced.
> 
right, this is the problem that should be fixed by ubuntu, and maybe other distributions as well.

> It is quite a download, but if you want I can download the asus sources, if yu
> can tell me which file you need.
> 
No, you don't need to download the source.
It's probably workaround in user space.
Let's see what Asus Linux reports first.
Comment 11 Ferry Toth 2010-06-09 09:47:07 UTC
Except one thing: ubuntu does not need to fix anything here.

When the kernel reports "last full capacity" == 100mAh ubuntu is right to warn that the battery is broken.

The kernel should report either 100% or 5400mAh instead of mixing up the units.

Ferry
Comment 12 Zhang Rui 2010-06-10 01:20:15 UTC
(In reply to comment #11)
> Except one thing: ubuntu does not need to fix anything here.
> 
> When the kernel reports "last full capacity" == 100mAh ubuntu is right to warn
> that the battery is broken.
> 
Oh, in this case, I thought ubuntu should be able to translate the 100mAh to 100%.

> The kernel should report either 100% or 5400mAh instead of mixing up the units.
> 
well, this sounds reasonable to report 100% instead of 100mAh in the kernel.

I think Len may give some suggestions.
Comment 13 Zhang Rui 2010-06-29 06:27:35 UTC
Created attachment 26967 [details]
patch: support percentage battery remaining capacity

please apply this patch on top of the latest git kernel and see if it helps.

BTW: after applying this patch, user space should be able to calculate the battery remaining percentage correctly, but it still can not calculate the battery remaining life.
Comment 14 Zhang Rui 2010-06-30 06:09:59 UTC
please re-open it if the patch doesn't help.
Comment 15 Zhang Rui 2010-07-06 08:18:38 UTC
ferry, would you please test the patch please?
I'll try to push it upstream if it works for you.
Comment 16 Ferry Toth 2010-07-06 21:22:06 UTC
I would if I could. I am running ubuntu lucid on my eeepc, so either I need to build a complete kernel on my eeepc - which I have never done, or I need to build this driver only against lucids kernel. Which I also have never done.

If you tell me what to do I would give it a try.

Can we use ubuntu ppa to get a kernel built?

Ferry
Comment 17 Zhang Rui 2010-07-07 01:22:30 UTC
Testing this patch on a vanilla kernel would be helpful.
please:
1. click the [full source] button of "mainline: 2.6.35-rc4"
2. unpack the source package
3. enter the root dir of the source package
4. download the patch in comment #13, save as 1.patch
5. apply the patch attached by running "patch -p1 < 1.patch"
6. copy the /boot/config-... to kernel_src/.config file
7. run "make oldconfig"
8. follow the step 6, 7 at http://www.howtoforge.com/kernel_compilation_ubuntu_p2
Comment 18 Ferry Toth 2010-07-11 22:01:31 UTC
Following your instructions as close as possible and entering the defaults for all new kernel configuration settings I get:

make[1]: Map '/home/ferry/tmp/kernel/linux-2.6.35-rc4' wordt binnengegaan
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/generated/compile.h
  VDSOSYM arch/x86/vdso/vdso32-int80-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-sysenter-syms.lds
  VDSOSYM arch/x86/vdso/vdso32-syms.lds
  LD      arch/x86/vdso/built-in.o
  LD      arch/x86/built-in.o
  CC      drivers/acpi/battery.o
drivers/acpi/battery.c: In function ‘acpi_battery_quirks2’:
drivers/acpi/battery.c:582: error: ‘struct acpi_battery’ has no member named ‘design_full_capacity’
make[3]: *** [drivers/acpi/battery.o] Fout 1
make[2]: *** [drivers/acpi] Fout 2
make[1]: *** [drivers] Fout 2
make[1]: Map '/home/ferry/tmp/kernel/linux-2.6.35-rc4' wordt verlaten
make: *** [debian/stamp/build/kernel] Fout 2

FYI building on debian squeeze and intend to install the new kernel on eeepc 900 with Ubuntu Lucid.

How to proceed?

Ferry
Comment 19 Zhang Rui 2010-07-12 07:45:01 UTC
Created attachment 27069 [details]
patch: support percentage battery remaining capacity

please try this patch instead.
Comment 20 Ferry Toth 2010-07-12 20:31:02 UTC
It compiles, installs (with some errors like a non-existent link), and boots up to the ubuntu login screen.

Unfortunately on the eeepc it gives me no touchpad and no keyboard. Plugging in an external USB mouse at least I get a mouse. But I still have no keyboard, and with no external USB keyboard available I can not log in.

Booted a live CD to set the default kernel to the old one by editting /boot/grub/grub.cfg as I couldn't get to the grub menu at boot. At least now I could boot the old kernel.

Any ideas?

Ferry
Comment 21 Zhang Rui 2010-07-13 00:42:07 UTC
well, this seems like an unknown regression in 2.6.35-rc4.
please check if this patch can be applied to your old kernel or not.
Comment 22 Ferry Toth 2010-07-13 19:40:10 UTC
Maybe I built incorrectly. Chances are high, as this was my first kernel build.

The kernel provided at https://launchpad.net/~kernel-ppa/+archive/ppa/+packages (2.6.35-7-generic #11-lucid1-ubuntu) installs and seems to run well.

Is there just a module that I can copy over that contains battery.o or is battery.o built into the kernel?

Otherwise, should I take the ubuntu sources and patch that? I will probably error the same as the first time.

Ferry
Comment 23 Zhang Rui 2010-07-14 01:18:35 UTC
(In reply to comment #22)
> Maybe I built incorrectly. Chances are high, as this was my first kernel build.
> 
> The kernel provided at https://launchpad.net/~kernel-ppa/+archive/ppa/+packages
> (2.6.35-7-generic #11-lucid1-ubuntu) installs and seems to run well.
> 
please download the vanilla kernel 2.6.34.1 source code from www.kernel.org.
Apply the patch and build the kernel using the kernel config file of (2.6.35-7-generic #11-lucid1-ubuntu) that you have installed.
Comment 24 Ferry Toth 2010-07-20 21:40:56 UTC
I built from the ubuntu ppa taking the config from the pre-built ubuntu 2.6.35-7.11~lucid. The ubuntu version has the same behavior as 2.6.32. My custom built with your patches actually makes things worse, ubuntu wants to shutdown because the battery is 1.8%.

On AC power I get:

ferry@eeepc:~$ cat /proc/acpi/battery/BAT0/info 
present:                 yes
design capacity:         5200 mAh
last full capacity:      5200 mAh
battery technology:      rechargeable
design voltage:          8400 mV
design capacity warning: 20 mAh
design capacity low:     10 mAh
cycle count:		  0
capacity granularity 1:  52 mAh
capacity granularity 2:  52 mAh
model number:            900
serial number:            
battery type:            LION
OEM info:                ASUS

ferry@eeepc:~$  cat /proc/acpi/battery/BAT0/state 
present:                 yes
capacity state:          ok
charging state:          charging
present rate:            unknown
remaining capacity:      90 mAh
present voltage:         8408 mV

Present voltage indicates battery full.

Ferry
Comment 25 Ferry Toth 2010-07-20 21:43:59 UTC
Created attachment 27172 [details]
acpidump of patched kernel
Comment 26 Ferry Toth 2010-07-20 21:45:11 UTC
Created attachment 27173 [details]
dmesg of patched kernel
Comment 27 Ferry Toth 2010-07-21 21:44:48 UTC
I also had some build errors, don't know if related by may be bugs:

  CC      drivers/acpi/battery.o
drivers/acpi/battery.c: In function ‘acpi_battery_add’:
drivers/acpi/battery.c:947: warning: passing argument 1 of ‘async_schedule_domain’ from incompatible pointer type
include/linux/async.h:20: note: expected ‘void (*)(void *, async_cookie_t)’ but argument is of type ‘void (*)(struct acpi_device *, async_cookie_t)’
drivers/acpi/battery.c: In function ‘acpi_battery_init’:
drivers/acpi/battery.c:1008: warning: ‘return’ with no value, in function returning non-void

battery.c:
	if (!result) {
line #947:		async_schedule_domain(acpi_battery_update_async, device, &acpi_battery_domain);

	} else {

and

static int __init acpi_battery_init(void)
{
	if (acpi_disabled)
line #1008:		return;
#ifdef CONFIG_ACPI_PROCFS_POWER
	acpi_battery_dir = acpi_lock_battery_dir();
	if (!acpi_battery_dir)
		return -1;
#endif
	if (acpi_bus_register_driver(&acpi_battery_driver) < 0) {
#ifdef CONFIG_ACPI_PROCFS_POWER
		acpi_unlock_battery_dir(acpi_battery_dir);
#endif
		return -1;
	}
	return 0;
}

async.h:
line #20: extern async_cookie_t async_schedule_domain(async_func_ptr *ptr, void *data, struct list_head *list);
Comment 28 Zhang Rui 2010-07-22 01:14:52 UTC
Created attachment 27194 [details]
debug patch

are you using the linux-next tree?
please apply this patch on top of the linus tree and attach the dmesg output after "grep . /proc/acpi/battery/*/*"
Comment 29 Sitsofe Wheeler 2010-08-24 10:50:20 UTC
Created attachment 27741 [details]
Contents of /sys/class/power_supply/BAT0

I've applied this patch and it changes what is reported in /proc/acpi/battery but it seems to confuse matters more. Tools no longer understand how full the battery is (for example it seems like there is 1.7% left when it is actually 90% full because charge_full=5200000 but charge_now=90000 and 90000/5200000*100 is roughly 1.73).

(I've also applied mjg59's patch in http://lkml.org/lkml/2010/8/23/361 )
Comment 30 Sitsofe Wheeler 2010-08-24 10:56:34 UTC
Zhang:
I don't see any dmesg output after running that grep with the patch (applied atop roughly 2.6.36-rc) in #28 and mjg59's patch.
Comment 31 Zhang Rui 2010-10-08 06:39:50 UTC
(In reply to comment #29)
> Created an attachment (id=27741) [details]
> Contents of /sys/class/power_supply/BAT0
> 
please attach the output of "grep . /sys/class/power_supply/BAT0/*" after applying the patch  in comment #28. and the same output of a CLEAN kernel, i.e. without any of the patch discussed above.
Comment 32 Sitsofe Wheeler 2010-10-09 09:11:32 UTC
Created attachment 32952 [details]
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00
Comment 33 Sitsofe Wheeler 2010-10-09 09:16:00 UTC
Created attachment 32962 [details]
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00 with patch

As previously mentioned, the patch breaks userspace battery monitoring tools (such as gnome-power-manager) causing them to report that the battery is empty.
Comment 34 Sitsofe Wheeler 2010-10-09 09:18:23 UTC
Can someone punt this bug out of NEEDINFO? I'd hate for it to get overlooked...
Comment 35 Sitsofe Wheeler 2010-10-09 09:21:46 UTC
Oh and here's the diff of the output before and after the patch:

--- batout-00069-g6b0cd00.txt	2010-10-09 10:07:09.347533502 +0100
+++ batout-00069-g6b0cd00-dirty.txt	2010-10-09 10:04:40.362719001 +0100
@@ -1,5 +1,5 @@
 /sys/class/power_supply/BAT0/alarm:0
-/sys/class/power_supply/BAT0/charge_full:100000
+/sys/class/power_supply/BAT0/charge_full:5200000
 /sys/class/power_supply/BAT0/charge_full_design:5200000
 /sys/class/power_supply/BAT0/charge_now:70000
 /sys/class/power_supply/BAT0/current_now:-1000
@@ -20,7 +20,7 @@
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_NOW=7534000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CURRENT_NOW=-1000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL_DESIGN=5200000
-/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL=100000
+/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL=5200000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_NOW=70000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_MODEL_NAME=900
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_MANUFACTURER=ASUS
Comment 36 Sitsofe Wheeler 2010-10-09 09:34:59 UTC
Oh and here's the snippet of dmesg output (I suspect I was previously mistaken that no output was produced in comment #30):

[    1.782481] atl2 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17 
[    1.782504] atl2 0000:03:00.0: setting latency timer to 64
[    1.789871] 1. Capacity now 802. Capacity now 4160
[    1.789893] ACPI: Battery Slot [BAT0] (battery present) 
[    1.821448] ath5k 0000:01:00.0: enabling device (0000 -> 0002)
Comment 37 Zhang Rui 2010-10-11 05:57:30 UTC
Created attachment 33212 [details]
patch v2: support percentage battery remaining capacity

please try this patch and see if it works.
Comment 38 Sitsofe Wheeler 2010-10-11 22:33:36 UTC
Created attachment 33282 [details]
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00 with patch v2

v2 of the patch seems to produce pretty much the same issue as v1 - battery monitoring programs (e.g. gnome-power-manager 2.30.0-0ubuntu1) think the battery has 1.9% charge in it.

Here's another diff:

--- batout-00069-g6b0cd00-dirty.txt  2010-10-09 10:04:40.362719001 +0100
+++ batout-00069-g6b0cd00-dirty-2.txt        2010-10-11 23:30:32.261676504 +0100
@@ -1,7 +1,7 @@
 /sys/class/power_supply/BAT0/alarm:0
 /sys/class/power_supply/BAT0/charge_full:5200000
 /sys/class/power_supply/BAT0/charge_full_design:5200000
-/sys/class/power_supply/BAT0/charge_now:70000
+/sys/class/power_supply/BAT0/charge_now:100000
 /sys/class/power_supply/BAT0/current_now:-1000
 /sys/class/power_supply/BAT0/cycle_count:0
 /sys/class/power_supply/BAT0/manufacturer:ASUS
@@ -17,13 +17,13 @@
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_TECHNOLOGY=Li-ion
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CYCLE_COUNT=0
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_MIN_DESIGN=8400000
-/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_NOW=7534000
+/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_NOW=7971000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CURRENT_NOW=-1000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL_DESIGN=5200000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL=5200000
-/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_NOW=70000
+/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_NOW=100000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_MODEL_NAME=900
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_MANUFACTURER=ASUS
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_SERIAL_NUMBER= 
 /sys/class/power_supply/BAT0/voltage_min_design:8400000
-/sys/class/power_supply/BAT0/voltage_now:7534000
+/sys/class/power_supply/BAT0/voltage_now:7971000
Comment 39 Sitsofe Wheeler 2010-10-11 22:36:17 UTC
Here's the diff of v2 against vanilla:

--- batout-00069-g6b0cd00.txt        2010-10-09 10:07:09.347533502 +0100
+++ batout-00069-g6b0cd00-dirty-2.txt        2010-10-11 23:30:32.261676504 +0100
@@ -1,7 +1,7 @@
 /sys/class/power_supply/BAT0/alarm:0
-/sys/class/power_supply/BAT0/charge_full:100000
+/sys/class/power_supply/BAT0/charge_full:5200000
 /sys/class/power_supply/BAT0/charge_full_design:5200000
-/sys/class/power_supply/BAT0/charge_now:70000
+/sys/class/power_supply/BAT0/charge_now:100000
 /sys/class/power_supply/BAT0/current_now:-1000
 /sys/class/power_supply/BAT0/cycle_count:0
 /sys/class/power_supply/BAT0/manufacturer:ASUS
@@ -17,13 +17,13 @@
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_TECHNOLOGY=Li-ion
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CYCLE_COUNT=0
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_MIN_DESIGN=8400000
-/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_NOW=7534000
+/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_VOLTAGE_NOW=7971000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CURRENT_NOW=-1000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL_DESIGN=5200000
-/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL=100000
-/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_NOW=70000
+/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_FULL=5200000
+/sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_CHARGE_NOW=100000
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_MODEL_NAME=900
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_MANUFACTURER=ASUS
 /sys/class/power_supply/BAT0/uevent:POWER_SUPPLY_SERIAL_NUMBER= 
 /sys/class/power_supply/BAT0/voltage_min_design:8400000
-/sys/class/power_supply/BAT0/voltage_now:7534000
+/sys/class/power_supply/BAT0/voltage_now:7971000
Comment 40 Zhang Rui 2010-10-12 01:35:13 UTC
Created attachment 33292 [details]
debug patch

would you please apply this patch instead and attach the dmesg output after running "grep . /sys/class/power_supply/BAT0/*"?
Comment 41 Zhang Rui 2010-10-12 01:38:15 UTC
BTW: do you know how the battery monitoring program get battery status?
is this info got from /sys/class/power_supply?
Comment 42 Sitsofe Wheeler 2010-10-12 07:58:18 UTC
Created attachment 33302 [details]
dmesg after applying debug patch

The battery monitoring on this system is actually done by upowerd and gnome-power-manager queries this. The source for the relevant part of upowerd can be read on http://cgit.freedesktop.org/DeviceKit/upower/tree/src/linux/up-device-supply.c#n393 (the up_device_supply_refresh_battery function). A casual inspection suggests it is using sysfs as the properties it is looking for only exist in one place in the /sys/ hierarchy.
Comment 43 Zhang Rui 2010-10-12 08:19:14 UTC
Created attachment 33312 [details]
patch v3: support percentage battery remaining capacity

please try this patch which I think it should work for you. :)
Comment 44 Zhang Rui 2010-10-12 08:20:23 UTC
wait for a minute, I'll send a refreshed patch soon
Comment 45 Zhang Rui 2010-10-12 08:33:18 UTC
Created attachment 33322 [details]
patch v3: support percentage battery remaining capacity

please try this patch instead. :)
Comment 46 Sitsofe Wheeler 2010-10-12 09:47:08 UTC
:D I have to admit I like structure of your patch. I guess the only catch is that a couple of extra tests are done every time a battery (even the majority which presumably don't have this issue) is checked right?

The v3 patch fixes the original issue and battery reporting programs show the correct amount of battery remaining on my EeePC 900 with a 1006 BIOS version. I've watched the battery go from 90% to 80%. The battery itself is quirky suddenly jumping from 80% full down to 0% but the battery warning light on the EeePC also suddenly came on and plugging it into the mains and then unplugging it seemed to reset things back to 70% so I believe that event seems unrelated to this patch.

I enabled the "low battery total capacity warning" via /apps/gnome-power-manager/notify/low_capacity and when logging in with the v3 patch a bad battery warning is NOT displayed (whereas using a vanilla kernel a bad battery warning was erroneously displayed when logging in with the aforementioned gconf key set). If anything, this patch seems to improve the battery reporting programs as the gnome-power-manager's graphs seem to show entries at exact intervals: i.e. 90% rather than 92% as it did previously.

Thanks for looking at this Zhang Rui!

Tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>

PS: In the patch comment ramaining -> remaining and rechargable -> rechargeable.

For people who stumble across this bug report in the future you may want to see https://bugzilla.redhat.com/show_bug.cgi?id=439460 , https://bugs.launchpad.net/ubuntu/+source/devicekit-power/+bug/403303 and http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/2008-October/001477.html .
Comment 47 Zhang Rui 2010-10-13 00:24:22 UTC
good news.
I've send the patch to ACPI mail list, https://patchwork.kernel.org/patch/249461/
Comment 48 Len Brown 2010-10-13 16:29:28 UTC
applied to acpi-test
Comment 49 Zhang Rui 2010-10-22 02:37:37 UTC
patch is refreshed because of the conflict with ACPI procfs cleanup patches.
https://patchwork.kernel.org/patch/272721/
Comment 50 Len Brown 2010-11-02 02:55:02 UTC
shipped in Linux-2.6.37-rc1
original patch from comment #47 submitted to 2.6.35..2.6.36.stable

closed

commit 557d58687dcdee6bc00c1a8f1fd4e0eac8fefce9
Author: Zhang Rui <rui.zhang@intel.com>
Date:   Fri Oct 22 10:02:06 2010 +0800

    ACPI battery: support percentage battery remaining capacity

Note You need to log in before you can comment on or make changes to this bug.