Comment 7 for bug 267141

On Tue, 2008-09-09 at 00:01 +0000, czk wrote:
> $ cat /var/log/pm-suspend.log
> Initial commandline parameters:
> Mon Sep 8 12:48:21 CST 2008: Running hooks for suspend.
> /usr/lib/pm-utils/sleep.d/00clear suspend: disabled.
> /usr/lib/pm-utils/sleep.d/05led suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/10NetworkManager suspend: success.
> /usr/lib/pm-utils/sleep.d/49bluetooth suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/50modules suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/90clock suspend: success.
> /usr/lib/pm-utils/sleep.d/94cpufreq suspend: success.
> /usr/lib/pm-utils/sleep.d/95anacron suspend: success.
> /usr/lib/pm-utils/sleep.d/95led suspend: not applicable.
> /usr/lib/pm-utils/sleep.d/96laptop-mode suspend: success.
> /usr/lib/pm-utils/sleep.d/98smart-kernel-video suspend: success.
> /usr/lib/pm-utils/sleep.d/99video suspend: disabled.
> Mon Sep 8 12:48:22 CST 2008: performing suspend

Interesting -- when running with the kernel suspend backend, 00clear and
99video should not be disabled -- only the uswsusp module does that.
Looks like that last patch broke pm-utils in a particularly spectacular
fashion.

>
> $ lshal |grep quirk
> power_management.quirk.vbe_post = true (bool)
> power_management.quirk.vbemode_restore = true (bool)

Can you try running pm-suspend manually by running the following command
as root and attaching the resultant /var/log/pm-suspend.log to this bug?

PM_DEBUG=true /usr/sbin/pm-suspend --quirk-vbe-post --quirk-vbemode-restore

This will spew out tons of debugging information into the logfile and
help pinpoint exactly where pm-utils is failing.

--
Victor Lowther
Ubuntu Certified Professional