Bug 187517

Summary:	pm-hibernate confuses hal
Product:	[Fedora] Fedora	Reporter:	David L. <lowe>
Component:	hal	Assignee:	David Zeuthen <davidz>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5	CC:	mclasen
Target Milestone:	---
Target Release:	---
Hardware:	i686
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-03-11 16:44:30 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David L. 2006-03-31 15:52:21 UTC

Description of problem:
After a fresh boot, HAL correctly records the lid state of my laptop (open):
 lshal | grep button.state
 button.state.value = false  (bool)

On lid close, my acpi script calls pm-hibernate. Upon opening the lid and
resuming I find:
lshal | grep button.state
  button.state.value = true  (bool)
So hal thinks the lid is still closed

After service haldaemon restart:
lshal | grep button.state
  button.state.value = false  (bool)
hal again correctly thinks the lid is open




Version-Release number of selected component (if applicable):
pm-utils-0.15-1
hal-0.5.7-3

How reproducible:
always



Additional info:
This is probably related to gnome-power-manager bug
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187396
However the hal confusion happens with gnome-power-manager off, so hopefully
there is some nice way for pm-hibernate to reset it?

Should also mention acpi correctly records the lid state in all cases -- so my
acpi power management scripts work fine. The bug only seems to prevent me using
gnome-power-manager

Comment 1 David Zeuthen 2006-09-28 21:05:47 UTC

This is most likely kernel bug - the event for ACPI open is not sent out
correctly. In fact, in HAL we work around this by rescanning the buttons on
resume. But this obviously won't work with calling pm-suspend and/or
pm-hibernate from the command line. Unless you put cruft like

 http://cvs.fedora.redhat.com/viewcvs/rpms/hal/FC-5/hal-0.5.7-lid-open-fix.patch?rev=1.1&view=auto

into the pm hooks.

Does 

 dbus-send --system --print-reply --dest=org.freedesktop.Hal \
 /org/freedesktop/Hal/devices/computer \ 
 org.freedesktop.Hal.Device.SystemPowerManagement.Suspend int:0

work instead? Replace ".Suspend int:0" with ".Hibernate" for hibernation instead.

Thanks.

Comment 2 David Zeuthen 2006-09-28 21:08:49 UTC

Comment 1: Replace "int:0" with "int32:0"

My bad, sorry.

Comment 3 petrosyan 2008-03-11 16:44:30 UTC

The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there have not been any
updates to the report since thirty (30) days or more since we
requested additional information, we're assuming the problem
is either no longer present in the current Fedora release, or
that there is no longer any interest in tracking the problem.

Setting status to "INSUFFICIENT_DATA".  If you still
experience this problem after updating to our latest Fedora
release and can provide the information previously requested, 
please feel free to reopen the bug report.

Thank you in advance.