The battery state of my Notebook (Belinea o.book 1301) is not determined correctly. Usually after booting it shows a bit less than a quarter of the actual battery charge, e.g. 23% instead of 99% or 10% instead of 43%. Reloading the battery module with "rmmod battery && modprobe battery" solves the problem. Sometimes (randomly?) it does not occur at all. This happens at least since Linux 2.6.32 on Debian. I have also tried Linux 2.6.37-rc5 and several versions in between, all with the same result. The issue may be related to bug 14867 concerning the same hardware: My ac adapter also is not detected.
Created attachment 40842 [details] "acpi -V" before "rmmod battery && modprobe battery"
Created attachment 40852 [details] "acpi -V" after "rmmod battery && modprobe battery"
Created attachment 40862 [details] "acpidump" before "rmmod battery && modprobe battery"
Created attachment 40872 [details] "acpidump" after "rmmod battery && modprobe battery" Both invocations of acpidump generated the error message "Wrong checksum for generic table!"
Created attachment 40882 [details] "dmidecode" before "rmmod battery && modprobe battery"
Created attachment 40892 [details] "dmidecode" after "rmmod battery && modprobe battery"
Created attachment 40902 [details] dmesg The last line occurred when I reloaded the battery module.
so the battery status is always correct after you unloading/loading the battery driver again, right? what if you unplug/plug the AC adapter, is the battery status updated?
Unplugging or plugging the AC adapter correctly updates the AC adapter status (which also is often incorrect after booting) but leaves the battery state untouched. Only unloading and loading the battery module seems to always restore the battery state to its true value.
(In reply to comment #9) > Unplugging or plugging the AC adapter correctly updates the AC adapter status > (which also is often incorrect after booting) please try the patch attached below and see if the AC adapter status is shown correctly.
Oh, I mean the patch here: http://marc.info/?l=linux-acpi&m=129177604615355&w=2
Unfortunately I was unable to apply the patch to 2.6.32. But I did a few reboots with Linux 2.6.37-rc7, which already contains those four lines, and could not reproduce the AC adapter bug, so the patch seems to fix it. The battery state however still is not always determined correctly.
so you may want to try this patch http://marc.info/?l=linux-acpi&m=129177607115387&w=2 to see if the battery problem is gone. Note that this patch has already been reverted as it causes an oops. If this patch help, I think this is a known problem, which we will fix after rewriting the battery driver.
I booted about ten times with the patch and the battery status was always detected correctly, so I suppose it was the same problem. Thank you very much for your quick responses and for pointing out the patch for me!
good to know. let's leave this bug open for a few days because the current fix is dropped from upstream kernel. I'll close it after rewriting the battery driver, sometime in Q1 2011. :)
Hi, Tianyu, any update on this?
Hi: Does this problem exist in the latest kernel?
I just tried out kernel 3.9 on the old laptop and the problem still exists: It sometimes shows only a quarter of the real battery status and going into and returning from suspend quadruples it.
Please try following patch. Thanks in advance. diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index c5cd5b5..347ed04 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -146,6 +146,9 @@ struct acpi_battery { #define to_acpi_battery(x) container_of(x, struct acpi_battery, bat) +static int acpi_battery_get_info(struct acpi_battery *battery); +static int acpi_battery_get_state(struct acpi_battery *battery); + inline int acpi_battery_present(struct acpi_battery *battery) { return battery->device->status.battery_present; @@ -200,6 +203,7 @@ static int acpi_battery_get_property(struct power_supply *psy, if (acpi_battery_present(battery)) { /* run battery update only if it is present */ + acpi_battery_get_info(battery); acpi_battery_get_state(battery); } else if (psp != POWER_SUPPLY_PROP_PRESENT) return -ENODEV;
ping ...
Thank you, the patch seems to work! I applied it and rebooted ten times: I could not reproduce the problem.
Great, I will upstream the patch as soon as possible.
Hi, can you provide "grep . /sys/class/power_supply/*/*" twice without my previous patch? First time is at error battery charge. Second time is after uploading and loading battery driver when the battery charge is correct.
Created attachment 99991 [details] Output of "grep . /sys/class/power_supply/*/*" with wrong charge.
Created attachment 100001 [details] Output of "grep . /sys/class/power_supply/*/*" with right charge.
Sorry for late reply. From the output， The first log show AML BIF/BIX return error charge_full and charge_full_design /sys/class/power_supply/BAT0/charge_full:20499000 <== /sys/class/power_supply/BAT0/charge_full_design:276000 <== /sys/class/power_supply/BAT0/charge_now:4369000 Please try following patch diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c index e710045..087c683 100644 --- a/drivers/acpi/battery.c +++ b/drivers/acpi/battery.c @@ -35,6 +35,7 @@ #include <linux/slab.h> #include <linux/suspend.h> #include <asm/unaligned.h> +#include <linux/delay.h> #ifdef CONFIG_ACPI_PROCFS_POWER #include <linux/proc_fs.h> @@ -429,9 +430,13 @@ static int acpi_battery_get_info(struct acpi_battery *battery) "_BIX" : "_BIF"; struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; + int i = 3; if (!acpi_battery_present(battery)) return 0; + + while (i-- > 0) { + msleep(3000); mutex_lock(&battery->lock); status = acpi_evaluate_object(battery->device->handle, name, NULL, &buffer); @@ -441,6 +446,7 @@ static int acpi_battery_get_info(struct acpi_battery *battery) ACPI_EXCEPTION((AE_INFO, status, "Evaluating %s", name)); return -ENODEV; } + } if (test_bit(ACPI_BATTERY_XINFO_PRESENT, &battery->flags)) result = extract_package(battery, buffer.pointer, extended_info_offsets,
I booted ten times again: That patch seems to work, too.
Created attachment 101921 [details] debug.patch Sorry for late reply. Please try this patch which just remvoe the sleep.
Without the sleep, the bug occurs again.
Ok. How about bootup without battery and then insert it? The battery volume will be correct? I produce a patch which will try to check the design_capacity and last_full_capacity for 30 times and 100ms among them. When design_capacity is great than last_full_capacity, it will jump out of loop and produce a log. Please try this patch and attach the output of dmesg. Thanks.
Created attachment 103531 [details] debug.patch
Created attachment 104031 [details] dmesg: booted without, then inserted battery
Created attachment 104041 [details] dmesg: booted without, then inserted battery I just noticed that after inserting the battery, the status was in fact wrong. I removed and inserted it again, and now it is correct. I updated the dmesg output.
Ok. Thanks for test. How about patch in the comment #30? Could you test it?
Sorry. I see the log. Original, I want to test the patch with battery inserted and check whether battery driver can get correct battery info. From the log, the battery state is present when battery is not inserted, right? This looks strange. I only can say this is a Bios issue. Anyway, please try the patch again with battery inserted and check the battery info. I think it can work unless we need more delay.
Created attachment 104761 [details] dmesg: booted with battery, got wrong value Sorry for the long delay! This is the dmesg output when booting with inserted battery and with the patch: After a few attempts, the charge was displayed wrong again. (BTW, I would completely understand should you decide not to pursue this issue further: After all, I'm just one user with old and possibly broken hardware. But if you decide to continue, I'll happily do more experiments, of course.)
Created attachment 104771 [details] dmesg: booted with battery, got right value This is the dmesg output of an attempt with patch and inserted battery where the bug didn't occur.
So sorry for later response. These logs show the EC part of battery info works abnormally about the 10s of bootup. It's hard to add such delay in the battery driver since this totally depends on the kernel configure. I have pushed the patch in the comment 19 which can fix this issue but get some feedback that it breaks battery info cache function. This bug is apparently caused by EC related hardware bug and not sure whether this happens on the another such machine. So marked this bug as WILL_NOT_FIX.