Bugzilla – Bug 115030
Battery not properly detected
Last modified: 2007-06-05 10:01:15 UTC
I am running Suse 10.0 Beta 3 on a HP Pavilion ZE2000z. Mainboard is ati radeon xpress 200m and cpu is amd turion 64 ml-30. It appears that the battery is not being set up as powersaved is expecting it to be. I've read through other bug reports with references to BAT0 in /proc/acpi/battery, but I don't have this. Instead, I have a BAT1. Powersaved is reporting that my battery is not being detected and I suspect it's not even attempting to look at BAT1 as it is reporting battery status just fine. Unpluggin ac results in the system warning me there is no battery life remaining and so acpi becomes rather useless for battery management.
please add this outputs (and please also try Beta4): - powersave -B - lshal and the file generated by this command: for F in `find /proc/acpi/battery/* -type f`; do echo "File:$F" >> cat_bat; cat $F >> cat_bat ; done;
Created attachment 48641 [details] Output of lshal command
Created attachment 48642 [details] cat_bat file from shell one liner
I've attached cat_bat and the output of lshal. Below is from powersave -B: linux:~ # powersave -B Battery: error. AC is online. Battery0: 0
Danny: "present voltage: unknown" might confuse hal? suspicious items: battery.charge_level.current = 0 (0x0) (int) this might come from "unknown voltage == 0" and multiplying with the voltage in the calculation. We love Richard ;-) Beau: please try "time cat /proc/acpi/battery/BAT1/*", maybe this takes excessively long (more than, say, 0.5 seconds), which would lead to bug #113056. I think this might be a duplicate of bug #113056, so you should maybe try the ec_burst options mentioned there.
I didn't notice it being excessive when I was browsing around and checking various things, such as this. That report stats it's taking multiple seconds to check a single file there, but checking all three reports: real 0m0.721s user 0m0.000s sys 0m0.036s I will go ahead and try the ec_burst option and see what happens.
700msec might be too long for hal (i am not familiar with it), but the "voltage unknown" will more likely confuse it (this is a case that nobody has considered yet, i suppose). Danny will tell us more about HAL :-) Thanks for the report, this is something we did not encounter on our test machines.
Using ec_burst=0 did bring the time down (to <120 ms), but it did not fix the battery problem. lshal appears to report similar values which you had described as possibly problematic. One thing I have noticed with ec_burst=0 is that the laptop responds a lot faster when changing ac state (unplugging and plugging back in).
The time is no problem. This worked also with machines which needed much more time for this. This should work. But the bug is really strange! Could you please do this: - Change line in /etc/init.d/haldaemon: from: HALDAEMON_PARA="--daemon=yes --retain-privileges"; to: HALDAEMON_PARA="--daemon=yes --retain-privileges --verbose=yes"; - restart hal with rchal restart - wait 10 seconds - unplug the AC adapter - wait 30 seconds - insert the AC adapter - wait 10 seconds Now attach your /var/log/messages since the last boot or since the HAL restart.
to #5: the unknown voltage should not be problem, but you found the point of problem ;-) R. No jokes more! The problem: the voltage should also in this code be never 0. If unknown HAL should use there the design voltage value. But wait for the log.
other question to reporter: what say "ps aux | grep acpi" ?
Here is ps aux | grep acpi: linux:~ # ps aux | grep acpi root 7 0.0 0.0 0 0 ? S< Sep02 0:04 [kacpid] root 4768 0.0 0.1 2572 592 ? Ss Sep02 0:00 /usr/sbin/acpid root 5143 0.0 0.4 14292 2300 ? S Sep02 0:07 /usr/sbin/powersaved -d -f /var/run/acpid.socket -v 3 root 12972 0.0 0.1 5960 776 ? S 01:13 0:00 hald-addon-acpi root 13061 0.0 0.1 2920 680 pts/5 R+ 01:18 0:00 grep acpi linux:~ # Attachment coming up with messages log from verbose haldaemon.
Created attachment 48678 [details] messages log showing output of verbose haldaemon
hm ... my mistake. Please do this: - stop hal (with 'rchal stop') - hald --verbose=yes --daemon=no --retain-privileges > /tmp/hal_log 2>&1 - wait 10 seconds - unplug the AC adapter - wait 30 seconds - insert the AC adapter - wait 10 seconds attach the file /tmp/hal_log to the bug
Created attachment 48703 [details] hal log
I was finally able to download beta 4 (most mirrors have incomplete files) so I am going to try a fresh install.
As I realised that you used a Beta 3: This should be fixed already in Beta4. Please retry.
I apologize. I've been trying to get beta 4 since the 1st. It is in fact fixed in beta4. I'm in the process of checking the other bugs I submitted, one of which still looks unresolved.
Therefore setting to fixed...