Bug#343440: Resuming from suspend to RAM with 2.6.14-5 fails significantly more often than with 2.6.14-4
Am Freitag, den 27.10.2006, 18:57 +0200 schrieb David Schmitt:
> Hi Thomas!
>
>
> In preparation of the upcoming etch release, would you please
> test if either 2.6.17-9 from testing or 2.6.18-3 from unstable
> still have problems resuming from RAM?
>
> Newer kernels now have a user mode software suspend (package uswsusp) which
> also can suspend to RAM and disk. It'd be interesting if you could try this
> also.
>
> Additionally if the problems persist, please detail how far your laptop can
> resume.
>
> Please report your findings by sending "found" or "close" followed by
> the bug number and the respective version to control@bugs.debian.org as
> detailed on http://www.debian.org/Bugs/server-control or by sending
> additional information to the bug report (reply to this mail)
>
>
> Thank you for your cooperation!
Hi David,
thought nobody's going to look at this, it's almost a year :). 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?
Good luck with the release, Thomas.
--
Thomas Maier - Research Assistant - University of Kassel, Germany
Reply to: