Bug#343440: Resuming from suspend to RAM with 2.6.14-5 fails significantly more often than with 2.6.14-4
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.
> > Last week I switched to Edgy (Ubuntu). While I was still with Debian,
> > I stopped using suspend to RAM (months ago) and used suspend to disk
> > instead. The in-kernel implementation is quite stable on my notebook
> > but sucks in all other aspects (e.g. it is _annoyingly_ slow). Being
> > extra careful when hibernating (old habit from the days when things
> > tended to freeze), my last uptime was 72 days. As a side note I'd
> > suggest (or, rather _beg_) offering suspend2-enabled kernels (see
> > suspend2.net), which works amazingly fast and has a couple of other nice
> > characteristics (better concept, nice community, nice developer
> > (especially in contrast to the in-kernel suspend), etc.). In short:
> > in-kernel suspend works but sucks, suspend2 works and is nice. Easy
> > choice, I'd think :). Should I file a wishlist-bug?
>
> 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.
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).
> you really want to use uswsusp as it has the advantages
> of suspend2
Again, this is wrong.
> , while not having akward not mergeable code.
>
> so no your wishlist bug is not welcome, but would be useless
> see http://wiki.debian.org/DebianKernelPatchAcceptanceGuidelines
Thanks for the pointer, that is a clear statement.
> as you didn't tell if you tested the 2.6.18 linux-images and
> switched distribution the bug can most probably be closed.
Yes. I stopped using suspend to RAM a few versions before and now I can
no longer test. Again, all the best for the release,
--
Thomas Maier - Research Assistant - University of Kassel, Germany
Reply to: