Bug 15979
|
Description
Ferry Toth
2010-05-15 19:30:43 UTC
please attach the acpidump output. please attach the dmesg output after boot. Created attachment 26464 [details]
acpidump
Created attachment 26465 [details]
dmesg
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? 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 (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? 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 (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. 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 (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. 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 (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. 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.
please re-open it if the patch doesn't help. ferry, would you please test the patch please? I'll try to push it upstream if it works for you. 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 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 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 Created attachment 27069 [details]
patch: support percentage battery remaining capacity
please try this patch instead.
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 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. 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 (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. 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 Created attachment 27172 [details]
acpidump of patched kernel
Created attachment 27173 [details]
dmesg of patched kernel
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);
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/*/*"
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 ) 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. (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. Created attachment 32952 [details]
/sys/class/power_supply/BAT0/* for 2.6.36-rc7-00069-g6b0cd00
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.
Can someone punt this bug out of NEEDINFO? I'd hate for it to get overlooked... 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 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) Created attachment 33212 [details]
patch v2: support percentage battery remaining capacity
please try this patch and see if it works.
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
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 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/*"?
BTW: do you know how the battery monitoring program get battery status? is this info got from /sys/class/power_supply? 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. Created attachment 33312 [details]
patch v3: support percentage battery remaining capacity
please try this patch which I think it should work for you. :)
wait for a minute, I'll send a refreshed patch soon Created attachment 33322 [details]
patch v3: support percentage battery remaining capacity
please try this patch instead. :)
: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 . good news. I've send the patch to ACPI mail list, https://patchwork.kernel.org/patch/249461/ applied to acpi-test patch is refreshed because of the conflict with ACPI procfs cleanup patches. https://patchwork.kernel.org/patch/272721/ 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 |