Most recent kernel where this bug did not occur: Distribution: fedora/ubuntu/suse Hardware Environment: nec versa p550 Software Environment: fedora core <= 5.90, ubuntu <= 6.06, suse 10 Problem Description: The battery is not found after booting. But when I plugin the power cord or remove it then the battery is and remains detected. Steps to reproduce: Boot and see: battery not present. acpi version: 1.04 Battery info after plugging in the cable: $ cat /proc/acpi/battery/BAT1/info present: yes design capacity: 4800 mAh last full capacity: 3507 mAh battery technology: rechargeable design voltage: 14800 mV design capacity warning: 400 mAh design capacity low: 140 mAh capacity granularity 1: 64 mAh capacity granularity 2: 64 mAh model number: PC-VP-WP66/OP-570-76620 serial number: battery type: LION OEM info: NEC
Please attach: kernel version (uname -a), dmesg output, content of /proc/acpi/battery/*/* files, after booting with failure. > Boot and see: battery not present. ------------------- Where have you seen this message: "battery not present"? Is this boot log? Also, try the latest stable kernel version (2.6.18 is available now) and send the results (dmesg, etc).
Created attachment 9100 [details] dmesg output of kernel 2.6.18 $ uname -a Linux dyn099180.nbw.tue.nl 2.6.18-1.2189.fc5 #1 Fri Sep 22 18:59:56 EDT 2006 i686 i686 i386 GNU/Linux $ pwd /proc/acpi/battery/BAT1 $ ls alarm info state $ cat * present: no present: no present: no
Created attachment 9101 [details] dmesg output of 2.6.15
$ uname -a Linux s050412 2.6.15-27-686 #1 SMP PREEMPT Sat Sep 16 02:13:27 UTC 2006 i686 GNU/Linux $ cat /proc/acpi/battery/BAT1/info present: no $ cat /proc/acpi/battery/BAT1/state present: no $ cat /proc/acpi/battery/BAT1/alarm present: no
Created attachment 9114 [details] battery_check_patch.txt Please apply this patch and send the results.
Created attachment 9117 [details] dmesg with laptop running on battery power It works! I could not find battery.c in the fedora 2.6.18 kernel sources, so I downloaded, patched and compiled a kernel.org 2.6.18 kernel and it worked.
> I could not find battery.c in the fedora 2.6.18 kernel sources, so I > downloaded, patched and compiled a kernel.org 2.6.18 kernel and it worked. Please verify that the problem exists on 2.6.18 without my patch. Also, please attach your 2.6.18 .config file.
Also please attach acpidump.
Created attachment 9314 [details] .config for 2.6.18 My .config file for 2.6.18. I recompiled 2.6.18 without the patch and the status is no longer displayed. I also tried 2.6.181 and it also did not work. I haven't tried that one with the patch. I don't have acpidump, but I asked a friend who has the same laptop to compile 2.6.18 and post it.
Created attachment 9325 [details] battery_check_patch2 I need some additional info from your laptop: please remove the previous patch, apply the latest (battery_check_patch2); after reboot perform few times 'cat /proc/acpi/battery/*/*' and post dmesg.
Created attachment 9344 [details] battery state, info and alarm and acpidump 2.6.18 I have build 2.6.18 with the patch, and got it working. Here is my output of /proc/acpi/battery/BAT1/* and acpidump (ubuntu 6.06.1) when power is not plugged in.
Thanks. I also asked: after reboot perform few times 'cat /proc/acpi/battery/*/*' and post dmesg.
I also tried the 2nd patch, but for me it doesn't work (fedora 5). Maybe the patching went wrong or the recompile, so I'll try again later. The /proc/acpi/battery directory only has the BAT1 subdir, shouldn't this be BAT0? Someone else told me a while ago that that should be the case if you have only 1 battery.
> I also tried the 2nd patch, but for me it doesn't work (fedora 5). Maybe the > patching went wrong or the recompile, so I'll try again later. We are in investigation stage, please send the 'dmesg' output in any case: success/failure, suse/fedora ... > The /proc/acpi/battery directory only has the BAT1 subdir, shouldn't this be > BAT0? Someone else told me a while ago that that should be the case if you > have only 1 battery. It doesn't matter: all should work fine independently of subdir name.
Created attachment 9347 [details] dmesg output of 2.6.18 dmesg when running on battery power on the patched 2.6.18 kernel
Created attachment 9348 [details] 10 times cat /proc/acpi/battery/*/* 10 times cat /proc/acpi/battery/*/* with a pause of 2 seconds between each. (on patched 2.6.18)
> I also tried the 2nd patch, but for me it doesn't work (fedora 5). Maybe the > patching went wrong or the recompile, so I'll try again later. Could you summarize please, where the patch2 works and where does not?
Created attachment 9359 [details] dmesg I think the patching went wrong, because: dmesg | grep CHECK gave no output and it did for Nicky's dmesg and if I understood your patch, then it should always print something starting with CHECK?
> gave no output and it did for Nicky's dmesg and if I understood your patch, > then it should always print something starting with CHECK? Yes. > Could you summarize please, where the patch2 works and where does not? Thus, is the problem solved or not? If it is solved, I am going to attach the cleaned patch (without printing ...) and close the bug.
It works now. dmesg | grep CHECK reports 4 times battery absent and then 13 times battery present. You can close the bug, thanks for the help!
*** Bug 6183 has been marked as a duplicate of this bug. ***
Created attachment 9548 [details] Acpidump I have the same problem, applied the patch2 but the problem still exist. uname -a Linux centrinox 2.6.18.2-centrino #1 SMP PREEMPT Fri Nov 17 10:31:46 CLST 2006 i686 GNU/Linux debian etch, lastest vanilla kernel Laptop: Packardbell EasyNote L2 after boot on battery: cat /proc/acpi/battery/BAT1/info present: no After plug de AC: cat /proc/acpi/battery/BAT1/info present: yes design capacity: 4000 mAh last full capacity: 3055 mAh battery technology: rechargeable design voltage: 9600 mV design capacity warning: 400 mAh design capacity low: 122 mAh capacity granularity 1: 64 mAh capacity granularity 2: 64 mAh model number: PC-VP-WP66/OP-570-76620 serial number: battery type: NiMH OEM info: NEC
Marco, Please perform 'cat /proc/acpi/battery/BAT1/*' about 10 times and send the dmesg output. Also see comment #20.
Created attachment 9556 [details] dmesg. first time after boot on battery: cat /proc/acpi/battery/BAT1/* present: no present: no present: no Second time... cat /proc/acpi/battery/BAT1/* alarm: unsupported present: yes design capacity: 4000 mAh last full capacity: 3055 mAh battery technology: rechargeable design voltage: 9600 mV design capacity warning: 400 mAh design capacity low: 122 mAh capacity granularity 1: 64 mAh capacity granularity 2: 64 mAh model number: PC-VP-WP66/OP-570-76620 serial number: battery type: NiMH OEM info: NEC present: yes capacity state: ok charging state: discharging present rate: 1167 mA remaining capacity: 2853 mAh present voltage: 12030 mV :-O. after doing this the battery is recognized :D dmesg |grep CHECK shows five times battery absent, and 9 times present I tried booting several times, and always the battery is recognized after doing de "cat /proc/acpi...." thing. Thanks.
after doing 'cat /proc/acpi/battery/BAT1/*' about 15 times, I get ACPI: CHECK #1: Battery Slot [BAT1] (battery absent) ... ... ACPI: CHECK #5: Battery Slot [BAT1] (battery absent) ACPI: CHECK #6: Battery Slot [BAT1] (battery present) .... .... ACPI: CHECK #86: Battery Slot [BAT1] (battery present)
You said you would add a patch without printing, but it still isn't in the latest kernel. When is it going to be added?
Created attachment 10214 [details] clean_battery_check_status.patch > You said you would add a patch without printing, but it still isn't in the > latest kernel. When is it going to be added? Sorry fot the dalay, fixed. Please verify it once again.
I've tried the new patch on a 2.6.19-suspend2-r1 kernel (standard gentoo and suspend2 patches) and it seems to work fine. dmesg | grep BAT still says ACPI: Battery Slot [BAT1] (battery absent) but acpitools sees it (and it's in the /proc dir).
>I've tried the new patch on a 2.6.19-suspend2-r1 kernel (standard gentoo and >suspend2 patches) and it seems to work fine. Thanks for the help. Also: >dmesg | grep BAT still says >ACPI: Battery Slot [BAT1] (battery absent) >but acpitools sees it (and it's in the /proc dir). BIOS of your system gives the battery status as 'battery absent' few times, but shows normal battery state after that. So I mark the bug as 'RESOLVED'.
I don't really know if it is related, but i've had it three times now, and only after applying the clean_battery_check_status.patch: kacpid goes wild, and starts using 99% processing power 'randomly' meaning i have to kill it with -9 for the system to back to a normal state. Is there any way this code could create an endless loop or anything ?
This is very strange situation: there is no any loop in clean_battery_check_status.patch - this patch is very simple ); it works when user/application access /proc/acpi/battery files and battery is 'battery absent' state. So: please provide more info (kernel version, dmesg) w/ and w/o patch. Be sure that you use the same kernel version w/ and w/o patch. Also; you can try old patch and compare the results.
patch in comment #27 applied to acpi-test
patch in comment #27 shipped in Linux-2.6.21-rc1. Closed.