Bugzilla – Bug 117820
kpowersave shows correct battery-status as percentage, but wrong time remaining (00:01 at 98%)
Last modified: 2005-09-28 07:52:59 UTC
kpowersave shut my computer down when the battery was still at 50%. So I had a look at the kpowersave kicker-icon and indeed, although the percentage is shown correctly, e.g. 98% loaded, the time remaining is shown as 00:01. I plugged in/out the power-cable but I cannot find a way to reproduce why it sometimes displays 00:01, 00:02, or even a correct time for some time but then back to 00:01. I think that kpowersave shut down the computer because it calculated the time incorrectly and thus hit the limit to trigger the shutdown.
KPowersave does not shutdown the machine. If the machine is shut down because of battery fill, this was shutdown by powersave. But powersave shutdown only related to percentage and not by remaining time. Maybe a problem with ACPI on your machine.
I think we ran into a very rare code path. To be sure, please post the output of /proc/acpi/battery/*/state.
Additionally, it would be helpful if you could also post the values of the three variables BATTERY_WARNING, BATTERY_LOW and BATTERY_CRITICAL in /etc/sysconfig/powersave/battery. Thanks.
Indeed this is an older notebook. With Suse 9.1 Standby and Suspend worked perfectly, I guess APM was used. With 9.3 it did not work. Suse 10 works again, although Fn+F1 which is LCD Off does not work anymore, although it did before, even for 9.3. This is when it shows 02:00 time remaining. pc192s:/home/rabauke # cat /proc/acpi/battery/*/state present: yes capacity state: ok charging state: discharging present rate: 1021 mA remaining capacity: 2038 mAh present voltage: 16969 mV present: no I switched to power and back to battery, after that there was the 00:02 problem and I got the following: pc192s:/home/rabauke # cat /proc/acpi/battery/*/state present: yes capacity state: ok charging state: discharging present rate: 64455 mA remaining capacity: 2033 mAh present voltage: 16081 mV present: no BATTERY_WARNING is 12 BATTERY_LOW is "" BATTERY_CRITICAL is "" When I use Yast to display the battery-settings, I get 12, 7 and 2. Even hitting OK in Yast does not seem to save the settings to the file. As I said before, although suspend to disk works perfectly, I think that this notebook has APM. I did not change anything, yet powersave gives me: pc192s:/home/rabauke # powersave -S ACPI
hm looks like a problem with the values from ACPI. 64455 mA for present rate is to high. What happens if you stop powersaved with 'rcpowersaved stop' and do the same? Normalise the value for present rate after a while? How long need this? Or is this value permanently high?
The value stays that high, no matter if powersaved is running or not. It does not change over time. I only get a lower value, if I plug the power in. If I un-plug it, it shows the correct timeuntil it updates its percentage. I guess the values are re-calculated every few seconds. I get: power-plug icon -> battery icon with correct time -> battery icon with wrong time. Is it maybe that powresaved should simply recognise that it should use APM? If not, how can I find out where this huge value comes from?
So we have got a really good example of bad bios acpi implementation IMO. Therefore we cannot do much about it I fear. If you like to use apm, simply boot with option acpi=off on the boot prompt. BTW: It is ok that BATTERY_LOW and BATTERY_CRITICAL are empty in the config file. This way, we use the default values mentioned in the comment directly above the variable.
Setting acpi=off solves all the issues! Fn+F1 turns the LCD off again. Fn+F3 goes into Standby again (triggered suspend-to-disk before) Fn+F4 goes into Suspend to RAM (triggered suspend-to-disk before) kpowersave's suspend-to-disk still works perfectly (except for the PCMCIA-network-adapter issue). The remaining-time is shown correctly now, all the time! Please add a question to the installation process, asking the user whether ACPI is supported by the notebook/PC SuSE is installed on! It will save people a lot of hassle. I am not sure if there is a way to detect this automatically, but asking users will only take 2 seconds and be so pleasing to those with only APM. One could maybe add a small text explaining, that old notebooks probably just support APM.
I have to correct myself, even the issue with suspend-to-disk not recovering, if a network-adapter was plugged in when suspending but plugged out when resuming works now.
But your system supports acpi! But its implementation is buggy. Usually acpi should be the better choice, except for such rare issues were acpi is supported, but not useable. So we choose acpi per default if the system supports it, otherwise apm. The problem is that we cannot determine whether the acpi implementation is clean in the first place. And a user who knows that apm works better on his machine can do the installation in "acpi disabled mode", which can be chosen when installation CD/DVD displays the bootloader the first time.
Ok, I did not know that back in 1998 ACPI was already supported. I blame it on the notebook then. :) Thanks a lot for the info. Is this bug a WORKSFORME or INVALID, I was not sure, so feel free to close it.
So I think this is WONTFIX, because we cannot do much about the acpi implementation.