Bug 183709

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.

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".

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.

I meant to add that it could be related to the kernel error I reported in bug
#184027.

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. 

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?

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>

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

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.

Should I create an FC5 bug on this? It is a truly annoying bug and limits the
usefulness of hibernation. 

Comment # 9 was a report for FC5.

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.

cam, is your lid value incorrect on resume too?

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...

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.

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.

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

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.

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)

Thinkpad X31,

false, open
false, open
false, open
false, open 

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?

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.

*** Bug 186331 has been marked as a duplicate of this bug. ***

I've fixed the hal side of the problem:

See the first entry here: http://live.gnome.org/GnomePowerManager/Faq

A new g-p-m and HAL have been pushed out to updates yesterday which should fix
the problems. Can people confirm pls?

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.  

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"

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.

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

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.

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.

> 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.

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

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.

This appears to be fixed in fc6

WORKSFORME on a T43 and a T60p.

Yes it indeed got fixed at some point -> closing :)

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?

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...

Yes, this is an ACPI problem. I suggest you bring up the issue on acpi-devel
mailing list. Many thanks.