Bug#343440: Resuming from suspend to RAM with 2.6.14-5 fails significantly more often than with 2.6.14-4
Am Sonntag, den 12.11.2006, 23:15 +0100 schrieb maximilian attems:
> heya,
>
> On Mon, 06 Nov 2006, Thomas Maier wrote:
>
> > Am Donnerstag, den 02.11.2006, 18:01 +0100 schrieb maximilian attems:
> >
> > That is very good. Thanks for the link (retrieving package information
> > in synaptic doesn't always work), I well remember the day when I read
> > the notes for 2.6.14-3:
> > [ maximilian attems ]
> > * Reenable CONFIG_SOFTWARE_SUSPEND on i386 and ppc, resume=/dev/<other device>
> > must be set by boot loader. (Closes: #267600)
> >
> > You were the hero of my day :).
>
> thanks, your reply made my day. :)
> remember that previously swsusp would grable the initrd mem location,
> and we were missing earlier userspace support for it..
Maks, you're welcome, I really appreciate you guys working on that kind
of stuff. I stuck to an old suspend2-hand-patched 2.6.9 for a long
time, hoping for better suspend support in standard Debian kernels.
Reading that entry really made _my_ day :).
> > > 2.6.19 promises a speedier suspend to disk, let' see.
> >
> > Do you know whether any work was done after 2.6.17 (my last Debian
> > kernel) to speed up that "Shrinking memory..." phase. Because that's
> > where all the time was spent. Not that the actual writeout was speedy,
> > but that shrinking thing was definitely the most annoying part.
>
> yes akpm and rafael did a lot of for work 2.6.19,
> i've heard that the next ubuntu release will be based on it,
> so you should really have soon those improvements.
Great, thanks for the hint! That's some good news. At least one guy at
it who doesn't seem to be an egomaniac.
> <snipp>
> > > 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.
> >
> > Suspend to RAM works acceptably fast here, too. Not a single second
> > (wow!), but, say, three seconds. I could live with that if it resumed
> > reliably. (Plus, the machine really drains batteries, even when S3ed).
> >
> > 15-25 seconds sounds fine, too. How much of your RAM is used? It
> > really is the "Shrinking memory" phase (see above) that takes the time
> > here. I have a feeling that it starts being slow as soon as I use more
> > than half of my RAM. Which somehow fits to something I read about
> > swsusp ages ago (that it needs half of the RAM free but that was long
> > ago and maybe they finally got rid of that).
> >
> > And what about resuming? Not the actual resume itself but the feeling
> > of the machine.
>
> the trouble with suspending to ram seems that at reinitialization not
> all pci quirks are applied the same way like on regular boot.
> need -ac (alan cox) to discover it recently :)
So there is hope that this will be fixed, soon? Edgy is still the same,
it does not resume reliably. Even suspend to disk failed to resume
today, after only four or five days of uptime. My last Debian uptime
was 72 days, so obviously you did a good job there :). And I only took
the machine down to install Edgy---I wonder if that was a good idea...
> 1 gig of ram and quit a lot is used,
> here most of the time is spend on writing the image to disk,
> is much quicker on single user mode, feels like without dma.
Strange. So it seems they fixed that in newer kernels (which one do you
use?). Or are caches eating lots of your RAM? (From what I remember,
suspend throws away disk caches, so that could of course easily drop the
amount of stuff that needs to be written to disk and maybe care for the
"shrinking memory phase" to be skipped?) Is swsusp supposed to not page
out everything and write out the disk caches, too, one day, like
suspend2 does?
I just suspended a session with free output as follows (yes, I oversized
swap but I wanted to be on the safe side with suspend):
$ free -m
total used free shared buffers cached
Mem: 1010 994 15 0 14 299
-/+ buffers/cache: 680 330
Swap: 2259 17 2241
When Edgy suspends, unfortunately I do not see a console (*sigh*), but
the write out to disk started rather quick, i.e. not half a minute or
longer "shrinking memory" (which always happened when I had 800+MB used,
excluding buffers/cache).
When I resumed the session, a lot needed to be paged back in, although
it felt faster than my last Debian experience.
Regards and a nice week (Monday's work time is almost over, yay!),
Thomas.
Reply to: