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
On Tue, 2008-09-09 at 00:01 +0000, czk wrote: pm-suspend. log pm-utils/ sleep.d/ 00clear suspend: disabled. pm-utils/ sleep.d/ 05led suspend: not applicable. pm-utils/ sleep.d/ 10NetworkManage r suspend: success. pm-utils/ sleep.d/ 49bluetooth suspend: not applicable. pm-utils/ sleep.d/ 50modules suspend: not applicable. pm-utils/ sleep.d/ 90clock suspend: success. pm-utils/ sleep.d/ 94cpufreq suspend: success. pm-utils/ sleep.d/ 95anacron suspend: success. pm-utils/ sleep.d/ 95led suspend: not applicable. pm-utils/ sleep.d/ 96laptop- mode suspend: success. pm-utils/ sleep.d/ 98smart- kernel- video suspend: success. pm-utils/ sleep.d/ 99video suspend: disabled.
> $ cat /var/log/
> Initial commandline parameters:
> Mon Sep 8 12:48:21 CST 2008: Running hooks for suspend.
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> /usr/lib/
> 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.
> t.quirk. vbe_post = true (bool) t.quirk. vbemode_ restore = true (bool)
> $ lshal |grep quirk
> power_managemen
> power_managemen
Can you try running pm-suspend manually by running the following command pm-suspend. log to this bug?
as root and attaching the resultant /var/log/
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