Dealing with suspend/resume failures

[David Zeuthen]

On Fri, 2006-11-03 at 12:00 -0500, Bill Nottingham wrote:
> David Zeuthen (david at fubar.dk) said: 
> > I'm adding the pm-utils list as Cc as I want to make sure we can get
> > useful logging output. I think HAL would just use an option
> > --log-verbose-output-to-stderr when invoking pm-suspend and
> > pm-hibernate.
> 
> So, in most cases, the 'interesting' messages are from the kernel
> (process XXX not stopped, device YYY threw an error.)
> 
> For this to work well, we may need to augment pm-utils to catch
> the kernel logs.

I think the "contract" I'd like is for pm-utils to (when passing e.g.
--log-verbose-output) spew out everything that would go into the body of
a bug report, perhaps including the output of 'lsmod' to e.g. capture
what kernel modules are loaded. And other non-static information too. 

Obviously we can't include "everything" (e.g. run sysreport or whatever)
as we don't want to slow down the suspend operation too much.

So I think that static information, such as system vendor, system
product etc. (e.g. the smbios.* properties on HAL), can be filled in by
the desktop policy manager (on the next reboot) when it sees a failure. 

Btw, ideally the desktop policy manager would probably submit a bug
report against pm-utils on bugs.freedesktop.org and pm-utils would
triage the reports, e.g. reassign to X.org (which happens to be the same
bugzilla) or bugzilla.kernel.org (which is a different bugzilla but
linking bugzillas together is maybe what needs to happen anyway).

That's what I think anyway but I want to make sure that pm-utils /
desktop policy managers developers / distro vendors are happy with this
approach too.

     David