linux-kernel - Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200802211702.02306.jesse.barnes@intel.com>
Date:	Thu, 21 Feb 2008 17:02:01 -0800
From:	Jesse Barnes <jesse.barnes@...el.com>
To:	"Jeff Chua" <jeff.chua.linux@...il.com>
Cc:	"Romano Giannetti" <romano@....icai.upcomillas.es>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"suspend-devel List" <suspend-devel@...ts.sourceforge.net>,
	"Dave Airlie" <airlied@...ux.ie>, "Greg KH" <gregkh@...e.de>,
	lkml <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>, linux-acpi@...r.kernel.org
Subject: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.

On Thursday, February 21, 2008 4:52 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <jesse.barnes@...el.com> 
wrote:
> >  Your s2ram script is doing your STD also?  Seems counterintuitive. 
> > Anyway, some machines also re-POST the GPU on resume from S3; maybe yours
> > is doing that.
>
> It's s2ram to do STR, not STD. Sorry for the confusion. But the key
> point is there's no GREEN for STR. Mr Green only appear with STD.

Ah, ok that makes sense.

So typically, what you'd see at suspend time is this ugly call chain:

1) user requests suspend or hibernate
2) kernel kicks users off VT
3) X calls LeaveVT function of X driver
4) X driver restores whatever video state it felt like saving when it started 
up
5) kernel calls suspend methods
6) machine goes to sleep

then on resume:

1) user requests wakeup
2) kernel calls resume methods
3) X takes back the VT, calling driver EnterVT methods
4) X driver EnterVT routine runs, doing whatever it wants
5) you're back to where you were (on a good day anyway)

So, on your machine, I suspect your firmware is doing enough that X doesn't 
have to save/restore full video state around Enter/Leave VT (the same 
functions called at VT switch time when you press ctl-alt-fx), otherwise 
you'd be missing things like your backlight or text consoles.

So the advantage of the kernel suspend/resume hooks for the DRM layer is that 
the kernel video drivers can do full state save/restore (which X usually 
doesn't do, and isn't really designed to do), so that if your platform 
*doesn't* do it all, you'll still end up with a usable machine in the end.

The fact that you'd started running into problems since we merged this just 
means your platform was taking care of it for you (lucky you) and that we 
have some bugs in the hibernate code that we're just discovering.

Jesse
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/