Bug 183709 - hal/gnome-power-manager gets confused about lid state
hal/gnome-power-manager gets confused about lid state
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
: 186331 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-02 18:46 EST by Pekka Pietikäinen
Modified: 2013-03-05 22:45 EST (History)
13 users (show)

See Also:
Fixed In Version: fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-15 03:25:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to make HAL scripts refresh on resume (1.10 KB, patch)
2006-03-27 16:55 EST, Richard Hughes
no flags Details | Diff

  None (edit)
Description Pekka Pietikäinen 2006-03-02 18:46:26 EST
Description of problem:

Since the last few updates (g-p-m 2.13.92-2 now, it worked ok a while back)
whenever I remove the power cord g-p-m performs whatever action 
the "Running on Battery/When laptop lid is closed" is, even when the lid is
open. Annoying!

Here's the acpid.log from the time period:

[Fri Mar  3 01:46:20 2006] received event "ac_adapter AC 00000080 00000000"
[Fri Mar  3 01:46:20 2006] notifying client 1777[68:68]
[Fri Mar  3 01:46:20 2006] completed event "ac_adapter AC 00000080 00000000"
[Fri Mar  3 01:46:20 2006] received event "processor CPU 00000080 00000000"
[Fri Mar  3 01:46:20 2006] notifying client 1777[68:68]
[Fri Mar  3 01:46:20 2006] completed event "processor CPU 00000080 00000000"
[Fri Mar  3 01:46:20 2006] received event "processor CPU 00000081 00000000"
[Fri Mar  3 01:46:20 2006] notifying client 1777[68:68]
[Fri Mar  3 01:46:20 2006] completed event "processor CPU 00000081 00000000"
[Fri Mar  3 01:46:20 2006] received event "battery BAT0 00000080 00000001"
[Fri Mar  3 01:46:20 2006] notifying client 1777[68:68]
[Fri Mar  3 01:46:20 2006] completed event "battery BAT0 00000080 00000001"
[Fri Mar  3 01:46:20 2006] received event "battery BAT0 00000080 00000001"
[Fri Mar  3 01:46:20 2006] notifying client 1777[68:68]
[Fri Mar  3 01:46:20 2006] completed event "battery BAT0 00000080 00000001"

When I really _do_ close the lid I get:

[Fri Mar  3 01:44:24 2006] received event "button/lid LID 00000080 00000001"
[Fri Mar  3 01:44:24 2006] completed event "button/lid LID 00000080 00000001"

(and nothing for reopening it)
Comment 1 Pekka Pietikäinen 2006-03-02 19:08:17 EST
Hmn. I just restarted g-p-m in verbose mode and it stopped doing this. As if
it gets confused by the lid state in some circumstances?

Appears so:

[root@localhost src]# hal-get-property --udi
/org/freedesktop/Hal/devices/acpi_LID --key button.state.value
true
...
playing with the lid button
...
hal-get-property --udi /org/freedesktop/Hal/devices/acpi_LID --key
button.state.value
false

(and obviously the lid is open in both cases or else I'd have no way of entering
that command!)

So more like a hal bug or is it just a "acpi doesn't give hal the events it
needs so it can't do the right thing" thing?

Also now in the "it works" mode I do get lid open messages too:
[Fri Mar  3 02:10:55 2006] received event "button/lid LID 00000080 00000001"
[Fri Mar  3 02:10:55 2006] completed event "button/lid LID 00000080 00000001"
[Fri Mar  3 02:10:55 2006] received event "button/lid LID 00000080 00000002"
[Fri Mar  3 02:10:55 2006] completed event "button/lid LID 00000080 00000002"

weird.

Comment 2 Richard Hughes 2006-03-03 04:26:04 EST
Sounds weird, but this isn't a g-p-m bug. If you do lshal -m, and close and open
the lid a few times, you'll see what information is reported to g-p-m -- which
if incorrect, will cause g-p-m to do unexpected things. It might be worth
disabling HAL and g-p-m, and seeing if you can narrow down the problem with acpi.
You say it worked okay a while back, I would try an older kernel and see if that
helps acpi "do the right thing".
Comment 3 Thomas J. Baker 2006-03-09 18:45:56 EST
I just had a similiar problem after removing the power on a Dell 600m. Because I
hadn't tried it in a while, last night I had hibernated it and later resumed it.
After that, gnome-power-manager wouldn't dim the screen and then when I
unplugged it just now, it went back into hibernate mode. It resumed fine and
g-p-m seems to have a handle on the state of things.
Comment 4 Thomas J. Baker 2006-03-09 18:47:53 EST
I meant to add that it could be related to the kernel error I reported in bug
#184027.
Comment 5 Thomas J. Baker 2006-03-12 09:06:40 EST
I just had another related problem. Last night I suspended my laptop with the
power cord plugged in. This morning I unplugged it, walked into the living room,
turned it back on, and just after it had returned to life, it went into
hibernate mode. I only have hibernate as an option if the power is critical on
battery and that should was not the case. One aside question. Is there any
hibernate menu item hidden somewhere that I'm not aware of? There doesn't seem
to be any place to just say hibernate now. 
Comment 6 Richard Hughes 2006-03-12 09:26:30 EST
g-p-m and dbus had a problem with PropertyModified events not being seen by
g-p-m. Does this problem go away if you upgrade to g-p-m 2.13.93 and dbus 0.61?
Comment 7 Thomas J. Baker 2006-03-12 11:55:14 EST
I'm running current rawhide so I already have those.

continuity> rpm -q dbus gnome-power-manager
dbus-0.61-3
gnome-power-manager-2.13.93-4
continuity>
Comment 8 Paul W. Frields 2006-03-12 19:40:48 EST
The bug in comment #1 is occurring for me as well.  Rawhide current as of 2330
UTC today, on a IBM ThinkPad T43.  Details:

gnome-power-manager-2.13.93-4
dbus-0.61-3
acpid-1.0.4-2
kernel-2.6.15-1.2041_FC5
Comment 9 Austin Jackson 2006-03-26 20:23:38 EST
I can confirm this but on a Dell Latitude X1 and the 2.14.0 release of g-p-m. 
The bug only appears after suspending the computer at least once.  It does not
occur when unplugging from a fresh boot.
Comment 10 Thomas J. Baker 2006-03-26 20:43:45 EST
Should I create an FC5 bug on this? It is a truly annoying bug and limits the
usefulness of hibernation. 
Comment 11 Austin Jackson 2006-03-26 20:59:10 EST
Comment # 9 was a report for FC5.
Comment 12 cam 2006-03-27 05:41:53 EST
I can confirm that this happens with recent FC5 software (and happened for late
FC5t3) on a Dell Inspiron 6000.

Removal of power triggers suspend.

In addition, when resuming, and the power has been (and remains) removed whilst
in suspend, the machine will resume and immediately re-suspend.

Comment 13 Richard Hughes 2006-03-27 05:46:51 EST
cam, is your lid value incorrect on resume too?
Comment 14 Pekka Pietikäinen 2006-03-27 10:28:28 EST
gnome-power-manager is probably the wrong component (kernel or hal more like
it), as it's getting wrong information from somewhere about the lid state. Most
g-p-m could do to work around this is some sort of sanity checking.

Since this seems to have made the "most nasty open FC5 bugs" list, I've changed
this to FC5 and moved this to hal. Could still be the kernel, but hal is the one
giving g-p-m false information, so let's blame that ;)

If someone is here just for a quick workaround that lets them use their laptop, 
killall gnome-power-manager and run pm-suspend when you want to suspend. That's
what I've had to resort to :-(

I can't remember if suspend even worked "just right". At one point it was
otherwise perfect, except closing the lid when the AC was on didn't suspend,
even after the AC was removed (rationale being that one doesn't need to suspend
when you're on AC even if you do close the lid). Now it's configurable, but we
have this "getting confused about lid state" problem instead.

Interestingly enough, I wasn't able to recreate the problem with just lshal -m
and pm-suspending and playing around with the lid button...
Comment 15 Richard Hughes 2006-03-27 11:28:48 EST
As a temporary solution, just set your "Actions" to be "Do nothing" for all
states (on battery and lid closed and open) and then at least g-p-m won't do bad
things when it shouldn't.

The real issue here is the brokenness and non-standard nature of ACPI
implimentations, so your patience here is appreciated. Just so we all know
what's going on, can you please...

Shutdown your machine, and turn it off.
Turn it on, login, and do (as root):
# hal-get-property --udi /org/freedesktop/Hal/devices/acpi_LID --key
button.state.value (should be true)
# cat /proc/acpi/button/*/*/* |grep state (should be open)

Then shut the lid, and wait a few seconds, and then re-open the lid.
Then do:

# hal-get-property --udi /org/freedesktop/Hal/devices/acpi_LID --key
button.state.value (should be true)
# cat /proc/acpi/button/*/*/* |grep state (should be open)

Then suspend the computer, wait a few seconds, resume then do:

# hal-get-property --udi /org/freedesktop/Hal/devices/acpi_LID --key
button.state.value (should be true)
# cat /proc/acpi/button/*/*/* |grep state (should be open)

Then shut the lid, wait a few seconds, open it and then do:

# hal-get-property --udi /org/freedesktop/Hal/devices/acpi_LID --key
button.state.value (should be true)
# cat /proc/acpi/button/*/*/* |grep state (should be open)

(spotting a pattern? :-)

Can you please attach your machine type and data. In my case I would write:

Toshiba Satellite Pro A10
true, open
true, open
true, open
true, open

Thanks for you help guys.

Richard.
Comment 16 Austin Jackson 2006-03-27 12:43:30 EST
Dell Latitude X1
false, open
true, open
true, open
true, open

Of additional note, bug 186331 may also be related to this.  The lid state
appears to be getting lost when there is a change in power source.  For example,
under 186331, I get an extra suspend following resume ONLY when putting the
computer to sleep plugged in (by closing the lid), then resuming at a later time
with the X1 unplugged (by opening the lid).  This does not occur for me when
suspending/resuming, under the same conditions, without opening/closing the lid.
Comment 17 cam 2006-03-27 15:19:53 EST
I followed Richard's instructions:

Dell Inspiron 6000
false,open
false,open
false,open
false,open

If I kill g-p-m and do lshal -m I get sets of:

acpi_LID property button.state.value = true
acpi_LID condition ButtonPressed = lid
acpi_LID property button.state.value = false
acpi_LID condition ButtonPressed = lid

perhaps hal is in a race condition reading the lid state vs. getting a lid event.

FYI when I remove the power cord this is the output of lshal -m:

acpi_BAT0 property battery.voltage.current = 12546 (0x3102)
acpi_AC property ac_adapter.present = false
acpi_BAT0 property battery.charge_level.percentage = 98 (0x62)
acpi_BAT0 property battery.charge_level.rate = 11100 (0x2b5c)
acpi_BAT0 property battery.charge_level.current = 49062000 (0x2eca070)
acpi_BAT0 property battery.reporting.current = 4420 (0x1144)
acpi_BAT0 property battery.rechargeable.is_discharging = true


Comment 18 Richard Hughes 2006-03-27 16:55:48 EST
Created attachment 126855 [details]
patch to make HAL scripts refresh on resume

Guys this patch might fix a lot of the problems you are having. To apply it,
save the patch into /tmp, then "su -l", "cd /", "patch -p0 <
/tmp/hal-refresh-on-resume.patch" and then try to suspend and resume. If it
works, then I'll get something similar to this in CVS HAL. Thanks.
Comment 19 Vikram Noel Ambrose 2006-03-27 19:07:12 EST
Same issue with MSI-510x laptop.
System suspends to ram, when power plug is pulled.
Nevertheless system does turn back on without power cable.
 /sbin/lspci
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 21)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 21)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI
Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge
(rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97
Modem Controller (rev 03)
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon
9600 M10]
02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
02:04.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ac)
02:04.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 04)
02:09.0 Network controller: Intel Corporation PRO/Wireless 2200BG (rev 05)
Comment 20 Pekka Pietikäinen 2006-03-28 05:10:03 EST
Thinkpad X31,

false, open
false, open
false, open
false, open 
Comment 21 Pekka Pietikäinen 2006-03-29 06:50:03 EST
Also tried the patch attached, and that didn't help. Well, can't see how it could 
if the logic is "acpi lid button pressed == lid is open", which obviously isn't
the case on all laptops.

So there should be some mechanism in hal/g-p-m to figure out whether 
the lid button being pressed means the lid is open or closed, right?
Comment 22 cam 2006-03-29 15:13:11 EST
The patch in comment #18 didn't have the desired effect.

It did stop the machine from suspending when the power is unplugged, however it
stopped suspending when the lid was closed too.

It did lock the screen as a side effect of the lid closing.

Strange.
Comment 23 Rod Nayfield 2006-04-11 18:33:00 EDT
*** Bug 186331 has been marked as a duplicate of this bug. ***
Comment 24 Richard Hughes 2006-04-24 14:01:40 EDT
I've fixed the hal side of the problem:

See the first entry here: http://live.gnome.org/GnomePowerManager/Faq
Comment 25 Richard Hughes 2006-05-05 03:23:42 EDT
A new g-p-m and HAL have been pushed out to updates yesterday which should fix
the problems. Can people confirm pls?
Comment 26 Rod Nayfield 2006-05-05 08:51:12 EDT
The new updates did not fix the problem on my Thinkpad T41.

I pulled hal-0.5.7-3.fc5.1 and g-p-m 2.14.3-1 from updates/testing before it was
pushed, a while back.  

I reproduced this AM - rebooted (on ac).  Shut lid (suspend), removed ac, opened
lid (resume).  Don't touch the keyboard.

After several seconds (for g-p-m to wake up) the system suspends again.  

Comment 27 Thomas M Steenholdt 2006-05-05 08:57:34 EDT
I'm seing the same thing, this appears to me a sligh morph of the original
problem that's gone at least on my system... removing AC (after the lid has been
closed, system suspended and lid reopen/system resumed) no longer causes the
system to suspend.

But closing the lid while on AC, letting the system suspend, remove AC and
opening lid for system to resume (as Rod points out - wait a while, 30 secs
perhaps more?) and the system suspends again.

I have not yet worked out the exact details on when it happens, but this is how
it "feels"
Comment 28 Thomas M Steenholdt 2006-05-05 09:08:03 EDT
Actually, although i've seen the problem Rod describes several times, i can't
seem to provoke it for logging purposes... I need to figure out the exact order
of things that causes it.
Comment 29 Rod Nayfield 2006-05-05 09:36:15 EDT
This is true - with very limited testing, it looks like one part of the problem
is solved.  That problem was the "system suspends when unplugging AC adapter"
issue.    I can pull AC right now and the system does not suspend.  (disclaimer
- I don't actually do this often.  I generally suspend before unplugging)


However, the "system re-suspends after resume without AC" issue still exists. 
Right now:

hal lid button.state.value is "false"
/proc/acpi/button/lid/LID/state is "open"

So if I read this correctly, the problem is that hal and acpi don't agree.  

Richard, let me know what data you'd like.  I will go collect the info from #15

Comment 30 Rod Nayfield 2006-05-05 10:01:41 EDT
Here is the sequence of hal events (I stripped out all the BAT0 messages)

acpi_LID property button.state.value = true
acpi_LID condition ButtonPressed = lid
acpi_AC property ac_adapter.present = false
acpi_LID property button.state.value = false
acpi_AC property ac_adapter.present = true

This was a sequence of 
1. start lshal -m
2. close lid, suspend, remove power
3. open lid, resume
4. g-p-m suspends automagically when it wakes up - bug!
5. open lid, resume, get log ;)

Between 3 and 4, hal/acpi are "false, open" which seems to be correct (ignore my
last comment).  I have not seen anything but false,open on this system (running
the latest hal).  

Too bad lshal -m doesn't timestamp - i will try again to make sure I know which
messages came from which events.
Comment 31 Rod Nayfield 2006-05-05 10:14:03 EDT
1. start lshal -m
2. close lid, suspend, remove power
3. open lid, resume, look at lshal output:

acpi_LID property button.state.value = true
acpi_LID condition ButtonPressed = lid
acpi_AC property ac_adapter.present = false
acpi_LID property button.state.value = false

4. bug. machine suspends.
5. open lid, resume, look for more messages

Note that after step 3 there are no additional hal messages besides battery values.

I did notice that at step 3, my window of opportunity, that g-p-m does not have
an icon in the panel.  It is just a blank grey area.  At step 5, g-p-m
immediately is there on resume with the on-bat-power state icon.




Comment 32 Richard Hughes 2006-05-14 12:14:44 EDT
> 4. bug. machine suspends.
> 5. open lid, resume, look for more messages
> 
> Note that after step 3 there are no additional hal messages besides battery
values.

Hmm. Do you ever get acpi messages about the lid after a suspend?

Richard.
Comment 33 Rod Nayfield 2006-05-15 10:21:30 EDT
After resuming, I get messages like:

May 15 09:01:33 localhost kernel: ACPI: Power Button (FF) [PWRF]
May 15 09:01:33 localhost kernel: ACPI: Lid Switch [LID]
May 15 09:01:33 localhost kernel: ACPI: Sleep Button (CM) [SLPB]
[...]
May 15 09:01:53 localhost gnome-power-manager: Suspending computer because the
lid has been closed, and the ac adapter removed

Comment 34 James 2006-06-19 19:12:10 EDT
This problem is familiar:

Mitac 8011;
false open,
false open,
false open,
false open.

gnome-power-manager 2.14.3-1
hal 0.5.7-3.fc5.2

Sometimes I have to open and close the lid twice to get it to suspend.
Sometimes, when it suspends, it resumes and then suspends again shortly
afterwards. Occasionally it pops up a "Suspend problem" bubble.
Comment 35 Austin Jackson 2006-11-14 19:58:18 EST
This appears to be fixed in fc6
Comment 36 Paul W. Frields 2006-11-14 20:04:55 EST
WORKSFORME on a T43 and a T60p.
Comment 37 Pekka Pietikäinen 2006-11-15 03:25:33 EST
Yes it indeed got fixed at some point -> closing :)
Comment 38 James 2006-12-01 13:22:30 EST
I hate to be the troublemaker... but it's still broken for me. It still only
suspends for me on every other closure of the lid. It seems acpid picks up the
lid event no problem, but not gpm. gpm does, however, notice that the lid has
been opened and turns the light back on.

gnome-power-manager-2.16.0-4.fc6
hal-0.5.8.1-5.fc6

This was an upgrade from FC5... could there be some tweaking I have to do?
Comment 39 James 2006-12-01 13:39:19 EST
Actually forget that last comment... seems for me this is an ACPI subsystem problem:

$ cat /proc/acpi/button/lid/LID/state 
state:      closed

with the lid open...
Comment 40 Richard Hughes 2006-12-09 14:42:45 EST
Yes, this is an ACPI problem. I suggest you bring up the issue on acpi-devel
mailing list. Many thanks.

Note You need to log in before you can comment on or make changes to this bug.