Bug 117820

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.