GNOME Bugzilla – Bug 334220
gpm suspends my machine when the AC is unplugged
Last modified: 2006-04-24 18:58:24 UTC
Please describe the problem: I think this is related to bug 332566 I am using the 2.13.93 version I use my laptop normaly, it suspend when I close the lid and resumes well... But, if i let it charging, and wait until it is fully charged, when i unplug it lots of times the notebook suspends!!!! Steps to reproduce: 1. With some of the battery put it to charge 2. wait until battery is fully recharged 3. unplug the cable Actual results: the notebook goes to sleep Expected results: I expect to stay awake Does this happen every time? almost Other information: do you need some kind of log???
What does (as root) cat /var/log/messages | grep gnome-power say?
I tried it but there were nothing in /var/log/messages with gnome-power !!! Do you need a lshal or gpm --no-daemon maybe?
Whenever g-p-m does an action, it should be logged in /var/log/messages: Mar 11 15:05:55 localhost gnome-power-manager: Shutting down computer because the power button has been pressed If you've got a verbose trace when it suspends wrongly, then that will do just fine.
Created attachment 61188 [details] The output of gpm with --verbos --no-daemon This is the output of --verbose --no daemon 1- Cable was unplugged 2- I plugged the cable 3- I unplugged the cable 4- GPM suspended the notebook 5- resumed notebook I hope it is usefull
Created attachment 61189 [details] the output of lshal -m The output from lshal for above entry
>Saving to syslog: Suspending computer because the lid has been closed, and the >ac adapter removed Is your laptop lid closed when you remove the AC? Richard.
I think not.. Today i didnt had the problem then i unpluged the AC, then suspended de MAchine and plug the cable.. from that moment every time i unplug the cable it suspends the machine
When i unplug the cable my lid is open... sometimes i am working and hit the plug int the wall with my feet... and my notebook suspends.. really anoying..
You could try disabling suspend for laptop lid close... but the real question is why your laptop thinks the lid is closed when it's not. Can you try and do lshal |grep "state.value" and try to get this value wrong?
I have been having the same issue. When I unplug the ac power cord I get the message Mar 21 11:00:13 trillian gnome-power-manager: Hibernating computer because the lid has been closed, and the ac adapter removed However the lid is open and battery fully charged. I was able to fix the issue by unchecking the use_time_for_policy box using gconf (under Apps/gnome-power-manager) and logging out and back in I am on a Dell Latitude D600
This happens to me with an ASUS V6800V. I think it may be caused by the fact that the lid is actually never really re-opened. Closing the lid generates an acpi event, hence the succesfull sleeping. But re-opening it doesn't. I need to press the power button te wake it up. Maybe, somehow, the acpi system considers that the lid is still closed. Then, unplugging the AC adapter generates an event, acpid thinks about what to do, and realizes that the lid is closed. Boom... We're sleeping. Very annoying. Of course, I know nothing about all this, so maybe I don't make sense. Anyway, just a 'me too' :(
>Then, unplugging the AC adapter generates an >event, acpid thinks about what to do, and realizes that the lid is closed. >Boom... We're sleeping. That seems very likely. I'm not sure how to fix this properly as it seems very tied into the hardware. Does Windows XP detect the lid is opened and closed correctly? Richard.
I dont have winxp to try which log should i look to see acpi events???? /var/log/acpid? This is what i see in /var/log/acpid. I suspended and resumed. But the error is not happening just now [Tue Mar 21 15:03:29 2006] received event "button/lid LID0 00000080 00000003" [Tue Mar 21 15:03:29 2006] notifying client 6109[105:105] [Tue Mar 21 15:03:29 2006] notifying client 6429[0:0] [Tue Mar 21 15:03:29 2006] completed event "button/lid LID0 00000080 00000003" [Tue Mar 21 15:03:35 2006] received event "battery BAT0 00000081 00000001" [Tue Mar 21 15:03:35 2006] notifying client 6109[105:105] [Tue Mar 21 15:03:35 2006] notifying client 6429[0:0] [Tue Mar 21 15:03:35 2006] completed event "battery BAT0 00000081 00000001" [Tue Mar 21 15:03:35 2006] client connected from 6429[0:0] [Tue Mar 21 15:03:35 2006] 1 client rule loaded When the error happens again i'll look the log again
(In reply to comment #12) > >Then, unplugging the AC adapter generates an > >event, acpid thinks about what to do, and realizes that the lid is closed. > >Boom... We're sleeping. > > That seems very likely. I'm not sure how to fix this properly as it seems very > tied into the hardware. Does Windows XP detect the lid is opened and closed > correctly? > > Richard. > I will try to find a spare hard drive to try XP on it and see. I did a little more research and found some bizare things. Just after a fresh boot, the 'state.value' for the LID is set to false (from lshal). I close the lid, the laptop sleeps fine, then I wake it up. 'state.value' is now set to true, no matter what. I tried setting it back to 'false' using the hal-set-property command. It actually makes lshal return 'state.value = false' for the LID, but the same behaviour still happens (sleep on AC unplug). Also, I noticed that the /proc/acpi info on the LID is correct. It always says 'open'. Maybe you can use that in some way to work around this issue? Or maybe this is something for the HAL guys? The last thing I noticed is that after restarting the X session (by Ctrl+Alt+Backspace) or even after a simple logout / log-back-in, I can unplug the AC without having the computer sleep. (button.state.value still is 'true' for the lid, and /proc/acpi/xxxxxxxx still says it's 'open'). I'm very affraid of not being clear enough as I'm not used to hal and acpi at all. Tell me whatever you'd like me to check, and I will. gnome-powermanager is just like networkmanager : a little tiny icon in our gnome-panel that will change the world, soon enough :) Keep it up!
Just a quick note that if the close-lid action is set to 'blank-screen', then the LID works as expected, that is it does generate two events (it says 'condition') ButtonPressed = lid (from lshal -m). Closing it sets state.value to true, re-opening it sets it back to false. After that, unplugging the AC doesn't trigger the 'close-lid + on-battery' event, since HAL/GPM really know that the LID is open there. If the 'close-lid + AC' is set to sleep, the second 'ButtonPressed = lid' never happens (since opening the lid doesnt trigger the wake-up), hence HAL/GPM never ever realizes that the lid is not closed anymore, despite the acpi subsystem (see /proc/acpi/button/lid/LID/state) being fully aware of the correct lid state. It could maybe help if GPM or maybe HAL would verify its idea of the state of the lid on wake up? At least make sure it is synchronized with what the acpi subsystem knows?
>hence HAL/GPM never ever realizes that the lid is not closed anymore Corrent. >It could maybe help if GPM or maybe HAL would verify its idea of the state >of the lid on wake up? So if you suspend, then resume, then: lshal |grep button.state cat /proc/acpi/button/lid/LID/state the two disagree? Oh I love ACPI. Wat we need is a way for the hal-system-power-suspend script to trigger a global refresh of the lid event in HAL, which I'm pretty sure can be done in libhal. There may be an easier way. Can someone send a mail to hal devel (I'm really busy this week) expaining the situation, and asking how the best way is to refresh the lid state from the script file. Thanks.
great!!! Could you send the mail Dandelion? My english is not enough to explain the problem in a coherent way :D alejo
I've fixed this in HAL HEAD. Can someone try that please?
Hello Richard. I want to try it... but i dont want to mess my system instaling HAL from source... do you think is a lot of time until the next release????? wich version it will be?? alejo
Don't blame you. I hack on HAL lots, and it was a real pain for me to install the latest CVS HEAD! If you can try the patch here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187396#c10 and if that doesn't work, can you try the patch also using g-p-m HEAD, as there have been lots of fixes there. Thanks.
Hi richard. I tried to use CVS HEAD from gpm. checked out from cvs, then make, make install But when i ran gnome-power-manager a alert window poped out telling me "can't find glade file" and the segfaulted (i tried both, plain make;make install AND the debian way of packages) Could it be only bad luck in cvs and better try tomorrow???? thanks
>Could it be only bad luck in cvs and better try tomorrow???? Seems to work for me, but then I am a moron: feedback->priv->xml = glade_xml_new ("/home/hughsie/gnome-power-manager/data/gpm-feedback-widget.glade", NULL, NULL); And I'm guessing for you that file does not exist... :-) I've committed a fix: 2006-04-03 Richard Hughes <richard@hughsie.com> * src/gpm-feedback-widget.c (gpm_feedback_init): Not everybody installs the glade file to /home/hughsie.... so don't hardcode this. Ugh. Found by Alejandro Vera, many thanks. So now it should work for you. Apologies. Richard.
Don't worry. Using it now :D... So far so good :D
I have the hal patch, and compiled gpm CVS (version 1.497). No joy for me :( After resuming, hal still ends up in a confused state and pulling the AC sends it into hibernate again. For some reason, the rescan patch does not reset hal's button state on my system. A full hal restart does the job though. Thanks for the work...
>I have the hal patch... Can you try adding a two second sleep before we do the rescan in the scripts please, and see what that does. Thanks.
The 2 second sleep didn't help. The good news is I installed hal from cvs, which helped a lot. Before that I had been using the fc5 package hal-0.5.7-3. Here is what I am currently seeing. The lid state is still getting confused. However now when I disconnect AC (when the lid is confused) gpm flashes up an error message saying "Hibernate Problem!" and eventually flashes up the correct message saying "Power Information...." In /var/log/messages I still see the anomalous Apr 8 09:33:58 trillian gnome-power-manager: Hibernating computer because the lid has been closed, and the ac adapter removed But now the system does not go into hibernate when AC is removed. When I close the lid, the system does correctly go into hibernate, so aside from the anomalous error messages, and lid state, things are working for all practical purposes. Some other minor weirdness: using gconf I unchecked "lock_on_hibernate" and "lock_use_screensaver_settings". Otherwise gpm would lock the screen when removing AC, even though I don't have lock set under gnome-screensaver.
I get the same problem here, using the FC5 hal (0.5.7-3). However, it really does not look like a hal problem to me. lshal shows the valid lid state all the times on my machine. The state change just doesn't happen because the computer is basically powered off at the time the event occurs. Is this a bug in hal or is it really working like it's supposed to? Perhaps if g-p-m would check the real hal lid value before suspending (i have no idea what the overhead of this might be), it would start working correctly. Or simply reinitialize the local variables from hal upon resume from whatever sleep state. However, if the general oppinion is that HAL should send these events, even for things that happen while the system is basically shut down, then i guess HAL is the faulty one.
I see now that hal really isn't able to figure out the lid state after resume... so this is definately not a gnome-power-manager bug IMHO...
Indeed. I'll try issuing a Rescan in g-p-m when we resume, but this isn't trivial to impliment, and it might not work.
I guess, since this is clearly a bug in hal rather than g-p-m, i'd like it fixed in hal rather than worked around in g-p-m... Also, since the value seems stuck in hal, the only way to work around it would be to re-read the /proc/acpi/.../LID/state file, which seems like a bad solution???
I see the same problem on my VAIO, which I wake up using the keyboard, and thus doesn't get the "re-open" LID event. I guess this would happen with quite a few laptops.
Bastien, What's the value of lshal |grep button.state.value on resume? Does it change if you do; devices=`hal-find-by-capability --capability button` for device in $devices do dbus-send --system --dest=org.freedesktop.Hal \ $device org.freedesktop.Hal.Device.Rescan done Thanks.
-(~)-> lshal |grep button.state.value button.state.value = true (bool) -(~)-> devices=`hal-find-by-capability --capability button` -(~)-> for device in $devices - do - dbus-send --system --dest=org.freedesktop.Hal \ - $device org.freedesktop.Hal.Device.Rescan - done -(~)-> lshal |grep button.state.value button.state.value = true (bool) -(~)-> echo $devices /org/freedesktop/Hal/devices/acpi_PWRB /org/freedesktop/Hal/devices/acpi_LID0 /org/freedesktop/Hal/devices/platform_i8042_i8042_Kbd_Port_logicaldev_input
This is using: gnome-power-manager-2.14.1-1 hal-0.5.7-3 (latest in FC5)
$ cat /proc/acpi/button/lid/LID0/state state: open That's right though. I'm not sure whether my version of hal has the "rescan" function for the buttons though.
ALL: I think I've fixed the problem -- please see the first entry in http://live.gnome.org/GnomePowerManager/Faq on how to fix the Rescan of the lid value.
$ lshal |grep button.state.value button.state.value = false (bool) The value is correct (hmm, is it true when opened, or closed?), but I'm still getting the same behaviour. Apr 24 18:15:17 randel gnome-power-manager: Suspending computer because the lid has been closed, and the ac adapter removed
Bastien, can you try the fix suggested in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187396 pls. Thanks.
Yep, fixes it for me.
Thanks Bastien. 2006-04-24 Richard Hughes <richard@hughsie.com> * src/gpm-manager.c (power_on_ac_changed_cb): Fix an operator precedence problem where the logic was all messed up. This was triggering the not-on-ac lid-closed behavior and causing seemingly random suspends. Big thanks to Koichi Takahashi for spotting the problem. Committed to HEAD and 2-14. I'll release 2.14.2 today as well.