Feisty HAL upgrade broke suspend on lid close

[Tim Holy]

Binary package hint: hal

I have a IBM T60 laptop running Kubuntu feisty. Before the recent hal upgrade (2007-05-11), the laptop suspended correctly when the lid was closed. Now (with version 0.5.9 of hald) the system does not go to sleep when the lid is closed.

It does not matter if running with AC power or batteries. Suspend-to-RAM does work if I manually right-click on the KDE powermanager icon. If I do
      cat /proc/acpi/button/lid/LID/state
I correctly get
     state: open
and if I do
     sleep 5; cat /proc/acpi/button/lid/LID/state
and close the lid in those 5 seconds I correctly get
     state: closed

Yet, the laptop doesn't suspend even though it knows the lid is closed. I tried re-setting the KDE powermanager to suspend on lid closed, but this did not alter the behavior.

[Tim Holy (holy-wustl)]

More information: on a reboot, the suspend on lid close works the _first_ time. But if you close the lid, wait, let it wake up, wait, and then close the lid again, it doesn't sleep.

Now I'm not sure about my assignment of this as a HAL problem, though: I did a dbus restart, which stops HAL and brings it back up again. Aside from it complaining that the battery has been removed (it hadn't), this didn't change things---suspend still failed on closing the lid.

Kernel version:
tim@diva:/etc/init.d$ uname -a
Linux diva 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

[Olivier (olivier-lacroix)]

Hi

Same problem here with an up-to-date feisty.
I i try to suspend closing the lid, nothing happen. I can suspend via guidance-power-manager and by hitting the "suspend-key".

by the way, if I suspend via one of the successful way after an unsuccessful lid-closing attempt, on resume, the system suspend another time : the first suspend command seems to be recorded, and a service may be blocking it to succeed. after this double suspend thing, the systems fails to resume properly and I have to do a hard-reboot.

If you need any debugging output, I will be glad to help.

Olivier

[Olivier (olivier-lacroix)]

may be the same bug as

https://bugs.launchpad.net/ubuntu/+source/hal/+bug/114507

[su99 (samsonsu)]

I met the same problem on all my 3 laptops: IBM Thinkpad T42, an old Thinkpad 600E (acpi=force), and Dell inspiron 710m. All were installed with ubuntu 7.04 release dvd on 4/19.

All 3 laptops can successfully suspend upon lid close before 5/11 hal update. However, since installing that update, now i have a very high failure rate (1 out of 3-5 attempts to close the lid) and the laptop keeps running after lid closes. I have to open&close the lid one more time and it then suspends correctly. This might be slightly different than what others experienced on their laptops: looks like some totally failed to suspend upon lid close, while my laptops always succeed on a 2nd attempt if the 1st one fails.

Haven't figured out any pattern when the failure will happen. My feeling is that it is easier to reproduce if I close the lid after using the laptop for a long time (1 hour, for example). When you try to reproduce it purposefully and open/close lid frequently, it hardly happens again.

I've posted the issue on forum: http://ubuntuforums.org/showthread.php?p=2656972 . Feel free to add comments. Thanks.

[aysiu (ubuntubugzilla-psychocats)]

Suspend was working perfectly for me on my Dell Inspiron 500m laptop before the HAL upgrade. Now it suspends "fine" (or seems to), but it cannot resume from suspend.

[emvy (mate-varga)]

Same here. Hardware: IBM T60. Hibernate works, suspend not (since last HAL update).

[whayong (whayong1)]

Same on Sony Vaio PCG-SRX77. Suspend didn't work on Edgy. Feisty fixed it. HAL update broke it again. Is there anyway to revert back prior to the update? Atleast while a fix is being worked on.

[su99 (samsonsu)]

For those who suffer from this issue, try to rollback to the good version using Synaptic Package Manager. Seems to work for me. After rolling back, please remember to ignore the update notifications until we see a fix.

http://ubuntuforums.org/showthread.php?p=2663042#post2663042 , refer to post #10.

[gorkon (gorkon)]

su99's workaround works ok. I have also seen the weirdness with my T60 and suspend only when shutting the lid. I have double checked that I do have Power Management set to suspend when the lid closes. Every second or third closing seems to work, but every once in a while it will not suspend when I close the lid. It will suspend fine if I make it.

Anyway, I hope this gets fixed soon. Here's a snippit of the acpid log:

[Thu May 17 08:09:45 2007] received event "ibm/hotkey HKEY 00000080 00005002"
[Thu May 17 08:09:45 2007] notifying client 5219[0:0]
[Thu May 17 08:09:45 2007] completed event "ibm/hotkey HKEY 00000080 00005002"
[Thu May 17 08:09:45 2007] received event "button/lid LID 00000080 00000002"
[Thu May 17 08:09:45 2007] notifying client 5219[0:0]
[Thu May 17 08:09:45 2007] executing action "/etc/acpi/lid.sh"
[Thu May 17 08:09:45 2007] BEGIN HANDLER MESSAGES
[Thu May 17 08:09:46 2007] END HANDLER MESSAGES
[Thu May 17 08:09:46 2007] action exited with status 0
[Thu May 17 08:09:46 2007] completed event "button/lid LID 00000080 00000002"
[Thu May 17 08:10:54 2007] received event "ibm/hotkey HKEY 00000080 00005001"
[Thu May 17 08:10:54 2007] notifying client 5219[0:0]
[Thu May 17 08:10:54 2007] completed event "ibm/hotkey HKEY 00000080 00005001"
[Thu May 17 08:10:54 2007] received event "button/lid LID 00000080 00000003"
[Thu May 17 08:10:54 2007] notifying client 5219[0:0]
[Thu May 17 08:10:54 2007] executing action "/etc/acpi/lid.sh"
[Thu May 17 08:10:54 2007] BEGIN HANDLER MESSAGES
[Thu May 17 08:10:54 2007] END HANDLER MESSAGES
[Thu May 17 08:10:54 2007] action exited with status 0
[Thu May 17 08:10:54 2007] completed event "button/lid LID 00000080 00000003"
[Thu May 17 08:11:14 2007] received event "processor CPU0 00000081 00000000"
[Thu May 17 08:11:14 2007] notifying client 5219[0:0]
[Thu May 17 08:11:14 2007] client has disconnected
[Thu May 17 08:11:14 2007] completed event "processor CPU0 00000081 00000000"
[Thu May 17 08:11:14 2007] received event "processor CPU1 00000081 00000000"
[Thu May 17 08:11:14 2007] completed event "processor CPU1 00000081 00000000"
[Thu May 17 08:11:18 2007] client connected from 5219[0:0]
[Thu May 17 08:11:18 2007] 1 client rule loaded
[Thu May 17 08:11:54 2007] received event "ibm/hotkey HKEY 00000080 00005001"
[Thu May 17 08:11:54 2007] notifying client 5219[0:0]
[Thu May 17 08:11:54 2007] completed event "ibm/hotkey HKEY 00000080 00005001"
[Thu May 17 08:11:54 2007] received event "button/lid LID 00000080 00000001"
[Thu May 17 08:11:54 2007] notifying client 5219[0:0]
[Thu May 17 08:11:54 2007] executing action "/etc/acpi/lid.sh"
[Thu May 17 08:11:54 2007] BEGIN HANDLER MESSAGES
[Thu May 17 08:11:54 2007] END HANDLER MESSAGES
[Thu May 17 08:11:54 2007] action exited with status 0
[Thu May 17 08:11:54 2007] completed event "button/lid LID 00000080 00000001"
[Thu May 17 08:12:00 2007] received event "ibm/hotkey HKEY 00000080 00005002"
[Thu May 17 08:12:00 2007] notifying client 5219[0:0]
[Thu May 17 08:12:00 2007] completed event "ibm/hotkey HKEY 00000080 00005002"
[Thu May 17 08:12:00 2007] received event "button/lid LID 00000080 00000002"
[Thu May 17 08:12:00 2007] notifying client 5219[0:0]
[...

[dennis (dwavomba)]

If you are using gnome-power-manager, try launching it with
$ gnome-power-manager --no-daemon --verbose
and look for the lid events from that end. What could be happening, like in my case, is the lid open event never gets reported by acpid or hal thus g-p-m always thinks the lid is closed. Therefore, when a subsequent 'Lid Closed' event occurs through acpid/hal, it gets ignored by g-p-m since gpm-button.c ignores duplicate lid events. What I did, is i patched gpm-button.c to allow for duplicate lid events (temporary fix: probably not a good Idea). This fix should be in hal/acpid to emit a 'Lid Open' event. Or, gnome-power-manager should reset the Lid state once we know it is unmistakably open (e.g keyboard/mouse activity).

[Tim Holy (holy-wustl)]

A post by su99 on the forum told me something new: the upgraded hal was in backports, not main. I hadn't even realized I was using the backports repository...

Downgrading as suggested in the form posts (link above) works to fix the problem for me.

[Chris Jones (cmsj)]

I have seen this on two thinkpads (X40 and T41) since the hal update in feisty-backports.

[cement_head (andorjkiss)]

Hello,

  Yes, This has also happened to me on a Dell Inspiron 8100 laptop. This (Suspend) & (Hibernate) are very important features on a laptop. Please address this ASAP. Current workaround is to (from within Synaptic) to FORCE a downgrade and LOCK the old version.

- cement_head

[Chris Boersma (chris-boersma)]

This is also happening to me on Kubuntu Feisty with a Dell 6000d. It's very annoying.

[Matthew McEachen (mrm-ubuntu)]

I'm also experiencing the bug on Feisty on an HP zt3000. This is a pretty severe bug -- if you think your laptop is going to suspend and you put it in your laptop bag, the laptop can roast itself and cause permanent hardware damage before the battery dies.

[gorkon (gorkon)]

Do you have automatix? After you use it, go in and disable backports
with synaptic. The source this hal update is coming from is feisty
backports added by automatix.

On 6/4/07, Matthew McEachen <email address hidden> wrote:
> I'm also experiencing the bug on Feisty on an HP zt3000. This is a
> pretty severe bug -- if you think your laptop is going to suspend and
> you put it in your laptop bag, the laptop can roast itself and cause
> permanent hardware damage before the battery dies.
>
> --
> Feisty HAL upgrade broke suspend on lid close
> https://bugs.launchpad.net/bugs/114595
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Matthew McEachen (mrm-ubuntu)]

No -- but I had enabled backports for a couple other packages. I followed the forum post http://ubuntuforums.org/showpost.php?p=2701612&postcount=26 and downgraded from backports with `sudo apt-get install hal=0.5.8.1-4ubuntu12 libhal-storage1=0.5.8.1-4ubuntu12 libhal1=0.5.8.1-4ubuntu12` and I've successfully bounced in and out of suspend-to-RAM four times now after reboot.

I'm using kpowermanager instead of kde-guidance-power-manager, BTW.

[gorkon (gorkon)]

 gorkon (<email address hidden>) has invited you to
StumbleUpon!

 You can see my other favorites here:
 http://gorkon.stumbleupon.com

 Thanks,
 gorkon

 ---
 StumbleUpon lets you discover great sites with a
single click. Give it a try at:
http://www.stumbleupon.com/join.php?friend=2985929&emailcode=bv46bpnafydjjre1

[Jeremy Cantrell (jmcantrell)]

I'm seeing this same problem with the latest updates from feisty backports. I'm using a Thinkpad T42. I REALLY hope this gets fixed soon. I would just downgrade from the backports version, but there were some issues related to LUKS drives that was fixed in the that version.

[Steinar Bang (sb-dod)]

I see the same symptoms on a Dell Latitude D610 (ATI mobility display chip set, Broadcom WLAN chipset). I reported it as a kernel bug, all details are here: Bug #120670

[Vladimir Prus (vladimir-prus)]

I experience the same on Dell Latitude D620. Suspend by closing the lid works only the first time. However, suspend by right clicking power manager and selecting "Suspend" there works reliably for me. Resume by opening the lid also works reliably.

[raketenman (sesselastronaut)]

I still have the problem downgrading hal - ev'ry 4-5th closing sleep fails. tried a few workarounds but no luck - using 2.6.20-16-lowlatency & generic with corresponding restricted-modules, xorg-driver-fglrx 7.1.0-8.34.8+2.6.20.5-16.29, with kpowersave!
can't wait for the solving of this annoying problem

[Cory Snider (corhere)]

My Acer Travelmate 4002WLMi has the same problem. One interesting note is that today I closed the lid of the computer and it did not go to sleep. I just decided to leave it as-is (awake with lid closed), and came back about an hour later. I then opened the lid and started using the computer. About 15 minutes into using the computer, it decided to suspend!

[Vadim Zeitlin (vz-ubuntu)]

This doesn't work in Gutsy (although it did work in Feisty on the same machine) with HP nw8000 neither. It seems that the new HAL simply doesn't see the lid switch at all, at least it doesn't appear as acpi_C138 device as I'd expect it to (the corresponding ACPI file path is /proc/acpi/button/lid/C138; FWIW acpid notices lid close/open just fine). So nothing happens when the lid is closed and this is a pretty serious bug which is especially jarring because it's a regression compared to Feisty.

[E Thornton (ewthornton)]

Same problem with 7.10 on Dell inspiron 4000. The screen initially blanks for about 1 second, then activates again. If the lid is closed while at the login screen, nothing happens.

I'm sure this feature worked under 7.04. I confirmed the above that /proc/acpi/button/lid/LID/state correctly shows if the lid is open or closed. I've also confirmed that acpi is receiving the lid open/close.

@ubuntu:~$ acpi_listen
button/lid LID 00000080 00000003
video VID 00000080 00000000
button/lid LID 00000080 00000004
video VID 00000080 00000000

Furthermore, running the command below, causes the screen to blank correctly, and stay blanked until mouse or keyboard brings video back.

@ubuntu:/etc/acpi$ /etc/acpi/screenblank.sh

I've tried everything I know to fix this. It's most definitely broken beyond my capabilities.

[Jean-Christophe Baptiste (jc-baptiste)]

Same problem here. The worst is that it already happened to me that I put the laptop in my bag, thinking it was off, and travelled with it for about 40 minutes, on foot and by bike.

So far there is no visible damage, but I guess it shortened somehow the lifetime of the hardware (especially the hard drive).

[Gordon Mckeown (thefluffyone)]

Getting the same problem here on Kubuntu Gutsy on a Dell Latitude D610.

The symptoms I see are that first suspend works, and then none after that work. If I quit the Power Manager app and restart it, I get one suspend and then subsquently suspend doesn't work again.

I'm afraid my Python skills are rather lacking, but I stuffed some debug statements into powermanage.py and discovered that the getLidClosedState() function is failing after the first suspend -- it generates an exception and the code deals with that by always returning "false" (meaning "lid is open"). The specific command that results in the exception is:

properties = self.lidObject.GetAllProperties(dbus_interface="org.freedesktop.Hal.Device")

Looking at the code I think self.lidObject maps directly to a Python library that pulls the data in from HAL, and this fits with the behaviour described above that a HAL update introduced the problem.

As a workaround, I imagine the getLidClosedState() function could be amended to read the content of /proc/acpi/button/lid/*/state instead of getting the information from HAL.

[Gordon Mckeown (thefluffyone)]

After knocking up a very dodgy patch to getLidClosedState() I stumbled across another bug in Launchpad that describes what appears to be a proper fix:

https://bugs.launchpad.net/bugs/151648

[Gordon Mckeown (thefluffyone)]

 Stijn Vansummeren wrote on 2008-01-25:
> (It is possible that this bug has already been fixed in the current development
> version of kde-guidance. I have been unable to find where to get the development
> version, however.)

Assuming I have the right location for the current KDE3/KDE4 development of kde-guidance:

http://websvn.kde.org/trunk/extragear/utils/guidance/powermanager/powermanage.py?view=log
http://websvn.kde.org/branches/extragear/kde3/utils/guidance/powermanager/powermanage.py?view=log

Doesn't appear to be fixed in either of these.

[Jean-Christophe Baptiste (jc-baptiste)]

Many users have the problem under Gnome, so why would it be KDE specific ?
Isn't the problem in Hal itself ?

[Stijn Vansummeren (stijn.vansummeren)]

My fix for Kubuntu Guidance was based on the following observations. I am not familiar with the way HAL is *supposed* to work, so I don't know whether this constitutes a bug in HAL.

The problem lies in the following section of /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux:

#Refresh devices as a resume can do funny things
for type in button battery ac_adapter
do
        devices=`hal-find-by-capability --capability $type`
        for device in $devices
        do
                dbus-send --system --print-reply --dest=org.freedesktop.Hal \
                          $device org.freedesktop.Hal.Device.Rescan
        done
done

After a resume HAL hence re-inserts all button objects. These button objects are not necessarily re-inserted in the same order that they were in before resuming however. As such, the lid object can be "/org/freedesktop/Hal/devices/computer_logicaldev_input_0" before resume but "/org/freedesktop/Hal/devices/computer_logicaldev_input_2" after. In short, all references to the lid object kept by Guidance Powermanager or Gnome powermanager (if it keeps them) become invalid after resume.

You can easily check this as follows: execute `hal-find-by-property --key button.type --string lid` before resume and after resume. They are likely to be different (if they're not, closing the lid should allow your laptop to sleep).

[Gordon Mckeown (thefluffyone)]

Have been running Stijn's patch for the last 24 hours and every suspend/resume has worked perfectly so far.

There still remains the question of whether this is a bug in HAL or in the power manager, but for the time being the "fix" to the power manager is working well for me :)

[Giorgos Kylafas (gekylafas)]

Stijn's patch works here as well. Thank you, man!

[Yuriy Kozlov (yuriy-kozlov)]

Adding tasks for kde-guidance and gnome-power-manager and attaching Stijn's patch from bug 151648.

[Rolf Leggewie (r0lf)]

Is this a problem in a release past feisty?

[cement_head (andorjkiss)]

Gutsy & Hardy are OKAY - no problems here.

[Tim Holy (holy-wustl)]

No, it's working perfectly now. Thanks for following up.
--Tim

On Monday 23 February 2009 04:49:30 pm Rolf Leggewie wrote:
> Is this a problem in a release past feisty?
>
> ** Changed in: hal (Ubuntu)
> Assignee: (unassigned) => Rolf Leggewie (r0lf)
> Status: Confirmed => Incomplete

[Rolf Leggewie (r0lf)]

Tim, thank you for reporting back. Closing as fix released.

Yuriy, please open a new report if you think your patch should still be applied to Ubuntu Jaunty in the packages you indicated.