Bug 146498

Please attach 300 lines of your syslog (/var/log/messages). Are you using ACPI? 

Created attachment 65643 [details]
As you can see on the attached log file, I am using ACPI.

Actually, I have SuSE 10.0 installed in another partition and I am using Powersave 0.11.5 (from the RPMs available in Sourceforge's project page) there. It works fine.

Please remember to always change the bug report back to ASSIGNED as soon as you
added the needed information - as long as you don't, the developers won't see
it on their "my bugs" page.

I prefer bugs to remain in NEED until I reassign them, I handle them in a seperate list.

You may want to try ec_burst=0 boot param.

> You may want to try ec_burst=0 boot param.

It doesn't work either :-(
I remember this bug also showed up in SuSE 10.0 final. The issue was discussed in the Powersave mailing-list and Danny Kukawka wrote:

«This is a known bug in HAL on SUSE related to receive and forward ACPI events 
from acpid. There is already a YOU Update for HAL in the pipe and should be 
available in the next days.»

In fact, the HAL update in 10.0 solved the issue. 
Maybe the current bug has the same origin...

please test this:
* start 'lshal --monitor'
* remove AC adapter and check if there is a message with: "ac_adapter.present = false" and how long the delay between remove AC adapter and this message is

* start: watch -n0,5 'cat /proc/acpi/ac_adapter/AC/state' 
* check if the state is correct displayed immediately if you remove the adapter

* start: acpi_listen
* check if there is immediately a ac_adapter event  if you remove the AC adapter 

> * start 'lshal --monitor'
> * remove AC adapter and check if there is a message with: "ac_adapter.present =
> false" and how long the delay between remove AC adapter and this message is

The delay is about 30 seconds.


> * start: watch -n0,5 'cat /proc/acpi/ac_adapter/AC/state' 
> * check if the state is correct displayed immediately if you remove the adapter

Yes, immediately.


> * start: acpi_listen
> * check if there is immediately a ac_adapter event  if you remove the AC
> adapter 

Yes, immediately.

So I guess the conclusion is that there is a bug in HAL.

Danny are you still doing the hal stuff?
Please reassign if not.

could you please do this:

* ps aux | grep hald-acpi-addon  --> search for the pid of the process
* strace -ff -s 1024 -o /tmp/hald-acpi-addon -p PIDOF_HALD_ACPI_ADDON
* remove ac adapter
* wait until kpowersave show the correct state
* readd ac adapter
* wait until kpowersave show the correct state
* stop the strace with strg+c
* attach /tmp/hald-acpi-addon to this bugreport as attachment

Created attachment 66478 [details]
Here's the information you requested, Danny

Could you try to reproduce this with Beta3, I have currently no idea, what the problem is. What happens if you restart hal and dbus?

Created attachment 66483 [details]
Output of strace -ff -s 1024 -o /tmp/hald-acpi-addon -p PIDOF_HALD_ACPI_ADDON

> Could you try to reproduce this with Beta3, I have currently no idea, 
> what the problem is. What happens if you restart hal and dbus?

My attachment in #11 was made using Beta3.
BUT your tip worked: restarting haldaemon makes powersave react immediately to battery state changes! I have rebooted several times to check if this behavior was consistent. It is. I am attaching the output of strace -ff -s 1024 -o /tmp/hald-acpi-addon -p PIDOF_HALD_ACPI_ADDON now.

Somehow it seems that haldaemon does not work correctly after it is started at boot time, only when it is restarted when all the services have started. Any clue?

Only to be sure if I understand you correct: Also on Beta3 hal only work correct if you restart the service?

If so, could you add/change this in /etc/init.d/haldamon:

replace:
    startproc -p $HALDAEMON_PID $HALDAEMON_BIN $HALDAEMON_PARA
    rc_status -v
with:
    strace -ff -s1024 -tt -o /tmp/hal_strace/hald-strace $HALDAEMON_BIN $HALDAEMON_PARA &
    # rc_status -v

then: mkdir /tmp/hal_strace
and:
* reboot the machine
* wait until hal is running and lshal work
* stop the strace with kill the strace process
* tar -cjf /tmp/hal_strace.tar.bz2 /tmp/hal_strace
* attach the file to the bug.

Created attachment 66486 [details]
hal strace

> Only to be sure if I understand you correct: Also on Beta3 hal only work
> correct if you restart the service?

Yes, that's right. 
And I have made some new findings. I noticed that this behavior of powersave was not deterministic. In about 20% of the times after reboot it worked as expected. I then decided to set RUN_PARALLEL="no" in /etc/sysconfig/boot. After that, I made several reboots and noticed that now it worked as expected in 90% of the cases.
This may indicate that the powersave init script is starting too early, before hal is completely functional.

Hm ... looks like a combination of a bug in HAL (wrong usage of dbus_error) and a race somewhere. I fixed the HAL bug for Beta4, we need to test this then again.

Any news? Reproduceable with beta4?

(In reply to comment #17)
> Any news? Reproduceable with beta4?

Last week I have made a factory installation and I couldn't reproduce the bug. Tomorrow I plan to install Beta4. I will confirm if the bug was really fixed.

(In reply to comment #17)
> Any news? Reproduceable with beta4?

I have tested Beta4 and I couldn't reproduce the bug. Maybe you can mark it as FIXED.

o.k. I set the bug as fixed.