Ubuntu

Suspends that are longer than 6 hours will inexplicably claim to fail, but not really fail

Reported by Mario Limonciello on 2008-06-24
86
This bug affects 6 people
Affects Status Importance Assigned to Milestone
gnome-power
Fix Released
Medium
gnome-power-manager (Ubuntu)
Low
Ted Gould
Hardy
Low
Mario Limonciello

Bug Description

Binary package hint: gnome-power-manager

The bug is present in both Ubuntu 8.04 and Ubuntu 8.10
(GPM 2.23.1-0ubuntu1 in 8.10 and 2.22.1-1ubuntu4 in 8.04)

Currently, g-p-m will make a series of annoying beeps in the event of a 'failed' suspend. Unfortunately, a 'failed' suspend just means that it failed 'one' of the times on the way down or on the way up. It will continue to try until it actually makes it down or up.

Addressing bug:
This is typically caused by a suspend longer than 6 hours, because dbus will time out the connection after 6 hours. I've supplied a fix to upstream gnome which as been added to their tree to resolve the issue.

Impact:
This bug is cosmetic (per say, since it's an audible sound), but can get rather annoying.

Test Case:
1) Ensure audio is working
2) Ensure that the checkbox to play a noise in the event of an error is checked
3) Suspend a machine that is known to suspend OK for short periods of time for > 6 hours
4) Listen for a series of annoying beeps

Regression Potential:
This code path is only used when suspending > 6 hours. There shouldn't be any regression potential.

Bill Filler (bfiller) wrote :

fyi, the gconf key for this setting in gnome-power-manager is:
/apps/gnome-power-manager/ui/enable_sound

description: updated
Sebastien Bacher (seb128) wrote :

confirmed, ted do you think the default value should be changed?

Changed in gnome-power-manager:
assignee: nobody → ted-gould
importance: Undecided → Low
status: New → Confirmed
description: updated
Sebastien Bacher (seb128) wrote :

would be something to evaluate as an hardy update too

Changed in gnome-power-manager:
assignee: nobody → ted-gould
importance: Undecided → Low
status: New → Confirmed
Ted Gould (ted) wrote :

No, I don't think it should be removed.

The reality is that the only way that an error can be reported when you close your laptop lid is through sound. All the display stuff doesn't work anymore. So we need to have that error for when a suspend does fail.

Now the problem here is that the sound is playing when there is not a failure, and that a failure is being reported after as suspend saying that the suspend failed. This information is gotten directly from HAL, so it is an error in HAL/PM-Utils about what they are reporting.

I think we have to keep the sound, what we need to fix is the error in reporting from HAL.

Changed in gnome-power-manager:
assignee: ted-gould → nobody
Changed in hal:
assignee: ted-gould → nobody
Owen Williams (ywwg) wrote :

I'd argue that it's more than not useful, it's extremely annoying and misleading. We have two dell laptops in the house that had this problem. Due to the pc-speaker-like sound of the beeps, and the fact that the volume of the sound is very loud independent of the mixer settings, I thought this was a BIOS bug. I've been googling "dell resume BIOS alarm" for literally months trying to figure out this problem. I only found this bug report by searching for "dell resume loud beep" eventually. (Getting up in the morning and hearing loud beeps from my resuming laptop is a rude awakening.)

I understand the need for a sound-only alarm, and that it can't be language-specific, but it needs to be a little more gentle, more like a mac error sound than the current "angry series of beeps" sound.

It also must correspond to an actual error, as stated. I hear the sound 50% of the time I resume, but only if it resumes successfully. I never hear the sound when resume fails. That's pretty poor. The option should be disabled until it starts correlating with actual failure.

Here with the same problem of a very loud noise after resuming... I have an HP Pavillion 9500 and I had this problem way before in 7.10. After I upgraded to 8.04, the problem remained and I thought it was a hardware issue (although my laptop is just 9 months old). However, I broke this laptop's screen and I had to install ubuntu in an old laptop of mine, Acer Travelmate 290 from 2004, and the same noise happens when resuming from hibernate. IT does happen randomly with me (so I pray when I'm in the library :S)

mac@alana:~$ uname -a
Linux alana 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux

Mario Limonciello (superm1) wrote :

After discussing this with upstream HAL, they believe the bug is actually in gnome-power-manager. A similar bug was fixed in KPowersave.

http://lists.freedesktop.org/archives/hal/2008-August/012190.html

Changed in hal:
importance: Low → Undecided
status: Confirmed → New
Changed in gnome-power-manager:
importance: Low → Undecided
status: Confirmed → New
Changed in gnome-power:
status: Unknown → New
Mario Limonciello (superm1) wrote :

Here is a debdiff for hardy to fix this.

Mario Limonciello (superm1) wrote :

The bzr branch for intrepid is available on this bug. The one that was listed in debian/control for hardy is not valid, and contains a lot of incorrect changelog information.

Mario Limonciello (superm1) wrote :

Here's the intrepid build log.

Mario Limonciello (superm1) wrote :

Here's the hardy build log

description: updated
description: updated
Sebastien Bacher (seb128) wrote :

the bug has been fixed upstream and should be fixed in intrepid when the new version is uploaded

Changed in gnome-power-manager:
importance: Undecided → Low
status: New → Confirmed
assignee: nobody → ted-gould
importance: Undecided → Low
status: New → Fix Committed
Changed in gnome-power:
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-power-manager - 2.23.91-0ubuntu2

---------------
gnome-power-manager (2.23.91-0ubuntu2) intrepid; urgency=low

  * Added two patches from Joakim Andersson <email address hidden> his
    comments on the patches are below.
  * Added 18_policy_actions_fallback.patch which makes policy actions
    fall back to per-percent policy if the battery profile is not good
    enough yet. It also ignores the accuracy of the battery profile when
    the GCONF key 'use_time_for_policy' is disabled. LP: #135548
  * Added 19_fix_critical_message.patch which fixes an error in the
    notification messages for critical battery. These messages would
    always show 0% battery remaining, since the cell unit object was
    reset while generating one of the strings used in the message.

  * 18_policy_actions_fallback.patch: Modified by Richard Hughes to
    make cleaner and smaller. Now keeps most prototypes intact.
  * I updated 18_policy_actions_fallback.patch from Richard's version
    to make it apply cleanly on 2.23.91.

gnome-power-manager (2.23.91-0ubuntu1) intrepid; urgency=low

  * Upstream release:
    * Handle "unknown" battery technology in HAL
    * Bug fixes (LP: #260314)
  * 75-ignore-long-failed-suspends.patch: added to prevent inaccurately
    indicating failed suspends when they were >= 6 hours. (LP: #242713)
    From Mario Limonciello <email address hidden>
  * 14_inhibit_tool.patch: A small tool to allow command line apps to
    use the inhibit DBus interface easily.
  * 17_icon_cache.patch: A patch to build the icon cache in the correct
    directory.
  * 50-r2882-fix-547766.patch: Removed as merged upstream.

 -- Ted Gould <email address hidden> Wed, 10 Sep 2008 09:36:40 -0500

Changed in gnome-power-manager:
status: Fix Committed → Fix Released
Mario Limonciello (superm1) wrote :

(this still needs the hardy task done for an SRU)

Changed in gnome-power-manager:
status: Confirmed → New
Martin Pitt (pitti) wrote :

Hardy upload sponsored. Assigning to Mario for driving the testing process.

Changed in gnome-power-manager:
assignee: nobody → superm1
status: New → In Progress
status: In Progress → Fix Committed
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Martin Pitt (pitti) wrote :

For verifying this, please don't only exercise the test case, but make sure that a normal (short-term) suspend and hibernate still works normally, too.

Matt Neilson (ichthyoboy) wrote :

confirmed as fixed on my Thinkpad R52. Before update, beeps on resume after overnight suspends. Now both short- and long-term (successful) suspends are sound free.

Bart Rose (jbrose3) wrote :

I seem to have the same issue as before with my R52 after the update. Still beeps and displays message of failed suspend.

David Fraser (davidf) wrote :

I've tested this. Normal (short-term) suspend and hibernate work normally.
However, on my first overnight (9 hour) suspend and resume, I still got the beeping sound and the message saying suspend failed to work properly. I can attach any relevant log files if that would help (just tell me what, I have captured dmesg, kern.log, messages and so on)
dpkg -s gnome-power-manager gives:
Version: 2.22.1-1ubuntu4.1

David Fraser (davidf) wrote :

Bother, I've just seen it looks like I've got the wrong version. Unfortunately that's what I got from hardy-proposed (and apt-get upgrade -t proposed doesn't show anything else)...

David Fraser (davidf) wrote :

OK, I've investigated and I was wrong about the version; 2.22.1-1ubuntu4.1 looks like it does have the fix (I'm on hardy).

I've looked at /var/log/kern.log and it seems bizarrely as though some of the suspend code ran after the resume (although I could see that the machine had a flashing light and was clearly suspended overnight) - I'll attach the relevant section here, as well as that from /var/log/messages (where you can see the gnome-power-manager messages)

David Fraser (davidf) wrote :

Got exactly the same symptoms after last night's suspend...

Matt Neilson (ichthyoboy) wrote :

I need to retract my confirmation...sound was off on my computer. After last night's suspend, beeps are still there.

Mario Limonciello (superm1) wrote :

I'm removing the verification-done tag since there hasn't been any ack's of it really working (after Matt's retraction). Anyone who has seen this failure still, do you have a /var/log/pm-suspend.log after a failed suspend that you would be able to post?

David Fraser (davidf) wrote :

No but I have dmesg and kern.log and messages - I've added pm-suspend.log to my capture script so I should have one soon...

Mark Edgington (edgimar) wrote :

I also experience the same symptoms still (both before and after the patched gnome-power-manager (and a reboot), on a Dell Inspiron 6400) -- attached is pm-suspend.log (doesn't contain too much info, however...).

David Fraser (davidf) wrote :

Here's my pm-suspend.log. The only problem mentioned is:
 * Reconfiguring network interfaces...
ppp0: ERROR while getting interface flags: No such device

Matt Neilson (ichthyoboy) wrote :

Here is my pm-suspend.log, fresh from this morning's suspend complete with beeps.

Martin Pitt (pitti) wrote :

So this actually doesn't work for anyone?

If it works for some, but not others, but otherwise doesn't introduce regressions, the package can go to -updates and this bug stay open.

If it doesn't work for anyone, we should pull the -proposed package.

Muharem Hrnjadovic (al-maisan) wrote :

Hi there, I have Hardy/Gnome running on my T61 laptop and do suspend it over night. No problems experienced so far. more specifically, I do not get an error message when I resume.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnome-power-manager - 2.22.1-1ubuntu4.1

---------------
gnome-power-manager (2.22.1-1ubuntu4.1) hardy-proposed; urgency=low

  * Add 75-ignore-long-failed-suspends.patch to prevent inaccurately
    indicating failed suspends when they were >= 6 hours. (LP: #242713)

 -- Mario Limonciello <email address hidden> Tue, 02 Sep 2008 17:40:15 -0500

Changed in gnome-power-manager:
status: Fix Committed → Fix Released
Felipe Figueiredo (philsf) wrote :

I turned on the option to beep if problem occurs, and got a beep this morning, with the new version, so it seems it's not fixed for me, also.

Geek2theCore (jeremymccaleb) wrote :

I have a Toshiba M60. Still there for me, too. I'd attach my pm-suspend.log, but it's completely error-free.

Changed in gnome-power:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.