Bug 145294 - Start supporting suspend-to-RAM
Summary: Start supporting suspend-to-RAM
Status: VERIFIED FIXED
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Alpha 4
Hardware: Other Other
: P5 - None : Enhancement (vote)
Target Milestone: ---
Assignee: Forgotten User ZhJd0F0L3x
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-24 19:52 UTC by Pavel Machek
Modified: 2007-06-05 11:20 UTC (History)
4 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Machek 2006-01-24 19:52:00 UTC
Suspend-to-RAM might be finally in state where we could mark it as supported on selected machines. (Where selected machines are "those where we can get video resume to work.)

In suspend.sf.net's cvs, there's s2ram C program. It includes DMI parsing code and initial whitelist with just my thinkpad. More video restore methods are needed, and whitelist really needs more entries.
Comment 1 Forgotten User ZhJd0F0L3x 2006-01-24 21:05:12 UTC
Holger and me have already thought about unconditionally just enabling suspend to RAM during BETA, maybe with a first-time-warning in the kpowersave client, just to see how many bugreports we get.
I have seen many machines where no video workaround is needed as long as the X server is running since X knows how to get video up again - many not too recent radeons and many i915's fall into that category IIRC.
Maybe Andreas wants to decide something here ;-)
Comment 2 Pavel Machek 2006-01-24 22:18:28 UTC
Well, I'd really prefer to do the whitelist thing, at least for final kernels.  Some special arangements seem to be needed for some common machines, like thinkpad X32. (It suspend/resumes okay, but leaves backlight on, eating power a bit too quickly).

It should be easy to call s2ram --test (or something like that), and if that returns success, no warning is needed -- it should just work. If machine is not in the whitelist, we may want the user to report working tricks back to us.
Comment 3 Holger Macht 2006-01-24 22:39:56 UTC
I had a quick look and I like it. I agree with Pavel to try this approach. At least for our "external" releases if not possible for our supported products. I also saw more and more machines during the last month where S2R worked out of the box.
I will have a deeper look at it this week.
Comment 4 Andreas Jaeger 2006-01-25 07:21:26 UTC
I would suggest to go to a whitelist - but we can do it unconditonally for the next beta first...
Comment 5 Forgotten User ZhJd0F0L3x 2006-03-07 07:17:44 UTC
implementing right now.
Comment 6 Winfried Dobbe 2006-03-20 13:17:02 UTC
Suspend-to-ram worked perfectly on my HP compaq nc2160 notebook running 10.1 beta4.
After upgrading to 10.1 beta8, the screen remains always black after resuming from suspend-to-ram.
Comment 7 Forgotten User ZhJd0F0L3x 2006-03-20 14:02:54 UTC
(In reply to comment #6)
> Suspend-to-ram worked perfectly on my HP compaq nc2160 notebook running 10.1
> beta4.
> After upgrading to 10.1 beta8, the screen remains always black after resuming
> from suspend-to-ram.

try booting with the boot parameter "noapic".

If this helps, please open a separate bug against the kernel for this issue and add me to cc:
Comment 8 Winfried Dobbe 2006-03-20 20:54:45 UTC
No, booting with noapic doesn´t make a difference (tried twice). Still black screen. Should I open a separate bug anyway?
Comment 9 Forgotten User ZhJd0F0L3x 2006-03-21 09:22:06 UTC
(In reply to comment #8)
> No, booting with noapic doesn´t make a difference (tried twice). Still black
> screen. Should I open a separate bug anyway?

Yes, please. This is a regression specific to your machine that should be tracked separately. Thanks.
Comment 10 Stefan Behlert 2006-07-03 12:57:48 UTC
I think this is now working.