Bug 145294

Summary:	Start supporting suspend-to-RAM
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Pavel Machek <pavel>
Component:	Kernel	Assignee:	Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x>
Status:	VERIFIED FIXED	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	aj, behlert, suse-beta, winfried_mb2
Version:	Alpha 4
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

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.