pm-suspend.log reports "power-pmu: failed to open /dev/pmu"

Yeah, your system should not even be trying to invoke pm-pmu (I assume that is what you meant -- afaik, there is no power-pmu command), but for whatever reason the binary seems to be installed on your system.

The attached patch should work around it.

Could you also attach the output of the following commands to this bug report?
dpkg-query -S pm-pmu

Forgot to note that the patch applies to /usr/lib/pm-utils/functions

The output is
dpkg: *pm-pmu* not found.

I'll let you know about the patch soon. Thanks.

I applied the patch and it fixed the pm-pmu error, but now another is coming up.

/usr/lib/pm-utils/functions: line 58: !grep: command not found

I've attached the full pm-suspend.log and my /usr/lib/pm-utils/functions file.
I think the remove_suspend_lock() function was the subject of an update the other day, but I'm not sure...

Here is the code in question:

remove_suspend_lock()
{
 rm -f /var/run/pm-suspend
 # This call will cause terminal corruption when using fglrx. This is a work around only.
 # Tested and suggested by AMD/AGP (ATI) Linux engineering group
 if !grep -q fglrx /proc/modules; then
  chvt 1
 fi
 chvt $VT
 openvt -- sh -c "sleep $1 ; rm -f /.suspended >/dev/null 2>&1 0<&1" >/dev/null 2>&1 0<&1 &
}

Should this be filed as a separate error? Thanks.

Yeah, whatever patch went into that update was obviously not tested before being pushed out.

Change that "!grep" to "! grep" and it will Do The Right Thing.

Or delete that whole if clause and replace it with

grep -q fglrx /proc/modules || chvt 1

which is easier to read and not susceptible to spacing errors in the future.

Ok, I just noticed that my "new toy" (suspend even with fglrx) is broken again. *sigh* Ok, that's beta, so perhaps I can do something to help.

System:
It's still a Laptop (LG S1) with Core2Duo, ati/AMD x1600
Currently I'm running Hardy beta1, pm-utils 0.99.2-3ubuntu8, kernel 2.6.24-14.25 (generic flavour) with "out-of-the-box" restricted/ubuntu modules.

Symptoms:
Suspending works nice (since the "chvt 1"-patch, I even don't get those pesky grey stripes on shutdown anymore) but resume is an utter failure: the power light comes on, the harddrive spins up, makes one _very_ short access and thats all. No screen, no hd activity, nothing.

Log: (pm-suspend.log attached - I'm learning ;-) )
Well, this is why I don't start a new bug. Obviously the "very short hd access" results in the system writing "power-pmu : Failed to open /dev/pmu"

Shouldn't that have been solved?

Oh - by the way - is this bug related to bug #204588 in any way?

... ok, I didn't attach the file...

Resume from 'suspend to ram' does not work for hp tc4200 either.
Same messages: power-pmu: failed to open /dev/pmu

on kubuntu hardy: dpkg-query -S pm-pmu yields:
                  dpkg: *pm-pmu* not found.

Patch removed /dev/pmu error, update fixed ! grep error, and pm-suspend.log is error free, but I'm still getting a popup on resume. It only seems to happen if the computer is suspended for multiple hours, but everything appears to resume normally. Is there another log file I could check to look for the source of this error? Thanks.

This is a popup that is happening on the desktop, I presume?

Can you attach the text of the popup to this bug?

Sorry, yes it is on the desktop. It says something to the effect of "Sleep has failed. Please check the help file for common causes" I will attach the full message the next time it happens...

The exact error message is:

Sleep Problem
    Your computer failed to suspend.
    Check the help file for common problems.

Is there a way to find out who's triggering this message and why?

Sorry, but that is not a pm-utils error message. At a guess, I would say that it is a gnome-power-manager error. You should probably file that issue against g-p-m

Will do. Hopefully, ironing these bugs out will help some others as well. If you need me to look into anything else, ie why my setup thinks I have a pmu, please feel free to ask. Thanks again for all your help.

I have a Lenovo X61 Tablet that also shows this issue, with the loud beep and all.

I am running a fully updated Hardy Heron (Ubuntu) 64-bit edition.

I will give the patch a try and see if it works for me as well in getting rid of the beep. I also get the error message from g-p-m, so if there is a bug on that already, might be a good idea to link it here.

dpkg-query -S pm-pmu
dpkg: *pm-pmu* not found.

Here is lspci:
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
00:19.0 Ethernet controller: Intel Corporation 82566MM Gigabit Network Connection (rev 03)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)
00:1f.0 ISA bridge: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03)
00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03)
02:00.0 Memory controller: Intel Corporation Turbo Memory Controller (rev 01)
03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
05:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ba)
05:00.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 04)
05:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)

The patch is no longer usable as the do_suspend function now uses "/usr/lib/hal/hal-system-power-pmu sleep || echo -n "mem" > /sys/power/state" instead of the "pm-pmu suspend" that, my guess, was being called when the patch was written. The error comes from "/usr/lib/hal/hal-system-power-pmu sleep" and seems harmless as it just prints out the error message and exits. Seems like the problem might be elsewhere now.

I'm also getting this error and also on an Intel 900 series chipset ( 945 ). Since this message appeared, my computer hasn't been able to wake from sleep. The fans and drives spin up, but nothing seems to happen after that. No keyboard, no mouse, nothing.

Breaks suspend very often (although it is a bit curious why it does that), and recent regression. Milestoning.

I also occasionally get the "keyboard and mouse do not work", but another suspend/resume cycle usually fixes it.

This bug was fixed in the package pm-utils - 0.99.2-3ubuntu9

---------------
pm-utils (0.99.2-3ubuntu9) hardy; urgency=low

  * debian/patches/70-remove-pm-pmu.patch: Check for /dev/pmu before calling
    /usr/lib/hal/hal-system-power-pmu. Not doing so causes error messages and
    g-p-m error beeps on non-powerpc systems. (LP: #210832)
  * debian/patches/98-unload_network_modules.patch: Restart network after
    resuming, since this unloads/reloads network modules during suspend. This
    unbreaks static network configuration after suspend, and mimics
    acpi-support's behaviour of previous releases. (LP: #162654)

 -- Martin Pitt <email address hidden> Fri, 11 Apr 2008 08:21:13 -0500

I'm getting exactly the same UI symptoms: "After resuming from suspend I get a loud beep and a popup [Sleep Problem
Your computer failed to suspend. Check the help file for common problems.] telling me sleep failed. This only happens randomly and everything seems to have worked properly."

Actually, my Xorg "synaptics" touchpad customizations seem to be gone after any resume, but I think that's a different bug, because it was happening after any suspend before this started happening, too.

This is after fixing
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/211572
with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/211572/comments/20
i.e. explicitly having module "ehci_hcd" temporarily removed during suspend. Suspend had been working fine for short periods of time (and still is), but when I suspended for a whole night, it wouldn't wake up again (at least not for half an hour, which is more than I ever had to wait for the Gutsy kernel suspend bug that I can't find right now). Now it's better: when I suspended last night, it did wake up quickly, but with the above symptoms of noise and spurious error message. But when I test suspend/resuming now with only being patient enough to be suspended for a few minutes, I don't get any loud beep or popup.

system:
Ubuntu Hardy x86 edition, updated as of today May 26 2008, running on June 2007 MacBook, booted using CSM (emulated BIOS) (because I haven't gotten elilo or grub2-efi to work). Is there any other useful information to mention? It's an Intel graphic card using their open-source driver that's built into Xorg; the CPU is intel x86-64; I'm using a recent MadWifi svn snapshot for wireless (though I'm plugged into Ethernet right now), following https://help.ubuntu.com/community/MacBook; and svn uvcvideo-r205 and the mactel PPA ( so iSight works -- http://ph.ubuntuforums.com/showthread.php?t=764616 ).

/var/log/pm-suspend.log contains nothing suspicious (see attachment). I have no "/dev/pmu" file.

linux-2.6.24-19 resolved this loud-beep and message issue for me (I upgraded that soon after a hal(-info?) upgrade that *didn't* seem to fix the problem, and made a few other changes while rebooting, but I'm guessing it was the kernel upgrade that fixed it). The Xorg Synaptics issue is still present, listed under Launchpad Bug #104060 ( https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/104060 )

er, never mind, today the beep issue is back.