Bug 7200
| Summary: | battery not detected on laptop - nec versa p550 | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Stefan Geuns (bitrain) |
| Component: | Power-Battery | Assignee: | Vladimir Lebedev (vladimir.p.lebedev) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, habraken |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
dmesg output of kernel 2.6.18
dmesg output of 2.6.15 battery_check_patch.txt dmesg with laptop running on battery power .config for 2.6.18 battery_check_patch2 battery state, info and alarm and acpidump 2.6.18 dmesg output of 2.6.18 10 times cat /proc/acpi/battery/*/* dmesg Acpidump dmesg. clean_battery_check_status.patch |
||
|
Description
Stefan Geuns
2006-09-25 04:03:13 UTC
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. |