Bug#343440: Resuming from suspend to RAM with 2.6.14-5 fails significantly more often than with 2.6.14-4

[maximilian attems <maks@sternwelten.at>]

hello thomas,

On Tue, 31 Oct 2006, Thomas Maier wrote:

> Am Montag, den 30.10.2006, 14:38 +0100 schrieb maximilian attems:
> > On Mon, Oct 30, 2006 at 10:42:25AM +0100, Thomas Maier wrote:
> > > Hi David,
> > > 
> > > thought nobody's going to look at this, it's almost a year :).  
> > 
> > swsusp bugs are low priority and there is still lots of work going
> > on upstream to make it more stable driver wise.
> 
> Yeah, frustrating from a user's point of view, but absolutely
> understandable.

we try our best so you'll see in Debian 2.6.18 several backported
swsusp patches.
http://svn.debian.org/wsvn/kernel/dists/trunk/linux-2.6/debian/changelog?op=file&rev=0&sc=0
2.6.19 promises a speedier suspend to disk, let' see.
and the suspend2 maintainer finaly starts to feed upstream.
 
 
<snipp>
> > suspend2 adds a gif decoder and is not even included in the bloated
> > ubuntu kernel, see the debian kernel policy
> > the only sucess of suspend2 is to unload a bunch of drivers and
> > reoload them, that's most of the difference for the user.
> 
> You obviously never used it and don't know what you are talking about.
> 
> FYI, suspend2 does not unload a bunch of drivers.  That's the job of a
> userspace application called hibernate (there is a Debian package with
> the same name), which I think originates from the suspend2 community but
> is not specific to it, i.e. it can be used with other suspend methods,
> too.

hibernate keeps track of driver, which haven't implementented an resume
methode like usblp (only latest).
 
> And the real difference to me as a user is the time it takes to suspend
> the machine.  It is really seconds with suspend2 (say, 20 seconds)
> compared to a few _minutes_ with swsusp.  When trying it yourself, be
> sure to suspend a real-life session (i.e. use a substantial part of your
> RAM).  And then resume your machine and feel the difference. With swsusp
> it runs like a pig, because everything needs to be paged back in.  With
> suspend2, you get your machine back like it was when you suspended it
> (with the file system caches still as hot as before).

here on an x40 suspend to ram takes not even 1 second and
suspend to disc varies of the image size but is around 15-25 seconds.

i have no idea what your laptop is, but i'd be curious if ubuntu
linux image suspends quicker?
 
best regards
 
-- 
maks