Re: [ 00/10] [Suspend2] Modules support.

[Pavel Machek <pavel@suse.cz>]

On Pá 03-02-06 09:49:33, Matthew Garrett wrote:
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > Follow up - do we have a rough idea how bad the suspend problem is, like
> > approximately what % of laptops don't DTRT and just suspend when you
> > close the lid?
> 
> It's arguable whether "just suspending when you close the lid" is
> actually DTRT, but if you want "how many x86 laptops can we
> successfully

:-).

> suspend and resume" then the number is between 80-90% for RAM and a
> little more than that for disk (numbers based on Ubuntu, other
> distributions don't have as much infrastructure for this right now).
> This is based on doing hacky things like unloading all the network and
> USB drivers before suspend, but by and large the driver situation is
> much improved. The single biggest problem is video reinitialisation, and
> that can't be solved in-kernel.

...and Ubuntu has vbetool solution which seems to work on 90% of all
notebooks, nice. Which big whitelist that basically says it all
works. Thanks for doing this work.

> (By and large, the biggest problem is repeated kernel regressions that
> hit suspend in bizarre ways. This doesn't get picked up on quickly
> because almost nobody is using this code, because "everyone knows" it
> doesn't work. Except it /does/. What we need is for distributions to
> actually work together on this, rather than everyone trying to fix the
> same problems independently, each coming up with different solutions and
> the world generally being a miserable place)

Perhaps we should force suspend/resume cycle at one of 10 boots :-).

Actually if you want to very quickly test if your changes did not
break swsusp, it should be enough to do 

swapoff -a; echo -n disk > /sys/power/state

. Your system will do half of system suspend, immediately followed by
resume.

								Pavel
-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/