Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Feb 20, 2008 2:19 PM, Jeff Chua
> I'll try the "idle=poll" to see if that works and will try some printk

I don't know what exactly the i915_suspend() and i915_resume() are 
supposed to do because it works better without them.

After inserting "return 0;" right at the top of those two functions, 
suspend (and power-off properly), and resume (without green screen) works 
just fine.

I would like to know what they're for.

Tested suspend-to-ram, and suspend-to-disk, both console and X on notebook 
internal LCD display, all works without these two functions.

But, anyway, got down to just one line in i915_drv.c causing the hang 
during suspend. "pci_set_power_state(dev->pdev, PCI_D3hot);".

And green screen problem during resume is caused by i915_restore_vga(dev);

So, let me where to go from here.


Thanks,
Jeff.




--- linux/drivers/char/drm/i915_drv.c.bad	2008-02-20 
11:29:14 +0800
+++ linux/drivers/char/drm/i915_drv.c	2008-02-21 00:58:37 +0800
@@ -369,7 +369,7 @@
  	if (state.event == PM_EVENT_SUSPEND) {
  		/* Shut down the device */
  		pci_disable_device(dev->pdev);
-		pci_set_power_state(dev->pdev, PCI_D3hot);
+		//pci_set_power_state(dev->pdev, PCI_D3hot);
  	}

  	return 0;
@@ -521,7 +521,7 @@
  	for (i = 0; i < 3; i++)
  		I915_WRITE(SWF30 + (i << 2), dev_priv->saveSWF2[i]);

-	i915_restore_vga(dev);
+	//i915_restore_vga(dev);

  	return 0;
  }

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Feb 21, 2008 1:17 AM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
>
>
> On Feb 20, 2008 2:19 PM, Jeff Chua
> > I'll try the "idle=poll" to see if that works and will try some printk

Tried "idle=poll" but it has not effect.

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Thu, 21 Feb 2008, Jeff Chua wrote:
> 
> After inserting "return 0;" right at the top of those two functions, suspend
> (and power-off properly), and resume (without green screen) works just fine.
> 
> I would like to know what they're for.

Try suspend-and-resume without X.

Also, try it on one of the more modern laptops - even *with* X.

Basically, the kernel wants to be able to do what X does, because it means 
that when it works, it works _so_ much better than doing it in X. So 
getting it working is definitely worth it.

That said, before you do anything else, try if suspend-to-RAM works. 

That's the primary goal for this code anyway, and if it works that gives a 
good hint. Suspend-to-disk is fundamentally different, and it's entirely 
possible that for the suspend-to-disk case we should just say "screw 
trying to suspend/resume graphics", since you'll have the BIOS resuming 
text-mode anyway, and there are no performance or debugging advantages.

		Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Feb 21, 2008 1:28 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Try suspend-and-resume without X.

Works without those two functions.

> Also, try it on one of the more modern laptops - even *with* X.

Again, still works. Tested on Lenovo X60s.

> Basically, the kernel wants to be able to do what X does, because it means
> that when it works, it works _so_ much better than doing it in X. So
> getting it working is definitely worth it.

> That said, before you do anything else, try if suspend-to-RAM works.

Yes, still works.

> That's the primary goal for this code anyway, and if it works that gives a
> good hint.

Ok, what's next?

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Thu, 21 Feb 2008, Jeff Chua wrote:
> 
> Works without those two functions.

Ahh. You're using the BIOS to re-initialize your video, aren't you? 

If STR works without X, then you have something else resuming graphics, 
and that may be what then interacts badly with the fact that the kernel 
also does so. 

> Ok, what's next?

Let's try to narrow it down to what the interaction is. Are you using 
something like acpi_sleep=s3_bios or similar? That's what the kernel 
support is supposed to make unnecessary in the long run, along with all 
the video mode flickering (ie we should be able to resume to the video 
mode we want, not flicker through unnecessary modes).

			Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Feb 21, 2008 1:52 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Ahh. You're using the BIOS to re-initialize your video, aren't you?

I don't know. Just pure simple "s2ram" without any options.


> Let's try to narrow it down to what the interaction is. Are you using
> something like acpi_sleep=s3_bios or similar?

No. Not additional command line option except for resume=/dev/sda3 reboot=bios


> That's what the kernel support is supposed to make unnecessary in the long run,

Ok, understand now.

Jeff.

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

[Romano Giannetti]

On Thu, 2008-02-21 at 02:02 +0800, Jeff Chua wrote:
> On Feb 21, 2008 1:52 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > Ahh. You're using the BIOS to re-initialize your video, aren't you?
>
> I don't know. Just pure simple "s2ram" without any options.

Well, as far as I know, s2ram could be doing vbe save/restore for you.
Even without parameter, if your laptop is in the whitelist.

> > Let's try to narrow it down to what the interaction is. Are you using
> > something like acpi_sleep=s3_bios or similar?
>
> No. Not additional command line option except for resume=/dev/sda3 reboot=bios

My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need
s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with
echo mem > /sys/power/state.

Romano

I imagine this will be received as blasphemy, but if only ndiswrapper
were not horribly broken, this will be my day-by-day kernel. I just hope
ath5k will arrive to my chipset soon...



--
La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.

This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

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

[Jesse Barnes]

On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> > > Let's try to narrow it down to what the interaction is. Are you using
> > > something like acpi_sleep=s3_bios or similar?
> >
> > No. Not additional command line option except for resume=/dev/sda3
> > reboot=bios
>
> My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need
> s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with
> echo mem > /sys/power/state.

Cool, glad to hear at least one success report. :)

> This communication contains confidential information. It is for the
> exclusive use of the intended addressee. If you are not the intended
> addressee, please note that any form of distribution, copying or use of
> this communication or the information in it is strictly prohibited by law.
> If you have received this communication in error, please immediately notify
> the sender by reply e-mail and destroy this message. Thank you for your
> cooperation.

Really?  This contains confidential information?  I'd better notify you and 
destroy this message now... :)

Jesse

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
>  > > > Let's try to narrow it down to what the interaction is. Are you using
>  > > > something like acpi_sleep=s3_bios or similar?
>  > >
>  > > No. Not additional command line option except for resume=/dev/sda3
>  > > reboot=bios
>  >
>  > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need
>  > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with
>  > echo mem > /sys/power/state.
>
>  Cool, glad to hear at least one success report. :)

STR is always working on my X60s. No green screen, no hang. Both s2ram
and "echo mem > /sys/power/state". It's STD that's having problem.

But strange thing is I could even restore console after STD even
without agp and i915 module loaded, so I don't know how the console
vga got saved and restored.

Thanks,
Jeff.

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

[Jesse Barnes]

On Thursday, February 21, 2008 4:20 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <jesse.barnes@intel.com> 
wrote:
> > On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> >  > > > Let's try to narrow it down to what the interaction is. Are you
> >  > > > using something like acpi_sleep=s3_bios or similar?
> >  > >
> >  > > No. Not additional command line option except for resume=/dev/sda3
> >  > > reboot=bios
> >  >
> >  > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need
> >  > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with
> >  > echo mem > /sys/power/state.
> >
> >  Cool, glad to hear at least one success report. :)
>
> STR is always working on my X60s. No green screen, no hang. Both s2ram
> and "echo mem > /sys/power/state". It's STD that's having problem.
>
> But strange thing is I could even restore console after STD even
> without agp and i915 module loaded, so I don't know how the console
> vga got saved and restored.

Your system (either your distro suspend/resume scripts or your platform) must 
be running the video BIOS at resume time, otherwise it would probably come 
back blank.

Jesse

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:

>  Your system (either your distro suspend/resume scripts or your platform) must
>  be running the video BIOS at resume time, otherwise it would probably come
>  back blank.

But I don't think so, unless acpid is doing just that. In my
suspend/resume event script, it's just doing a simple s2ram (without
options), and exit after resume.

Jeff.

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

[Jesse Barnes]

On Thursday, February 21, 2008 4:42 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <jesse.barnes@intel.com> 
wrote:
> >  Your system (either your distro suspend/resume scripts or your platform)
> > must be running the video BIOS at resume time, otherwise it would
> > probably come back blank.
>
> But I don't think so, unless acpid is doing just that. In my
> suspend/resume event script, it's just doing a simple s2ram (without
> options), and exit after resume.

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.

Jesse

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <jesse.barnes@intel.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.

Thanks,
Jeff.

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

[Jesse Barnes]

On Thursday, February 21, 2008 4:52 pm Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <jesse.barnes@intel.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

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 9:02 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:

>  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.

That's the main reason for moving to the X series. It's seems to work
very well on Linux.

Thanks,
Jeff.

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

[Linus Torvalds]

On Thu, 21 Feb 2008, Jesse Barnes wrote:
> 
> 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.

Well, I'm also hoping that eventually we could even just not do the VT 
switch at all, and the kernel can treat X as "just another user process" 
that it freezes.

At least from a mode setting standpoint.

We'd still want to make sure that X repaints the screen if the contents 
were lost, of course. And this is going to depend very intimately on the 
type of graphics card and whether the video RAM is saved by STR or not - 
for the Intel integrated graphics kind of situation, the video RAM will be 
refreshed along with all the other memory, but for other cards we may end 
up having to do the VT switch not so much for modesetting reasons as just 
a way to get X to save and restore all the *other* state.

How close is the i915 driver from not having to even signal X? Or is that 
just a pipedream of mine?

			Linus

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

[Jesse Barnes]

On Thursday, February 21, 2008 5:28 pm Linus Torvalds wrote:
> On Thu, 21 Feb 2008, Jesse Barnes wrote:
> > 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.
>
> Well, I'm also hoping that eventually we could even just not do the VT
> switch at all, and the kernel can treat X as "just another user process"
> that it freezes.

Hell yes.

> At least from a mode setting standpoint.
>
> We'd still want to make sure that X repaints the screen if the contents
> were lost, of course. And this is going to depend very intimately on the
> type of graphics card and whether the video RAM is saved by STR or not -
> for the Intel integrated graphics kind of situation, the video RAM will be
> refreshed along with all the other memory, but for other cards we may end
> up having to do the VT switch not so much for modesetting reasons as just
> a way to get X to save and restore all the *other* state.

Drivers supporting kernel modesetting will have to stuff their VRAM somewhere, 
yeah.  Hopefully X won't have much to do with it though...

> How close is the i915 driver from not having to even signal X? Or is that
> just a pipedream of mine?

It's there in the modesetting tree (though the requisite changes to avoid VT 
notification aren't done, it should all work fine).

Jesse

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

[Matthew Garrett]

On Fri, Feb 22, 2008 at 08:42:15AM +0800, Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> 
> >  Your system (either your distro suspend/resume scripts or your platform) must
> >  be running the video BIOS at resume time, otherwise it would probably come
> >  back blank.
> 
> But I don't think so, unless acpid is doing just that. In my
> suspend/resume event script, it's just doing a simple s2ram (without
> options), and exit after resume.

The s2ram command has a built-in whitelist used to set up video 
rePOSTing. If you want to test, reboot and do

echo mem >/sys/power/state

without i915 being loaded. If you get a console back on resume then the 
platform is reinitialising video for you, but otherwise it's your 
userspace.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Ingo Molnar]

* Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> The s2ram command has a built-in whitelist used to set up video 
> rePOSTing. If you want to test, reboot and do
> 
> echo mem >/sys/power/state
> 
> without i915 being loaded. If you get a console back on resume then 
> the platform is reinitialising video for you, but otherwise it's your 
> userspace.

btw., why isnt there an in-kernel whitelist, with perhaps a dynamic, 
convenient /debug/s2r/whitelist append-API for distros (and testers) to 
add more entries to the whitelist/blacklist? (for cases where the kernel 
whitelist has not caught up yet) Which would eventually converge to 
Utopia: s2ram that just works out of box.
 
This would be a lot more flexible (people could even temporarily extend 
the whitelist via rc.local if need to be, etc.), a lot more robust and a 
lot more user friendly than the "dont use /sys/power/state, rely on some 
user-space tool to work around bugs" approach.

Really, i couldnt make the s2ram API/quirks situation much worse even if 
i deliberately tried to design the whole code to be as hard to use and 
as confusing as possible :-/ These types of half-kernel half-userspace 
solutions usually result in constant finger-pointing and constant lag, 
and they result in about the crappiest user experience that is possible 
to achieve physically.

( Sorry about the strong words, while there's lots of good and positive
  development lately i havent seen much change in this particular area
  of s2ram in the past 1-2 years, and the whole chain is only as strong
  as the weakest link - so someone finally has to deliver this message
  to the cozy fire of s2r hackers while our testers and users are 
  standing out in the cold rain ... )

	Ingo

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

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Ingo Molnar wrote:
> 
> * Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
> > The s2ram command has a built-in whitelist used to set up video 
> > rePOSTing. If you want to test, reboot and do
> > 
> > echo mem >/sys/power/state
> > 
> > without i915 being loaded. If you get a console back on resume then 
> > the platform is reinitialising video for you, but otherwise it's your 
> > userspace.
> 
> btw., why isnt there an in-kernel whitelist, with perhaps a dynamic, 
> convenient /debug/s2r/whitelist append-API for distros (and testers) to 
> add more entries to the whitelist/blacklist? (for cases where the kernel 
> whitelist has not caught up yet) Which would eventually converge to 
> Utopia: s2ram that just works out of box.
>  
> This would be a lot more flexible (people could even temporarily extend 
> the whitelist via rc.local if need to be, etc.), a lot more robust and a 
> lot more user friendly than the "dont use /sys/power/state, rely on some 
> user-space tool to work around bugs" approach.
> 
> Really, i couldnt make the s2ram API/quirks situation much worse even if 
> i deliberately tried to design the whole code to be as hard to use and 
> as confusing as possible :-/ These types of half-kernel half-userspace 
> solutions usually result in constant finger-pointing and constant lag, 
> and they result in about the crappiest user experience that is possible 
> to achieve physically.
> 
> ( Sorry about the strong words, while there's lots of good and positive
>   development lately i havent seen much change in this particular area
>   of s2ram in the past 1-2 years, and the whole chain is only as strong
>   as the weakest link - so someone finally has to deliver this message
>   to the cozy fire of s2r hackers while our testers and users are 
>   standing out in the cold rain ... )

The problem with the whitelists is that they have to use quite a lot of data to
reliably match the system.  The s2ram whitelist is not 100% reliable, because
it uses too little information to distinguish different versions of the same
machine model, for example.

Plus, in an ideal world, we should be able to match all possible working
graphics/chipset/BIOS combinations and that would be quite a bit of a database.
Also, there are some quirks that need to be run from the user land, AFAICS
(eg. in an i86 real-mode compatible manner).

IMO, whitelisting is not a solution.  It's only a sort-of-working workaround
and as such it shouldn't be put into the kernel.

Thanks,
Rafael

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

[Linus Torvalds]

On Fri, 22 Feb 2008, Ingo Molnar wrote:
> 
> btw., why isnt there an in-kernel whitelist, with perhaps a dynamic, 
> convenient /debug/s2r/whitelist append-API for distros (and testers) to 
> add more entries to the whitelist/blacklist? (for cases where the kernel 
> whitelist has not caught up yet) Which would eventually converge to 
> Utopia: s2ram that just works out of box.

The big problem with that is
 - the people who know about the devices are usually not kernel people
 - the workarounds that the whitelist requires is quite often not a kernel 
   workaround.

In other words, the most common workarounds for the s2ram whitelist is 
usually to do things like running vbetool in user-level to do VGA register 
save/restore (VBE_POST and VGE_SAVE). Sure, the kernel could do that with 
usermodehelper etc, but s2ram also has those things as command line flags 
etc, so...

		Linus

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

[Matthew Garrett]

On Fri, Feb 22, 2008 at 02:06:15PM +0100, Ingo Molnar wrote:

> btw., why isnt there an in-kernel whitelist, with perhaps a dynamic, 
> convenient /debug/s2r/whitelist append-API for distros (and testers) to 
> add more entries to the whitelist/blacklist? (for cases where the kernel 
> whitelist has not caught up yet) Which would eventually converge to 
> Utopia: s2ram that just works out of box.

Because all of these video quirks are just workarounds for the fact that 
the kernel doesn't work properly. In general, you really don't want to 
call a real-mode video bios from the kernel, so punting it to userspace 
(and leaving the whitelisting there) is somewhat more straightforward. 
In addition, we can then extend the whitelist without requiring kernel 
upgrades.

> ( Sorry about the strong words, while there's lots of good and positive
>   development lately i havent seen much change in this particular area
>   of s2ram in the past 1-2 years, and the whole chain is only as strong
>   as the weakest link - so someone finally has to deliver this message
>   to the cozy fire of s2r hackers while our testers and users are 
>   standing out in the cold rain ... )

We've got i915 suspend/resume now, which already fixes this for a large 
number of users. Recent ATI is easy, now that we actually have specs for 
ATOM. The nouveau guys are almost at the point where we can do it for 
nvidia. That basically just leaves VIA.

The other s2r issues are pretty much just driver bugs at this point.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

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

[Ingo Molnar]

* Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> We've got i915 suspend/resume now, which already fixes this for a 
> large number of users. Recent ATI is easy, now that we actually have 
> specs for ATOM. The nouveau guys are almost at the point where we can 
> do it for nvidia. That basically just leaves VIA.
> 
> The other s2r issues are pretty much just driver bugs at this point.

ok - sounds good :-)

	Ingo

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

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> >  > > > Let's try to narrow it down to what the interaction is. Are you using
> >  > > > something like acpi_sleep=s3_bios or similar?
> >  > >
> >  > > No. Not additional command line option except for resume=/dev/sda3
> >  > > reboot=bios
> >  >
> >  > My laptop (a Toshiba satellite U305, intel 945GM chipset, used to need
> >  > s2ram -f -p -m to STR correctly. In 2.6.25-rc2 I can simply STR with
> >  > echo mem > /sys/power/state.
> >
> >  Cool, glad to hear at least one success report. :)
> 
> STR is always working on my X60s. No green screen, no hang. Both s2ram
> and "echo mem > /sys/power/state". It's STD that's having problem.
> 
> But strange thing is I could even restore console after STD even
> without agp and i915 module loaded, so I don't know how the console
> vga got saved and restored.

Jeff, can you please test hibernation with the patch I've just sent to Jesse
(reproduced below for convenience)?

Thanks,
Rafael

---
 drivers/char/drm/i915_drv.c |    5 +++--
 include/linux/suspend.h     |    2 ++
 kernel/power/disk.c         |   10 +++++++++-
 3 files changed, 14 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/char/drm/i915_drv.c
===================================================================
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
  *
  */
 
+#include <linux/suspend.h>
 #include "drmP.h"
 #include "drm.h"
 #include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_
 			   dev_priv->saveGR[0x18]);
 
 	/* Attribute controller registers */
+	inb(st01); /* switch back to index mode */
 	for (i = 0; i < 20; i++)
 		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
 	inb(st01); /* switch back to index mode */
@@ -366,9 +368,8 @@ static int i915_suspend(struct drm_devic
 
 	i915_save_vga(dev);
 
-	if (state.event == PM_EVENT_SUSPEND) {
+	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
 		/* Shut down the device */
-		pci_disable_device(dev->pdev);
 		pci_set_power_state(dev->pdev, PCI_D3hot);
 	}
 
Index: linux-2.6/include/linux/suspend.h
===================================================================
--- linux-2.6.orig/include/linux/suspend.h
+++ linux-2.6/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t
 
 extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
 extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
 #else /* CONFIG_HIBERNATION */
 static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
 static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_fre
 
 static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) {}
 static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
 #endif /* CONFIG_HIBERNATION */
 
 #ifdef CONFIG_PM_SLEEP
Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -24,7 +24,7 @@
 
 #include "power.h"
 
-
+static bool entering_sleep_state;
 static int noresume = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
 	if (!hibernation_ops)
 		return -ENOSYS;
 
+	entering_sleep_state = true;
 	/*
 	 * We have cancelled the power transition by running
 	 * hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
 	}
 	local_irq_enable();
 
+	entering_sleep_state = false;
 	/*
 	 * We don't need to reenable the nonboot CPUs or resume consoles, since
 	 * the system is going to be halted anyway.
@@ -427,6 +429,12 @@ int hibernation_platform_enter(void)
 	return error;
 }
 
+bool in_hibernation_power_off(void)
+{
+	return entering_sleep_state;
+}
+EXPORT_SYMBOL(in_hibernation_power_off);
+
 /**
  *	power_down - Shut the machine down for hibernation.
  *

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:

>  Jeff, can you please test hibernation with the patch I've just sent to Jesse
>  (reproduced below for convenience)?

Testing now.

Jeff.

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>
>  >  Jeff, can you please test hibernation with the patch I've just sent to Jesse
>  >  (reproduced below for convenience)?
>
>  Testing now.

Great news. It works. STD (platform) does not hang at suspend. And the
annoying green is gone! STR still works.


Thanks,
Jeff.

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

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Jeff Chua wrote:
> On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
> > On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> >
> >  >  Jeff, can you please test hibernation with the patch I've just sent to Jesse
> >  >  (reproduced below for convenience)?
> >
> >  Testing now.
> 
> Great news. It works. STD (platform) does not hang at suspend. And the
> annoying green is gone! STR still works.

Great, thanks for testing.

If Jesse confirms that it also works for him, I'll prepare a cleaner final fix
tomorrow.

Thanks,
Rafael

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

[Linus Torvalds]

On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
>  
> -	if (state.event == PM_EVENT_SUSPEND) {
> +	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {

I don't understand why hibernation just doesn't use a PM_EVENT_HIBERNATE, 
and be done with it?

Why should it be called PM_EVENT_SUSPEND when it isn't?

Adding some external global variables is absolutely the wrong way to fix 
this.

It's not even like there are very many drivers who actually care about 
"state.event" anyway: a 'git grep' returns just 35 users in the whole 
tree, so if this was done this ugly way just to avoid double-chcking the 
other cases that compare against PM_EVENT_SUSPEND, then it really wasn't 
worth it.

		Linus

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

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Linus Torvalds wrote:
> 
> On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> >  
> > -	if (state.event == PM_EVENT_SUSPEND) {
> > +	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
> 
> I don't understand why hibernation just doesn't use a PM_EVENT_HIBERNATE, 
> and be done with it?
> 
> Why should it be called PM_EVENT_SUSPEND when it isn't?
> 
> Adding some external global variables is absolutely the wrong way to fix 
> this.
> 
> It's not even like there are very many drivers who actually care about 
> "state.event" anyway: a 'git grep' returns just 35 users in the whole 
> tree, so if this was done this ugly way just to avoid double-chcking the 
> other cases that compare against PM_EVENT_SUSPEND, then it really wasn't 
> worth it.

Please relax, we're debugging the thing right now and the patch doesn't
even seem to help on the other affected box.

The issue appears to be more complicated than we initially thought.

Thanks,
Rafael

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

[Jesse Barnes]

On Thursday, February 21, 2008 4:54 pm Rafael J. Wysocki wrote:
> On Friday, 22 of February 2008, Linus Torvalds wrote:
> > On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> > > -	if (state.event == PM_EVENT_SUSPEND) {
> > > +	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
> >
> > I don't understand why hibernation just doesn't use a PM_EVENT_HIBERNATE,
> > and be done with it?
> >
> > Why should it be called PM_EVENT_SUSPEND when it isn't?
> >
> > Adding some external global variables is absolutely the wrong way to fix
> > this.
> >
> > It's not even like there are very many drivers who actually care about
> > "state.event" anyway: a 'git grep' returns just 35 users in the whole
> > tree, so if this was done this ugly way just to avoid double-chcking the
> > other cases that compare against PM_EVENT_SUSPEND, then it really wasn't
> > worth it.
>
> Please relax, we're debugging the thing right now and the patch doesn't
> even seem to help on the other affected box.

Actually, looks like I forgot to reboot between tests (just rmmod'd & 
modprobed i915), your patch actually does work.

However, making new PM event messages might be a good thing anyway, assuming 
Linus takes it for 2.6.25, since it should make the migration to ->hibernate 
callbacks easier.

Jesse

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

[Jesse Barnes]

On Thursday, February 21, 2008 5:13 pm Jesse Barnes wrote:
> On Thursday, February 21, 2008 4:54 pm Rafael J. Wysocki wrote:
> > On Friday, 22 of February 2008, Linus Torvalds wrote:
> > > On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> > > > -	if (state.event == PM_EVENT_SUSPEND) {
> > > > +	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off())
> > > > {
> > >
> > > I don't understand why hibernation just doesn't use a
> > > PM_EVENT_HIBERNATE, and be done with it?
> > >
> > > Why should it be called PM_EVENT_SUSPEND when it isn't?
> > >
> > > Adding some external global variables is absolutely the wrong way to
> > > fix this.
> > >
> > > It's not even like there are very many drivers who actually care about
> > > "state.event" anyway: a 'git grep' returns just 35 users in the whole
> > > tree, so if this was done this ugly way just to avoid double-chcking
> > > the other cases that compare against PM_EVENT_SUSPEND, then it really
> > > wasn't worth it.
> >
> > Please relax, we're debugging the thing right now and the patch doesn't
> > even seem to help on the other affected box.
>
> Actually, looks like I forgot to reboot between tests (just rmmod'd &
> modprobed i915), your patch actually does work.
>
> However, making new PM event messages might be a good thing anyway,
> assuming Linus takes it for 2.6.25, since it should make the migration to
> ->hibernate callbacks easier.

Rafael, I'd actually prefer these changes to the i915 driver.  One is to avoid 
the "green screen" problem and the other is to actually save state at 
hibernate time in case we don't do a POST coming out of S4 (probably not 
common but hey).

Jesse

Make sure hibernation works by not shutting down the video device during 
hibernation power off.  This is important because later stages of the 
hibernation cycle end up touching the video device, which may cause a hang if 
it was disabled early on.  Also make sure the restoration correctly restores 
the AR registers by flipping the ARX register into index mode before doing 
anything.

Depends on Rafael's patch which exports hibernation state to drivers.

Signed-off-by:  Jesse Barnes <jesse.barnes@intel.com>

diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 35758a6..5e73869 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
  *
  */
 
+#include <linux/suspend.h>
 #include "drmP.h"
 #include "drm.h"
 #include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_device *dev)
 			   dev_priv->saveGR[0x18]);
 
 	/* Attribute controller registers */
+	inb(st01);
 	for (i = 0; i < 20; i++)
 		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
 	inb(st01); /* switch back to index mode */
@@ -364,8 +366,8 @@ static int i915_suspend(struct drm_device *dev)
 	i915_save_vga(dev);
 
 	/* Shut down the device */
-	pci_disable_device(dev->pdev);
-	pci_set_power_state(dev->pdev, PCI_D3hot);
+	if (!in_hibernation_power_off())
+		pci_set_power_state(dev->pdev, PCI_D3hot);
 
 	return 0;
 }

i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 5:13 pm Jesse Barnes wrote:
> > On Thursday, February 21, 2008 4:54 pm Rafael J. Wysocki wrote:
> > > On Friday, 22 of February 2008, Linus Torvalds wrote:
> > > > On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> > > > > -	if (state.event == PM_EVENT_SUSPEND) {
> > > > > +	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off())
> > > > > {
> > > >
> > > > I don't understand why hibernation just doesn't use a
> > > > PM_EVENT_HIBERNATE, and be done with it?
> > > >
> > > > Why should it be called PM_EVENT_SUSPEND when it isn't?
> > > >
> > > > Adding some external global variables is absolutely the wrong way to
> > > > fix this.
> > > >
> > > > It's not even like there are very many drivers who actually care about
> > > > "state.event" anyway: a 'git grep' returns just 35 users in the whole
> > > > tree, so if this was done this ugly way just to avoid double-chcking
> > > > the other cases that compare against PM_EVENT_SUSPEND, then it really
> > > > wasn't worth it.
> > >
> > > Please relax, we're debugging the thing right now and the patch doesn't
> > > even seem to help on the other affected box.
> >
> > Actually, looks like I forgot to reboot between tests (just rmmod'd &
> > modprobed i915), your patch actually does work.
> >
> > However, making new PM event messages might be a good thing anyway,
> > assuming Linus takes it for 2.6.25, since it should make the migration to
> > ->hibernate callbacks easier.
> 
> Rafael, I'd actually prefer these changes to the i915 driver.  One is to avoid 
> the "green screen" problem and the other is to actually save state at 
> hibernate time in case we don't do a POST coming out of S4 (probably not 
> common but hey).

Below is a patch that introduces PM_EVENT_HIBERNATE as requested by Linus
and (hopefully) makes hibernation with i915 work correctly.

I must admit I don't feel very comfortable introduces PM_EVENT_HIBERNATE at
this point, since such changes tend to introduce unexpected issues all over the
place, but hopefully this time it won't break anything.

I have tested it on the nx6325.

Please review and tell me if it looks good.

Jesse and Jeff, please check if your boxes hibernate correctly with this patch
applied.

Thanks,
Rafael

---
 Documentation/power/devices.txt        |   13 ++++++++-----
 drivers/ata/ahci.c                     |    3 ++-
 drivers/ata/ata_piix.c                 |    3 ++-
 drivers/ata/libata-core.c              |    2 +-
 drivers/char/drm/i915_drv.c            |    4 +++-
 drivers/ide/ppc/pmac.c                 |    6 ++++--
 drivers/macintosh/mediabay.c           |    4 +++-
 drivers/pci/pci.c                      |    1 +
 drivers/scsi/aic7xxx/aic79xx_osm_pci.c |    2 +-
 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c |    2 +-
 drivers/scsi/mesh.c                    |    1 +
 drivers/scsi/sd.c                      |    5 +++--
 drivers/usb/host/sl811-hcd.c           |    1 +
 drivers/usb/host/u132-hcd.c            |   10 +++++++---
 drivers/video/chipsfb.c                |    3 ++-
 drivers/video/nvidia/nvidia.c          |    3 ++-
 include/linux/pm.h                     |    5 +++++
 kernel/power/disk.c                    |    4 ++--
 net/rfkill/rfkill.c                    |    3 ++-
 19 files changed, 51 insertions(+), 24 deletions(-)

Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -391,7 +391,7 @@ int hibernation_platform_enter(void)
 		goto Close;
 
 	suspend_console();
-	error = device_suspend(PMSG_SUSPEND);
+	error = device_suspend(PMSG_HIBERNATE);
 	if (error)
 		goto Resume_console;
 
@@ -404,7 +404,7 @@ int hibernation_platform_enter(void)
 		goto Finish;
 
 	local_irq_disable();
-	error = device_power_down(PMSG_SUSPEND);
+	error = device_power_down(PMSG_HIBERNATE);
 	if (!error) {
 		hibernation_ops->enter();
 		/* We should never get here */
Index: linux-2.6/include/linux/pm.h
===================================================================
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -143,6 +143,9 @@ typedef struct pm_message {
  * 		the upcoming system state (such as PCI_D3hot), and enable
  * 		wakeup events as appropriate.
  *
+ * HIBERNATE	Enter a low power device state appropriate for the hibernation
+ * 		state (eg. ACPI S4) and enable wakeup events as appropriate.
+ *
  * FREEZE	Quiesce operations so that a consistent image can be saved;
  * 		but do NOT otherwise enter a low power device state, and do
  * 		NOT emit system wakeup events.
@@ -167,10 +170,12 @@ typedef struct pm_message {
 #define PM_EVENT_FREEZE 1
 #define PM_EVENT_SUSPEND 2
 #define PM_EVENT_PRETHAW 3
+#define PM_EVENT_HIBERNATE 4
 
 #define PMSG_FREEZE	((struct pm_message){ .event = PM_EVENT_FREEZE, })
 #define PMSG_PRETHAW	((struct pm_message){ .event = PM_EVENT_PRETHAW, })
 #define PMSG_SUSPEND	((struct pm_message){ .event = PM_EVENT_SUSPEND, })
+#define PMSG_HIBERNATE	((struct pm_message){ .event = PM_EVENT_HIBERNATE, })
 #define PMSG_ON		((struct pm_message){ .event = PM_EVENT_ON, })
 
 struct dev_pm_info {
Index: linux-2.6/drivers/char/drm/i915_drv.c
===================================================================
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
 			   dev_priv->saveGR[0x18]);
 
 	/* Attribute controller registers */
+	inb(st01);
 	for (i = 0; i < 20; i++)
 		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
 	inb(st01); /* switch back to index mode */
@@ -369,7 +370,8 @@ static int i915_suspend(struct drm_devic
 	if (state.event == PM_EVENT_SUSPEND) {
 		/* Shut down the device */
 		pci_disable_device(dev->pdev);
-		pci_set_power_state(dev->pdev, PCI_D3hot);
+		pci_set_power_state(dev->pdev,
+					pci_choose_state(dev->pdev, state));
 	}
 
 	return 0;
Index: linux-2.6/drivers/ata/ahci.c
===================================================================
--- linux-2.6.orig/drivers/ata/ahci.c
+++ linux-2.6/drivers/ata/ahci.c
@@ -1932,7 +1932,8 @@ static int ahci_pci_device_suspend(struc
 	void __iomem *mmio = host->iomap[AHCI_PCI_BAR];
 	u32 ctl;
 
-	if (mesg.event == PM_EVENT_SUSPEND) {
+	if (mesg.event == PM_EVENT_SUSPEND
+	    || mesg.event == PM_EVENT_HIBERNATE) {
 		/* AHCI spec rev1.1 section 8.3.3:
 		 * Software must disable interrupts prior to requesting a
 		 * transition of the HBA to D3 state.
Index: linux-2.6/drivers/ata/ata_piix.c
===================================================================
--- linux-2.6.orig/drivers/ata/ata_piix.c
+++ linux-2.6/drivers/ata/ata_piix.c
@@ -1339,7 +1339,8 @@ static int piix_pci_device_suspend(struc
 	 * cycles and power trying to do something to the sleeping
 	 * beauty.
 	 */
-	if (piix_broken_suspend() && mesg.event == PM_EVENT_SUSPEND) {
+	if (piix_broken_suspend() && (mesg.event == PM_EVENT_SUSPEND
+	    || mesg.event == PM_EVENT_HIBERNATE)) {
 		pci_save_state(pdev);
 
 		/* mark its power state as "unknown", since we don't
Index: linux-2.6/drivers/ata/libata-core.c
===================================================================
--- linux-2.6.orig/drivers/ata/libata-core.c
+++ linux-2.6/drivers/ata/libata-core.c
@@ -7368,7 +7368,7 @@ void ata_pci_device_do_suspend(struct pc
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event == PM_EVENT_SUSPEND || mesg.event == PM_EVENT_HIBERNATE)
 		pci_set_power_state(pdev, PCI_D3hot);
 }
 
Index: linux-2.6/drivers/ide/ppc/pmac.c
===================================================================
--- linux-2.6.orig/drivers/ide/ppc/pmac.c
+++ linux-2.6/drivers/ide/ppc/pmac.c
@@ -1254,7 +1254,8 @@ pmac_ide_macio_suspend(struct macio_dev 
 	int		rc = 0;
 
 	if (mesg.event != mdev->ofdev.dev.power.power_state.event
-			&& mesg.event == PM_EVENT_SUSPEND) {
+			&& (mesg.event == PM_EVENT_SUSPEND
+			|| mesg.event == PM_EVENT_HIBERNATE)) {
 		rc = pmac_ide_do_suspend(hwif);
 		if (rc == 0)
 			mdev->ofdev.dev.power.power_state = mesg;
@@ -1364,7 +1365,8 @@ pmac_ide_pci_suspend(struct pci_dev *pde
 	int		rc = 0;
 	
 	if (mesg.event != pdev->dev.power.power_state.event
-			&& mesg.event == PM_EVENT_SUSPEND) {
+			&& (mesg.event == PM_EVENT_SUSPEND
+			|| mesg.event == PM_EVENT_HIBERNATE)) {
 		rc = pmac_ide_do_suspend(hwif);
 		if (rc == 0)
 			pdev->dev.power.power_state = mesg;
Index: linux-2.6/drivers/macintosh/mediabay.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/mediabay.c
+++ linux-2.6/drivers/macintosh/mediabay.c
@@ -698,7 +698,9 @@ static int media_bay_suspend(struct maci
 {
 	struct media_bay_info	*bay = macio_get_drvdata(mdev);
 
-	if (state.event != mdev->ofdev.dev.power.power_state.event && state.event == PM_EVENT_SUSPEND) {
+	if (state.event != mdev->ofdev.dev.power.power_state.event
+	    && (state.event == PM_EVENT_SUSPEND
+	    || state.event == PM_EVENT_HIBERNATE)) {
 		down(&bay->lock);
 		bay->sleeping = 1;
 		set_mb_power(bay, 0);
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
 	case PM_EVENT_PRETHAW:
 		/* REVISIT both freeze and pre-thaw "should" use D0 */
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 		return PCI_D3hot;
 	default:
 		printk("Unrecognized suspend event %d\n", state.event);
Index: linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
===================================================================
--- linux-2.6.orig/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
+++ linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
@@ -89,7 +89,7 @@ ahd_linux_pci_dev_suspend(struct pci_dev
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event == PM_EVENT_SUSPEND || mesg.event == PM_EVENT_HIBERNATE)
 		pci_set_power_state(pdev, PCI_D3hot);
 
 	return rc;
Index: linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
===================================================================
--- linux-2.6.orig/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
+++ linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
@@ -134,7 +134,7 @@ ahc_linux_pci_dev_suspend(struct pci_dev
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event == PM_EVENT_SUSPEND || mesg.event == PM_EVENT_HIBERNATE)
 		pci_set_power_state(pdev, PCI_D3hot);
 
 	return rc;
Index: linux-2.6/drivers/scsi/mesh.c
===================================================================
--- linux-2.6.orig/drivers/scsi/mesh.c
+++ linux-2.6/drivers/scsi/mesh.c
@@ -1759,6 +1759,7 @@ static int mesh_suspend(struct macio_dev
 
 	switch (mesg.event) {
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 	case PM_EVENT_FREEZE:
 		break;
 	default:
Index: linux-2.6/drivers/scsi/sd.c
===================================================================
--- linux-2.6.orig/drivers/scsi/sd.c
+++ linux-2.6/drivers/scsi/sd.c
@@ -1835,8 +1835,9 @@ static int sd_suspend(struct device *dev
 			goto done;
 	}
 
-	if (mesg.event == PM_EVENT_SUSPEND &&
-	    sdkp->device->manage_start_stop) {
+	if ((mesg.event == PM_EVENT_SUSPEND
+	     || mesg.event == PM_EVENT_HIBERNATE)
+	    && sdkp->device->manage_start_stop) {
 		sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
 		ret = sd_start_stop_device(sdkp, 0);
 	}
Index: linux-2.6/drivers/usb/host/sl811-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/sl811-hcd.c
+++ linux-2.6/drivers/usb/host/sl811-hcd.c
@@ -1766,6 +1766,7 @@ sl811h_suspend(struct platform_device *d
 		retval = sl811h_bus_suspend(hcd);
 		break;
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 	case PM_EVENT_PRETHAW:		/* explicitly discard hw state */
 		port_power(sl811, 0);
 		break;
Index: linux-2.6/drivers/usb/host/u132-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/u132-hcd.c
+++ linux-2.6/drivers/usb/host/u132-hcd.c
@@ -3214,14 +3214,18 @@ static int u132_suspend(struct platform_
                 return -ESHUTDOWN;
         } else {
                 int retval = 0;
-                if (state.event == PM_EVENT_FREEZE) {
+
+		switch (state.event) {
+		case PM_EVENT_FREEZE:
                         retval = u132_bus_suspend(hcd);
-                } else if (state.event == PM_EVENT_SUSPEND) {
+			break;
+		case PM_EVENT_SUSPEND:
+		case PM_EVENT_HIBERNATE:
                         int ports = MAX_U132_PORTS;
                         while (ports-- > 0) {
                                 port_power(u132, ports, 0);
                         }
-                }
+			break;
                 if (retval == 0)
                         pdev->dev.power.power_state = state;
                 return retval;
Index: linux-2.6/drivers/video/chipsfb.c
===================================================================
--- linux-2.6.orig/drivers/video/chipsfb.c
+++ linux-2.6/drivers/video/chipsfb.c
@@ -459,7 +459,8 @@ static int chipsfb_pci_suspend(struct pc
 
 	if (state.event == pdev->dev.power.power_state.event)
 		return 0;
-	if (state.event != PM_EVENT_SUSPEND)
+	if (state.event != PM_EVENT_SUSPEND
+	    && state.event != PM_EVENT_HIBERNATE)
 		goto done;
 
 	acquire_console_sem();
Index: linux-2.6/drivers/video/nvidia/nvidia.c
===================================================================
--- linux-2.6.orig/drivers/video/nvidia/nvidia.c
+++ linux-2.6/drivers/video/nvidia/nvidia.c
@@ -1066,7 +1066,8 @@ static int nvidiafb_suspend(struct pci_d
 	acquire_console_sem();
 	par->pm_state = mesg.event;
 
-	if (mesg.event == PM_EVENT_SUSPEND) {
+	if (mesg.event == PM_EVENT_SUSPEND
+	    || mesg.event == PM_EVENT_HIBERNATE) {
 		fb_set_suspend(info, 1);
 		nvidiafb_blank(FB_BLANK_POWERDOWN, info);
 		nvidia_write_regs(par, &par->SavedReg);
Index: linux-2.6/net/rfkill/rfkill.c
===================================================================
--- linux-2.6.orig/net/rfkill/rfkill.c
+++ linux-2.6/net/rfkill/rfkill.c
@@ -232,7 +232,8 @@ static int rfkill_suspend(struct device 
 	struct rfkill *rfkill = to_rfkill(dev);
 
 	if (dev->power.power_state.event != state.event) {
-		if (state.event == PM_EVENT_SUSPEND) {
+		if (state.event == PM_EVENT_SUSPEND
+		    || state.event == PM_EVENT_HIBERNATE) {
 			mutex_lock(&rfkill->mutex);
 
 			if (rfkill->state == RFKILL_STATE_ON)
Index: linux-2.6/Documentation/power/devices.txt
===================================================================
--- linux-2.6.orig/Documentation/power/devices.txt
+++ linux-2.6/Documentation/power/devices.txt
@@ -310,9 +310,12 @@ used with suspend-to-disk:
     PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power
 	state.  When used with system sleep states like "suspend-to-RAM" or
 	"standby", the upcoming resume() call will often be able to rely on
-	state kept in hardware, or issue system wakeup events.  When used
-	instead with suspend-to-disk, few devices support this capability;
-	most are completely powered off.
+	state kept in hardware, or issue system wakeup events.
+
+    PM_EVENT_HIBERNATE -- Put hardware into a low-power state and enable wakeup
+	events as appropriate.  It is only used with hibernation
+	(suspend-to-disk) and few devices are able to wake up the system from
+	this state; most are completely powered off.
 
     PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into
 	any low power mode.  A system snapshot is about to be taken, often
@@ -329,8 +332,8 @@ used with suspend-to-disk:
 	wakeup events nor DMA are allowed.
 
 To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or
-the similarly named APM states, only PM_EVENT_SUSPEND is used; for "Suspend
-to Disk" (STD, hibernate, ACPI S4), all of those event codes are used.
+the similarly named APM states, only PM_EVENT_SUSPEND is used; the other event
+codes are used for hibernation ("Suspend to Disk", STD, ACPI S4).
 
 There's also PM_EVENT_ON, a value which never appears as a suspend event
 but is sometimes used to record the "not suspended" device state.

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Linus Torvalds]

On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:

> --- linux-2.6.orig/drivers/char/drm/i915_drv.c
> +++ linux-2.6/drivers/char/drm/i915_drv.c
> @@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
>  			   dev_priv->saveGR[0x18]);
>  
>  	/* Attribute controller registers */
> +	inb(st01);
>  	for (i = 0; i < 20; i++)
>  		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
>  	inb(st01); /* switch back to index mode */

I'm doing this part separately, please drop it - it has nothing to do with 
the rest of the patch.

I'd also suggest that you just add a helper function like

	int pm_event_powerdown(struct pm_message mesg)
	{
		return mesg.event >= PM_EVENT_SUSPEND;
	}

or something, so that you can have code like

	if (pm_event_powerdown(mesg))
		pci_set_power_state(pdev, PCI_D3hot);

instead of the test for EVENT_SUSPEND/HIBERNATE explicitly.

Of course, the places that already do a switch-statement are much better 
kept that way and just add PM_EVENT_HIBERNATE to the list.

> --- linux-2.6.orig/drivers/pci/pci.c
> +++ linux-2.6/drivers/pci/pci.c
> @@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
>  	case PM_EVENT_PRETHAW:
>  		/* REVISIT both freeze and pre-thaw "should" use D0 */
>  	case PM_EVENT_SUSPEND:
> +	case PM_EVENT_HIBERNATE:
>  		return PCI_D3hot;

Didn't you miss the apci_pci_choose_state() thing that also needs this 
extension?

> Index: linux-2.6/drivers/usb/host/u132-hcd.c
> ===================================================================
> --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> +++ linux-2.6/drivers/usb/host/u132-hcd.c
> @@ -3214,14 +3214,18 @@ static int u132_suspend(struct platform_
>                  return -ESHUTDOWN;
>          } else {
>                  int retval = 0;
> -                if (state.event == PM_EVENT_FREEZE) {
> +
> +		switch (state.event) {
> +		case PM_EVENT_FREEZE:
>                          retval = u132_bus_suspend(hcd);
> -                } else if (state.event == PM_EVENT_SUSPEND) {
> +			break;
> +		case PM_EVENT_SUSPEND:
> +		case PM_EVENT_HIBERNATE:
>                          int ports = MAX_U132_PORTS;
>                          while (ports-- > 0) {
>                                  port_power(u132, ports, 0);
>                          }
> -                }
> +			break;
>                  if (retval == 0)
>                          pdev->dev.power.power_state = state;
>                  return retval;

Looks like a missing close-brace to me there - you removed the final '}'.

Or am I blind?

Apart from those issues it looks fine to me.

			Linus

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Rafael J. Wysocki]

On Saturday, 23 of February 2008, Linus Torvalds wrote:
> 
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> 
> > --- linux-2.6.orig/drivers/char/drm/i915_drv.c
> > +++ linux-2.6/drivers/char/drm/i915_drv.c
> > @@ -222,6 +222,7 @@ static void i915_restore_vga(struct drm_
> >  			   dev_priv->saveGR[0x18]);
> >  
> >  	/* Attribute controller registers */
> > +	inb(st01);
> >  	for (i = 0; i < 20; i++)
> >  		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
> >  	inb(st01); /* switch back to index mode */
> 
> I'm doing this part separately, please drop it - it has nothing to do with 
> the rest of the patch.

Dropped.

> I'd also suggest that you just add a helper function like
> 
> 	int pm_event_powerdown(struct pm_message mesg)
> 	{
> 		return mesg.event >= PM_EVENT_SUSPEND;
> 	}
> 
> or something, so that you can have code like
> 
> 	if (pm_event_powerdown(mesg))
> 		pci_set_power_state(pdev, PCI_D3hot);
> 
> instead of the test for EVENT_SUSPEND/HIBERNATE explicitly.

In the revised patch below I redefined the PM_EVENT_* things as flags so
that I can "or" them and defined PM_EVENT_SLEEP in analogy with
CONFIG_PM_SLEEP.

> Of course, the places that already do a switch-statement are much better 
> kept that way and just add PM_EVENT_HIBERNATE to the list.
> 
> > --- linux-2.6.orig/drivers/pci/pci.c
> > +++ linux-2.6/drivers/pci/pci.c
> > @@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
> >  	case PM_EVENT_PRETHAW:
> >  		/* REVISIT both freeze and pre-thaw "should" use D0 */
> >  	case PM_EVENT_SUSPEND:
> > +	case PM_EVENT_HIBERNATE:
> >  		return PCI_D3hot;
> 
> Didn't you miss the apci_pci_choose_state() thing that also needs this 
> extension?

No, I didn't.  That one operates on the ACPI D* states.

> > Index: linux-2.6/drivers/usb/host/u132-hcd.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> > +++ linux-2.6/drivers/usb/host/u132-hcd.c
> > @@ -3214,14 +3214,18 @@ static int u132_suspend(struct platform_
> >                  return -ESHUTDOWN;
> >          } else {
> >                  int retval = 0;
> > -                if (state.event == PM_EVENT_FREEZE) {
> > +
> > +		switch (state.event) {
> > +		case PM_EVENT_FREEZE:
> >                          retval = u132_bus_suspend(hcd);
> > -                } else if (state.event == PM_EVENT_SUSPEND) {
> > +			break;
> > +		case PM_EVENT_SUSPEND:
> > +		case PM_EVENT_HIBERNATE:
> >                          int ports = MAX_U132_PORTS;
> >                          while (ports-- > 0) {
> >                                  port_power(u132, ports, 0);
> >                          }
> > -                }
> > +			break;
> >                  if (retval == 0)
> >                          pdev->dev.power.power_state = state;
> >                  return retval;
> 
> Looks like a missing close-brace to me there - you removed the final '}'.
> 
> Or am I blind?

No, you aren't. :-)

> Apart from those issues it looks fine to me.

OK, please have a look at the modified patch below.

Thanks,
Rafael

---
 Documentation/power/devices.txt        |   13 ++++++++-----
 drivers/ata/ahci.c                     |    2 +-
 drivers/ata/ata_piix.c                 |    2 +-
 drivers/ata/libata-core.c              |    2 +-
 drivers/ide/ppc/pmac.c                 |    4 ++--
 drivers/macintosh/mediabay.c           |    3 ++-
 drivers/pci/pci.c                      |    1 +
 drivers/scsi/aic7xxx/aic79xx_osm_pci.c |    2 +-
 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c |    2 +-
 drivers/scsi/mesh.c                    |    1 +
 drivers/scsi/sd.c                      |    3 +--
 drivers/usb/host/sl811-hcd.c           |    1 +
 drivers/usb/host/u132-hcd.c            |   11 ++++++++---
 drivers/video/chipsfb.c                |    2 +-
 drivers/video/nvidia/nvidia.c          |    2 +-
 include/linux/pm.h                     |    9 ++++++++-
 kernel/power/disk.c                    |    4 ++--
 net/rfkill/rfkill.c                    |    2 +-
 18 files changed, 42 insertions(+), 24 deletions(-)

Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -391,7 +391,7 @@ int hibernation_platform_enter(void)
 		goto Close;
 
 	suspend_console();
-	error = device_suspend(PMSG_SUSPEND);
+	error = device_suspend(PMSG_HIBERNATE);
 	if (error)
 		goto Resume_console;
 
@@ -404,7 +404,7 @@ int hibernation_platform_enter(void)
 		goto Finish;
 
 	local_irq_disable();
-	error = device_power_down(PMSG_SUSPEND);
+	error = device_power_down(PMSG_HIBERNATE);
 	if (!error) {
 		hibernation_ops->enter();
 		/* We should never get here */
Index: linux-2.6/include/linux/pm.h
===================================================================
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -143,6 +143,9 @@ typedef struct pm_message {
  * 		the upcoming system state (such as PCI_D3hot), and enable
  * 		wakeup events as appropriate.
  *
+ * HIBERNATE	Enter a low power device state appropriate for the hibernation
+ * 		state (eg. ACPI S4) and enable wakeup events as appropriate.
+ *
  * FREEZE	Quiesce operations so that a consistent image can be saved;
  * 		but do NOT otherwise enter a low power device state, and do
  * 		NOT emit system wakeup events.
@@ -166,11 +169,15 @@ typedef struct pm_message {
 #define PM_EVENT_ON 0
 #define PM_EVENT_FREEZE 1
 #define PM_EVENT_SUSPEND 2
-#define PM_EVENT_PRETHAW 3
+#define PM_EVENT_HIBERNATE 4
+#define PM_EVENT_PRETHAW 8
+
+#define PM_EVENT_SLEEP	(PM_EVENT_SUSPEND | PM_EVENT_HIBERNATE)
 
 #define PMSG_FREEZE	((struct pm_message){ .event = PM_EVENT_FREEZE, })
 #define PMSG_PRETHAW	((struct pm_message){ .event = PM_EVENT_PRETHAW, })
 #define PMSG_SUSPEND	((struct pm_message){ .event = PM_EVENT_SUSPEND, })
+#define PMSG_HIBERNATE	((struct pm_message){ .event = PM_EVENT_HIBERNATE, })
 #define PMSG_ON		((struct pm_message){ .event = PM_EVENT_ON, })
 
 struct dev_pm_info {
Index: linux-2.6/drivers/ata/ahci.c
===================================================================
--- linux-2.6.orig/drivers/ata/ahci.c
+++ linux-2.6/drivers/ata/ahci.c
@@ -1932,7 +1932,7 @@ static int ahci_pci_device_suspend(struc
 	void __iomem *mmio = host->iomap[AHCI_PCI_BAR];
 	u32 ctl;
 
-	if (mesg.event == PM_EVENT_SUSPEND) {
+	if (mesg.event & PM_EVENT_SLEEP) {
 		/* AHCI spec rev1.1 section 8.3.3:
 		 * Software must disable interrupts prior to requesting a
 		 * transition of the HBA to D3 state.
Index: linux-2.6/drivers/ata/ata_piix.c
===================================================================
--- linux-2.6.orig/drivers/ata/ata_piix.c
+++ linux-2.6/drivers/ata/ata_piix.c
@@ -1339,7 +1339,7 @@ static int piix_pci_device_suspend(struc
 	 * cycles and power trying to do something to the sleeping
 	 * beauty.
 	 */
-	if (piix_broken_suspend() && mesg.event == PM_EVENT_SUSPEND) {
+	if (piix_broken_suspend() && (mesg.event & PM_EVENT_SLEEP)) {
 		pci_save_state(pdev);
 
 		/* mark its power state as "unknown", since we don't
Index: linux-2.6/drivers/ata/libata-core.c
===================================================================
--- linux-2.6.orig/drivers/ata/libata-core.c
+++ linux-2.6/drivers/ata/libata-core.c
@@ -7368,7 +7368,7 @@ void ata_pci_device_do_suspend(struct pc
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event & PM_EVENT_SLEEP)
 		pci_set_power_state(pdev, PCI_D3hot);
 }
 
Index: linux-2.6/drivers/ide/ppc/pmac.c
===================================================================
--- linux-2.6.orig/drivers/ide/ppc/pmac.c
+++ linux-2.6/drivers/ide/ppc/pmac.c
@@ -1254,7 +1254,7 @@ pmac_ide_macio_suspend(struct macio_dev 
 	int		rc = 0;
 
 	if (mesg.event != mdev->ofdev.dev.power.power_state.event
-			&& mesg.event == PM_EVENT_SUSPEND) {
+			&& (mesg.event & PM_EVENT_SLEEP)) {
 		rc = pmac_ide_do_suspend(hwif);
 		if (rc == 0)
 			mdev->ofdev.dev.power.power_state = mesg;
@@ -1364,7 +1364,7 @@ pmac_ide_pci_suspend(struct pci_dev *pde
 	int		rc = 0;
 	
 	if (mesg.event != pdev->dev.power.power_state.event
-			&& mesg.event == PM_EVENT_SUSPEND) {
+			&& (mesg.event & PM_EVENT_SLEEP)) {
 		rc = pmac_ide_do_suspend(hwif);
 		if (rc == 0)
 			pdev->dev.power.power_state = mesg;
Index: linux-2.6/drivers/macintosh/mediabay.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/mediabay.c
+++ linux-2.6/drivers/macintosh/mediabay.c
@@ -698,7 +698,8 @@ static int media_bay_suspend(struct maci
 {
 	struct media_bay_info	*bay = macio_get_drvdata(mdev);
 
-	if (state.event != mdev->ofdev.dev.power.power_state.event && state.event == PM_EVENT_SUSPEND) {
+	if (state.event != mdev->ofdev.dev.power.power_state.event
+	    && (state.event & PM_EVENT_SLEEP)) {
 		down(&bay->lock);
 		bay->sleeping = 1;
 		set_mb_power(bay, 0);
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
 	case PM_EVENT_PRETHAW:
 		/* REVISIT both freeze and pre-thaw "should" use D0 */
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 		return PCI_D3hot;
 	default:
 		printk("Unrecognized suspend event %d\n", state.event);
Index: linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
===================================================================
--- linux-2.6.orig/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
+++ linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
@@ -89,7 +89,7 @@ ahd_linux_pci_dev_suspend(struct pci_dev
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event & PM_EVENT_SLEEP)
 		pci_set_power_state(pdev, PCI_D3hot);
 
 	return rc;
Index: linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
===================================================================
--- linux-2.6.orig/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
+++ linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
@@ -134,7 +134,7 @@ ahc_linux_pci_dev_suspend(struct pci_dev
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event & PM_EVENT_SLEEP)
 		pci_set_power_state(pdev, PCI_D3hot);
 
 	return rc;
Index: linux-2.6/drivers/scsi/mesh.c
===================================================================
--- linux-2.6.orig/drivers/scsi/mesh.c
+++ linux-2.6/drivers/scsi/mesh.c
@@ -1759,6 +1759,7 @@ static int mesh_suspend(struct macio_dev
 
 	switch (mesg.event) {
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 	case PM_EVENT_FREEZE:
 		break;
 	default:
Index: linux-2.6/drivers/scsi/sd.c
===================================================================
--- linux-2.6.orig/drivers/scsi/sd.c
+++ linux-2.6/drivers/scsi/sd.c
@@ -1835,8 +1835,7 @@ static int sd_suspend(struct device *dev
 			goto done;
 	}
 
-	if (mesg.event == PM_EVENT_SUSPEND &&
-	    sdkp->device->manage_start_stop) {
+	if ((mesg.event & PM_EVENT_SLEEP) && sdkp->device->manage_start_stop) {
 		sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
 		ret = sd_start_stop_device(sdkp, 0);
 	}
Index: linux-2.6/drivers/usb/host/sl811-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/sl811-hcd.c
+++ linux-2.6/drivers/usb/host/sl811-hcd.c
@@ -1766,6 +1766,7 @@ sl811h_suspend(struct platform_device *d
 		retval = sl811h_bus_suspend(hcd);
 		break;
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 	case PM_EVENT_PRETHAW:		/* explicitly discard hw state */
 		port_power(sl811, 0);
 		break;
Index: linux-2.6/drivers/usb/host/u132-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/u132-hcd.c
+++ linux-2.6/drivers/usb/host/u132-hcd.c
@@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
                 return -ESHUTDOWN;
         } else {
                 int retval = 0;
-                if (state.event == PM_EVENT_FREEZE) {
+
+		switch (state.event) {
+		case PM_EVENT_FREEZE:
                         retval = u132_bus_suspend(hcd);
-                } else if (state.event == PM_EVENT_SUSPEND) {
+			break;
+		case PM_EVENT_SUSPEND:
+		case PM_EVENT_HIBERNATE:
                         int ports = MAX_U132_PORTS;
                         while (ports-- > 0) {
                                 port_power(u132, ports, 0);
                         }
-                }
+			break;
+		}
                 if (retval == 0)
                         pdev->dev.power.power_state = state;
                 return retval;
Index: linux-2.6/drivers/video/chipsfb.c
===================================================================
--- linux-2.6.orig/drivers/video/chipsfb.c
+++ linux-2.6/drivers/video/chipsfb.c
@@ -459,7 +459,7 @@ static int chipsfb_pci_suspend(struct pc
 
 	if (state.event == pdev->dev.power.power_state.event)
 		return 0;
-	if (state.event != PM_EVENT_SUSPEND)
+	if (!(state.event & PM_EVENT_SLEEP))
 		goto done;
 
 	acquire_console_sem();
Index: linux-2.6/drivers/video/nvidia/nvidia.c
===================================================================
--- linux-2.6.orig/drivers/video/nvidia/nvidia.c
+++ linux-2.6/drivers/video/nvidia/nvidia.c
@@ -1066,7 +1066,7 @@ static int nvidiafb_suspend(struct pci_d
 	acquire_console_sem();
 	par->pm_state = mesg.event;
 
-	if (mesg.event == PM_EVENT_SUSPEND) {
+	if (mesg.event & PM_EVENT_SLEEP) {
 		fb_set_suspend(info, 1);
 		nvidiafb_blank(FB_BLANK_POWERDOWN, info);
 		nvidia_write_regs(par, &par->SavedReg);
Index: linux-2.6/net/rfkill/rfkill.c
===================================================================
--- linux-2.6.orig/net/rfkill/rfkill.c
+++ linux-2.6/net/rfkill/rfkill.c
@@ -232,7 +232,7 @@ static int rfkill_suspend(struct device 
 	struct rfkill *rfkill = to_rfkill(dev);
 
 	if (dev->power.power_state.event != state.event) {
-		if (state.event == PM_EVENT_SUSPEND) {
+		if (state.event & PM_EVENT_SLEEP) {
 			mutex_lock(&rfkill->mutex);
 
 			if (rfkill->state == RFKILL_STATE_ON)
Index: linux-2.6/Documentation/power/devices.txt
===================================================================
--- linux-2.6.orig/Documentation/power/devices.txt
+++ linux-2.6/Documentation/power/devices.txt
@@ -310,9 +310,12 @@ used with suspend-to-disk:
     PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power
 	state.  When used with system sleep states like "suspend-to-RAM" or
 	"standby", the upcoming resume() call will often be able to rely on
-	state kept in hardware, or issue system wakeup events.  When used
-	instead with suspend-to-disk, few devices support this capability;
-	most are completely powered off.
+	state kept in hardware, or issue system wakeup events.
+
+    PM_EVENT_HIBERNATE -- Put hardware into a low-power state and enable wakeup
+	events as appropriate.  It is only used with hibernation
+	(suspend-to-disk) and few devices are able to wake up the system from
+	this state; most are completely powered off.
 
     PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into
 	any low power mode.  A system snapshot is about to be taken, often
@@ -329,8 +332,8 @@ used with suspend-to-disk:
 	wakeup events nor DMA are allowed.
 
 To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or
-the similarly named APM states, only PM_EVENT_SUSPEND is used; for "Suspend
-to Disk" (STD, hibernate, ACPI S4), all of those event codes are used.
+the similarly named APM states, only PM_EVENT_SUSPEND is used; the other event
+codes are used for hibernation ("Suspend to Disk", STD, ACPI S4).
 
 There's also PM_EVENT_ON, a value which never appears as a suspend event
 but is sometimes used to record the "not suspended" device state.

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Linus Torvalds]

On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> 
> In the revised patch below I redefined the PM_EVENT_* things as flags so
> that I can "or" them and defined PM_EVENT_SLEEP in analogy with
> CONFIG_PM_SLEEP.

Ok, looks fine by me.

> > Didn't you miss the apci_pci_choose_state() thing that also needs this 
> > extension?
> 
> No, I didn't.  That one operates on the ACPI D* states.

Ok. I consider that just about the worst interface ever, but whatever...

> OK, please have a look at the modified patch below.

All right, I'm fine with it. Now we just need to confirm that it works for 
people..

		Linus

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Jeff Chua]

On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:

>  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>  > OK, please have a look at the modified patch below.
>
>  All right, I'm fine with it. Now we just need to confirm that it works for
>  people..

Looks good. Applied Rafael patch on top of your latest git tree that
has Jesse's i915 fix.

No green screen. Tested with STD (platform), STR, and plain echo mem >
/sys/power/state.

Thanks,
Jeff.

[PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Rafael J. Wysocki]

On Saturday, 23 of February 2008, Jeff Chua wrote:
> On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> 
> >  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> >  > OK, please have a look at the modified patch below.
> >
> >  All right, I'm fine with it. Now we just need to confirm that it works for
> >  people..
> 
> Looks good. Applied Rafael patch on top of your latest git tree that
> has Jesse's i915 fix.
> 
> No green screen. Tested with STD (platform), STR, and plain echo mem >
> /sys/power/state.

Thanks for testing.  Below is the final version of the patch with a changelog
etc.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rjw@sisk.pl>

During the last step of hibernation in the "platform" mode (with the
help of ACPI) we use the suspend code, including the devices'
->suspend() methods, to prepare the system for entering the ACPI S4
system sleep state.  At least for some devices the operations
performed by the ->suspend() callback in that case must be different
from its operations during regular suspend.  For this reason,
introduce the new PM event type PM_EVENT_HIBERNATE and pass it to
the device drivers' ->suspend() methods during the last phase of
hibernation, so that they can distinguish this case and handle it as
appropriate.  Modify the drivers that handle PM_EVENT_SUSPEND in a
special way and need to handle PM_EVENT_HIBERNATE in the same way.

These changes are necessary to fix a hibernation regression related
to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Pavel Machek <pavel@ucw.cz>
Tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
---
 Documentation/power/devices.txt        |   13 ++++++++-----
 drivers/ata/ahci.c                     |    2 +-
 drivers/ata/ata_piix.c                 |    2 +-
 drivers/ata/libata-core.c              |    2 +-
 drivers/ide/ppc/pmac.c                 |    4 ++--
 drivers/macintosh/mediabay.c           |    3 ++-
 drivers/pci/pci.c                      |    1 +
 drivers/scsi/aic7xxx/aic79xx_osm_pci.c |    2 +-
 drivers/scsi/aic7xxx/aic7xxx_osm_pci.c |    2 +-
 drivers/scsi/mesh.c                    |    1 +
 drivers/scsi/sd.c                      |    3 +--
 drivers/usb/host/sl811-hcd.c           |    1 +
 drivers/usb/host/u132-hcd.c            |   11 ++++++++---
 drivers/video/chipsfb.c                |    2 +-
 drivers/video/nvidia/nvidia.c          |    2 +-
 include/linux/pm.h                     |    9 ++++++++-
 kernel/power/disk.c                    |    4 ++--
 net/rfkill/rfkill.c                    |    2 +-
 18 files changed, 42 insertions(+), 24 deletions(-)

Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -391,7 +391,7 @@ int hibernation_platform_enter(void)
 		goto Close;
 
 	suspend_console();
-	error = device_suspend(PMSG_SUSPEND);
+	error = device_suspend(PMSG_HIBERNATE);
 	if (error)
 		goto Resume_console;
 
@@ -404,7 +404,7 @@ int hibernation_platform_enter(void)
 		goto Finish;
 
 	local_irq_disable();
-	error = device_power_down(PMSG_SUSPEND);
+	error = device_power_down(PMSG_HIBERNATE);
 	if (!error) {
 		hibernation_ops->enter();
 		/* We should never get here */
Index: linux-2.6/include/linux/pm.h
===================================================================
--- linux-2.6.orig/include/linux/pm.h
+++ linux-2.6/include/linux/pm.h
@@ -143,6 +143,9 @@ typedef struct pm_message {
  * 		the upcoming system state (such as PCI_D3hot), and enable
  * 		wakeup events as appropriate.
  *
+ * HIBERNATE	Enter a low power device state appropriate for the hibernation
+ * 		state (eg. ACPI S4) and enable wakeup events as appropriate.
+ *
  * FREEZE	Quiesce operations so that a consistent image can be saved;
  * 		but do NOT otherwise enter a low power device state, and do
  * 		NOT emit system wakeup events.
@@ -166,11 +169,15 @@ typedef struct pm_message {
 #define PM_EVENT_ON 0
 #define PM_EVENT_FREEZE 1
 #define PM_EVENT_SUSPEND 2
-#define PM_EVENT_PRETHAW 3
+#define PM_EVENT_HIBERNATE 4
+#define PM_EVENT_PRETHAW 8
+
+#define PM_EVENT_SLEEP	(PM_EVENT_SUSPEND | PM_EVENT_HIBERNATE)
 
 #define PMSG_FREEZE	((struct pm_message){ .event = PM_EVENT_FREEZE, })
 #define PMSG_PRETHAW	((struct pm_message){ .event = PM_EVENT_PRETHAW, })
 #define PMSG_SUSPEND	((struct pm_message){ .event = PM_EVENT_SUSPEND, })
+#define PMSG_HIBERNATE	((struct pm_message){ .event = PM_EVENT_HIBERNATE, })
 #define PMSG_ON		((struct pm_message){ .event = PM_EVENT_ON, })
 
 struct dev_pm_info {
Index: linux-2.6/drivers/ata/ahci.c
===================================================================
--- linux-2.6.orig/drivers/ata/ahci.c
+++ linux-2.6/drivers/ata/ahci.c
@@ -1932,7 +1932,7 @@ static int ahci_pci_device_suspend(struc
 	void __iomem *mmio = host->iomap[AHCI_PCI_BAR];
 	u32 ctl;
 
-	if (mesg.event == PM_EVENT_SUSPEND) {
+	if (mesg.event & PM_EVENT_SLEEP) {
 		/* AHCI spec rev1.1 section 8.3.3:
 		 * Software must disable interrupts prior to requesting a
 		 * transition of the HBA to D3 state.
Index: linux-2.6/drivers/ata/ata_piix.c
===================================================================
--- linux-2.6.orig/drivers/ata/ata_piix.c
+++ linux-2.6/drivers/ata/ata_piix.c
@@ -1339,7 +1339,7 @@ static int piix_pci_device_suspend(struc
 	 * cycles and power trying to do something to the sleeping
 	 * beauty.
 	 */
-	if (piix_broken_suspend() && mesg.event == PM_EVENT_SUSPEND) {
+	if (piix_broken_suspend() && (mesg.event & PM_EVENT_SLEEP)) {
 		pci_save_state(pdev);
 
 		/* mark its power state as "unknown", since we don't
Index: linux-2.6/drivers/ata/libata-core.c
===================================================================
--- linux-2.6.orig/drivers/ata/libata-core.c
+++ linux-2.6/drivers/ata/libata-core.c
@@ -7368,7 +7368,7 @@ void ata_pci_device_do_suspend(struct pc
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event & PM_EVENT_SLEEP)
 		pci_set_power_state(pdev, PCI_D3hot);
 }
 
Index: linux-2.6/drivers/ide/ppc/pmac.c
===================================================================
--- linux-2.6.orig/drivers/ide/ppc/pmac.c
+++ linux-2.6/drivers/ide/ppc/pmac.c
@@ -1254,7 +1254,7 @@ pmac_ide_macio_suspend(struct macio_dev 
 	int		rc = 0;
 
 	if (mesg.event != mdev->ofdev.dev.power.power_state.event
-			&& mesg.event == PM_EVENT_SUSPEND) {
+			&& (mesg.event & PM_EVENT_SLEEP)) {
 		rc = pmac_ide_do_suspend(hwif);
 		if (rc == 0)
 			mdev->ofdev.dev.power.power_state = mesg;
@@ -1364,7 +1364,7 @@ pmac_ide_pci_suspend(struct pci_dev *pde
 	int		rc = 0;
 	
 	if (mesg.event != pdev->dev.power.power_state.event
-			&& mesg.event == PM_EVENT_SUSPEND) {
+			&& (mesg.event & PM_EVENT_SLEEP)) {
 		rc = pmac_ide_do_suspend(hwif);
 		if (rc == 0)
 			pdev->dev.power.power_state = mesg;
Index: linux-2.6/drivers/macintosh/mediabay.c
===================================================================
--- linux-2.6.orig/drivers/macintosh/mediabay.c
+++ linux-2.6/drivers/macintosh/mediabay.c
@@ -698,7 +698,8 @@ static int media_bay_suspend(struct maci
 {
 	struct media_bay_info	*bay = macio_get_drvdata(mdev);
 
-	if (state.event != mdev->ofdev.dev.power.power_state.event && state.event == PM_EVENT_SUSPEND) {
+	if (state.event != mdev->ofdev.dev.power.power_state.event
+	    && (state.event & PM_EVENT_SLEEP)) {
 		down(&bay->lock);
 		bay->sleeping = 1;
 		set_mb_power(bay, 0);
Index: linux-2.6/drivers/pci/pci.c
===================================================================
--- linux-2.6.orig/drivers/pci/pci.c
+++ linux-2.6/drivers/pci/pci.c
@@ -554,6 +554,7 @@ pci_power_t pci_choose_state(struct pci_
 	case PM_EVENT_PRETHAW:
 		/* REVISIT both freeze and pre-thaw "should" use D0 */
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 		return PCI_D3hot;
 	default:
 		printk("Unrecognized suspend event %d\n", state.event);
Index: linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
===================================================================
--- linux-2.6.orig/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
+++ linux-2.6/drivers/scsi/aic7xxx/aic79xx_osm_pci.c
@@ -89,7 +89,7 @@ ahd_linux_pci_dev_suspend(struct pci_dev
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event & PM_EVENT_SLEEP)
 		pci_set_power_state(pdev, PCI_D3hot);
 
 	return rc;
Index: linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
===================================================================
--- linux-2.6.orig/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
+++ linux-2.6/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c
@@ -134,7 +134,7 @@ ahc_linux_pci_dev_suspend(struct pci_dev
 	pci_save_state(pdev);
 	pci_disable_device(pdev);
 
-	if (mesg.event == PM_EVENT_SUSPEND)
+	if (mesg.event & PM_EVENT_SLEEP)
 		pci_set_power_state(pdev, PCI_D3hot);
 
 	return rc;
Index: linux-2.6/drivers/scsi/mesh.c
===================================================================
--- linux-2.6.orig/drivers/scsi/mesh.c
+++ linux-2.6/drivers/scsi/mesh.c
@@ -1759,6 +1759,7 @@ static int mesh_suspend(struct macio_dev
 
 	switch (mesg.event) {
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 	case PM_EVENT_FREEZE:
 		break;
 	default:
Index: linux-2.6/drivers/scsi/sd.c
===================================================================
--- linux-2.6.orig/drivers/scsi/sd.c
+++ linux-2.6/drivers/scsi/sd.c
@@ -1835,8 +1835,7 @@ static int sd_suspend(struct device *dev
 			goto done;
 	}
 
-	if (mesg.event == PM_EVENT_SUSPEND &&
-	    sdkp->device->manage_start_stop) {
+	if ((mesg.event & PM_EVENT_SLEEP) && sdkp->device->manage_start_stop) {
 		sd_printk(KERN_NOTICE, sdkp, "Stopping disk\n");
 		ret = sd_start_stop_device(sdkp, 0);
 	}
Index: linux-2.6/drivers/usb/host/sl811-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/sl811-hcd.c
+++ linux-2.6/drivers/usb/host/sl811-hcd.c
@@ -1766,6 +1766,7 @@ sl811h_suspend(struct platform_device *d
 		retval = sl811h_bus_suspend(hcd);
 		break;
 	case PM_EVENT_SUSPEND:
+	case PM_EVENT_HIBERNATE:
 	case PM_EVENT_PRETHAW:		/* explicitly discard hw state */
 		port_power(sl811, 0);
 		break;
Index: linux-2.6/drivers/usb/host/u132-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/u132-hcd.c
+++ linux-2.6/drivers/usb/host/u132-hcd.c
@@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
                 return -ESHUTDOWN;
         } else {
                 int retval = 0;
-                if (state.event == PM_EVENT_FREEZE) {
+
+		switch (state.event) {
+		case PM_EVENT_FREEZE:
                         retval = u132_bus_suspend(hcd);
-                } else if (state.event == PM_EVENT_SUSPEND) {
+			break;
+		case PM_EVENT_SUSPEND:
+		case PM_EVENT_HIBERNATE:
                         int ports = MAX_U132_PORTS;
                         while (ports-- > 0) {
                                 port_power(u132, ports, 0);
                         }
-                }
+			break;
+		}
                 if (retval == 0)
                         pdev->dev.power.power_state = state;
                 return retval;
Index: linux-2.6/drivers/video/chipsfb.c
===================================================================
--- linux-2.6.orig/drivers/video/chipsfb.c
+++ linux-2.6/drivers/video/chipsfb.c
@@ -459,7 +459,7 @@ static int chipsfb_pci_suspend(struct pc
 
 	if (state.event == pdev->dev.power.power_state.event)
 		return 0;
-	if (state.event != PM_EVENT_SUSPEND)
+	if (!(state.event & PM_EVENT_SLEEP))
 		goto done;
 
 	acquire_console_sem();
Index: linux-2.6/drivers/video/nvidia/nvidia.c
===================================================================
--- linux-2.6.orig/drivers/video/nvidia/nvidia.c
+++ linux-2.6/drivers/video/nvidia/nvidia.c
@@ -1066,7 +1066,7 @@ static int nvidiafb_suspend(struct pci_d
 	acquire_console_sem();
 	par->pm_state = mesg.event;
 
-	if (mesg.event == PM_EVENT_SUSPEND) {
+	if (mesg.event & PM_EVENT_SLEEP) {
 		fb_set_suspend(info, 1);
 		nvidiafb_blank(FB_BLANK_POWERDOWN, info);
 		nvidia_write_regs(par, &par->SavedReg);
Index: linux-2.6/net/rfkill/rfkill.c
===================================================================
--- linux-2.6.orig/net/rfkill/rfkill.c
+++ linux-2.6/net/rfkill/rfkill.c
@@ -232,7 +232,7 @@ static int rfkill_suspend(struct device 
 	struct rfkill *rfkill = to_rfkill(dev);
 
 	if (dev->power.power_state.event != state.event) {
-		if (state.event == PM_EVENT_SUSPEND) {
+		if (state.event & PM_EVENT_SLEEP) {
 			mutex_lock(&rfkill->mutex);
 
 			if (rfkill->state == RFKILL_STATE_ON)
Index: linux-2.6/Documentation/power/devices.txt
===================================================================
--- linux-2.6.orig/Documentation/power/devices.txt
+++ linux-2.6/Documentation/power/devices.txt
@@ -310,9 +310,12 @@ used with suspend-to-disk:
     PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power
 	state.  When used with system sleep states like "suspend-to-RAM" or
 	"standby", the upcoming resume() call will often be able to rely on
-	state kept in hardware, or issue system wakeup events.  When used
-	instead with suspend-to-disk, few devices support this capability;
-	most are completely powered off.
+	state kept in hardware, or issue system wakeup events.
+
+    PM_EVENT_HIBERNATE -- Put hardware into a low-power state and enable wakeup
+	events as appropriate.  It is only used with hibernation
+	(suspend-to-disk) and few devices are able to wake up the system from
+	this state; most are completely powered off.
 
     PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into
 	any low power mode.  A system snapshot is about to be taken, often
@@ -329,8 +332,8 @@ used with suspend-to-disk:
 	wakeup events nor DMA are allowed.
 
 To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or
-the similarly named APM states, only PM_EVENT_SUSPEND is used; for "Suspend
-to Disk" (STD, hibernate, ACPI S4), all of those event codes are used.
+the similarly named APM states, only PM_EVENT_SUSPEND is used; the other event
+codes are used for hibernation ("Suspend to Disk", STD, ACPI S4).
 
 There's also PM_EVENT_ON, a value which never appears as a suspend event
 but is sometimes used to record the "not suspended" device state.

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Linus Torvalds]

On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> 
> Thanks for testing.  Below is the final version of the patch with a changelog
> etc.

Thanks, applied. 

With this, I also find that I dislike the use of suspend/resume for 
freezing for STD a lot less. It's still too easy to get confused, but at 
least now drivers always have total knowledge about what is really going 
on. I'd not like this interface as a driver writer, but now it's not 
fundamentally broken any more, just slightly confusing.

			Linus

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Pavel Machek]

Hi!

> Thanks, applied. 
> 
> With this, I also find that I dislike the use of suspend/resume for 
> freezing for STD a lot less. It's still too easy to get confused, but at 
> least now drivers always have total knowledge about what is really going 
> on. I'd not like this interface as a driver writer, but now it's not 
> fundamentally broken any more, just slightly confusing.

Heh, thanks :-).
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Jeff Chua]

On Sun, Feb 24, 2008 at 2:43 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
>  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>  >
>
> > Thanks for testing.  Below is the final version of the patch with a changelog
>  > etc.
>
>  Thanks, applied.
>
>  With this, I also find that I dislike the use of suspend/resume for
>  freezing for STD a lot less. It's still too easy to get confused, but at
>  least now drivers always have total knowledge about what is really going
>  on. I'd not like this interface as a driver writer, but now it's not
>  fundamentally broken any more, just slightly confusing.

Tested and working.

Thanks again,
Jeff.

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Mirco Tischler]

[-- Attachment #1: Type: text/plain, Size: 3234 bytes --]


On Sa, 2008-02-23 at 19:13 +0100, Rafael J. Wysocki wrote:
> Index: linux-2.6/drivers/usb/host/u132-hcd.c
> ===================================================================
> --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> +++ linux-2.6/drivers/usb/host/u132-hcd.c
> @@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
>                  return -ESHUTDOWN;
>          } else {
>                  int retval = 0;
> -                if (state.event == PM_EVENT_FREEZE) {
> +
> +		switch (state.event) {
> +		case PM_EVENT_FREEZE:
>                          retval = u132_bus_suspend(hcd);
> -                } else if (state.event == PM_EVENT_SUSPEND) {
> +			break;
> +		case PM_EVENT_SUSPEND:
> +		case PM_EVENT_HIBERNATE:
>                          int ports = MAX_U132_PORTS;
>                          while (ports-- > 0) {
>                                  port_power(u132, ports, 0);
>                          }
> -                }
> +			break;
> +		}
>                  if (retval == 0)
>                          pdev->dev.power.power_state = state;
>                  return retval;
Hmm. Doesn't compile for me in 2.6.25-rc2-git7:

  CC [M]  drivers/usb/host/u132-hcd.o
drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
drivers/usb/host/u132-hcd.c:3224: error: expected expression before
‘int’
drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
in this function)
drivers/usb/host/u132-hcd.c:3225: error: (Each undeclared identifier is
reported only once
drivers/usb/host/u132-hcd.c:3225: error: for each function it appears
in.)
make[3]: *** [drivers/usb/host/u132-hcd.o] Error 1
make[2]: *** [drivers/usb/host] Error 2
make[1]: *** [drivers/usb] Error 2
make: *** [drivers] Error 2

This fixes it:

Thanks
Mirco

---
From: Mirco Tischler <mt-ml@gmx.de>

Fixes the following compile error caused by commit
3a2d5b700132f35401f1d9e22fe3c2cab02c2549

...
  CC [M]  drivers/usb/host/u132-hcd.o
drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
drivers/usb/host/u132-hcd.c:3224: error: expected expression before
‘int’
drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
in this function)
...

Signed-off-by: Mirco Tischler <mt-ml@gmx.de>
---
 drivers/usb/host/u132-hcd.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index 6fca069..58830b2 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3214,6 +3214,7 @@ static int u132_suspend(struct platform_device
*pdev, pm_message_t state)
                 return -ESHUTDOWN;
         } else {
                 int retval = 0;
+		int ports = 0;
 
 		switch (state.event) {
 		case PM_EVENT_FREEZE:
@@ -3221,7 +3222,7 @@ static int u132_suspend(struct platform_device
*pdev, pm_message_t state)
 			break;
 		case PM_EVENT_SUSPEND:
 		case PM_EVENT_HIBERNATE:
-                        int ports = MAX_U132_PORTS;
+			ports = MAX_U132_PORTS;
                         while (ports-- > 0) {
                                 port_power(u132, ports, 0);
                         }


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Mirco Tischler wrote:
> 
> On Sa, 2008-02-23 at 19:13 +0100, Rafael J. Wysocki wrote:
> > Index: linux-2.6/drivers/usb/host/u132-hcd.c
> > ===================================================================
> > --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> > +++ linux-2.6/drivers/usb/host/u132-hcd.c
> > @@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
> >                  return -ESHUTDOWN;
> >          } else {
> >                  int retval = 0;
> > -                if (state.event == PM_EVENT_FREEZE) {
> > +
> > +		switch (state.event) {
> > +		case PM_EVENT_FREEZE:
> >                          retval = u132_bus_suspend(hcd);
> > -                } else if (state.event == PM_EVENT_SUSPEND) {
> > +			break;
> > +		case PM_EVENT_SUSPEND:
> > +		case PM_EVENT_HIBERNATE:
> >                          int ports = MAX_U132_PORTS;
> >                          while (ports-- > 0) {
> >                                  port_power(u132, ports, 0);
> >                          }
> > -                }
> > +			break;
> > +		}
> >                  if (retval == 0)
> >                          pdev->dev.power.power_state = state;
> >                  return retval;
> Hmm. Doesn't compile for me in 2.6.25-rc2-git7:
> 
>   CC [M]  drivers/usb/host/u132-hcd.o
> drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
> drivers/usb/host/u132-hcd.c:3224: error: expected expression before
> ‘int’
> drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
> in this function)
> drivers/usb/host/u132-hcd.c:3225: error: (Each undeclared identifier is
> reported only once
> drivers/usb/host/u132-hcd.c:3225: error: for each function it appears
> in.)
> make[3]: *** [drivers/usb/host/u132-hcd.o] Error 1
> make[2]: *** [drivers/usb/host] Error 2
> make[1]: *** [drivers/usb] Error 2
> make: *** [drivers] Error 2
> 
> This fixes it:
> 
> Thanks
> Mirco
> 
> ---
> From: Mirco Tischler <mt-ml@gmx.de>
> 
> Fixes the following compile error caused by commit
> 3a2d5b700132f35401f1d9e22fe3c2cab02c2549
> 
> ...
>   CC [M]  drivers/usb/host/u132-hcd.o
> drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
> drivers/usb/host/u132-hcd.c:3224: error: expected expression before
> ‘int’
> drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
> in this function)
> ...
> 
> Signed-off-by: Mirco Tischler <mt-ml@gmx.de>
> ---
>  drivers/usb/host/u132-hcd.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
> index 6fca069..58830b2 100644
> --- a/drivers/usb/host/u132-hcd.c
> +++ b/drivers/usb/host/u132-hcd.c
> @@ -3214,6 +3214,7 @@ static int u132_suspend(struct platform_device
> *pdev, pm_message_t state)
>                  return -ESHUTDOWN;
>          } else {
>                  int retval = 0;
> +		int ports = 0;

Hm, why not to do:

---
 drivers/usb/host/u132-hcd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/usb/host/u132-hcd.c
===================================================================
--- linux-2.6.orig/drivers/usb/host/u132-hcd.c
+++ linux-2.6/drivers/usb/host/u132-hcd.c
@@ -3214,6 +3214,7 @@ static int u132_suspend(struct platform_
                 return -ESHUTDOWN;
         } else {
                 int retval = 0;
+		int ports = MAX_U132_PORTS;
 
 		switch (state.event) {
 		case PM_EVENT_FREEZE:
@@ -3221,7 +3222,6 @@ static int u132_suspend(struct platform_
 			break;
 		case PM_EVENT_SUSPEND:
 		case PM_EVENT_HIBERNATE:
-                        int ports = MAX_U132_PORTS;
                         while (ports-- > 0) {
                                 port_power(u132, ports, 0);
                         }

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Rafael J. Wysocki]

On Sunday, 24 of February 2008, Rafael J. Wysocki wrote:
> On Sunday, 24 of February 2008, Mirco Tischler wrote:
> > 
> > On Sa, 2008-02-23 at 19:13 +0100, Rafael J. Wysocki wrote:
> > > Index: linux-2.6/drivers/usb/host/u132-hcd.c
> > > ===================================================================
> > > --- linux-2.6.orig/drivers/usb/host/u132-hcd.c
> > > +++ linux-2.6/drivers/usb/host/u132-hcd.c
> > > @@ -3214,14 +3214,19 @@ static int u132_suspend(struct platform_
> > >                  return -ESHUTDOWN;
> > >          } else {
> > >                  int retval = 0;
> > > -                if (state.event == PM_EVENT_FREEZE) {
> > > +
> > > +		switch (state.event) {
> > > +		case PM_EVENT_FREEZE:
> > >                          retval = u132_bus_suspend(hcd);
> > > -                } else if (state.event == PM_EVENT_SUSPEND) {
> > > +			break;
> > > +		case PM_EVENT_SUSPEND:
> > > +		case PM_EVENT_HIBERNATE:
> > >                          int ports = MAX_U132_PORTS;
> > >                          while (ports-- > 0) {
> > >                                  port_power(u132, ports, 0);
> > >                          }
> > > -                }
> > > +			break;
> > > +		}
> > >                  if (retval == 0)
> > >                          pdev->dev.power.power_state = state;
> > >                  return retval;
> > Hmm. Doesn't compile for me in 2.6.25-rc2-git7:
> > 
> >   CC [M]  drivers/usb/host/u132-hcd.o
> > drivers/usb/host/u132-hcd.c: In function ‘u132_suspend’:
> > drivers/usb/host/u132-hcd.c:3224: error: expected expression before
> > ‘int’
> > drivers/usb/host/u132-hcd.c:3225: error: ‘ports’ undeclared (first use
> > in this function)
> > drivers/usb/host/u132-hcd.c:3225: error: (Each undeclared identifier is
> > reported only once
> > drivers/usb/host/u132-hcd.c:3225: error: for each function it appears
> > in.)
> > make[3]: *** [drivers/usb/host/u132-hcd.o] Error 1
> > make[2]: *** [drivers/usb/host] Error 2
> > make[1]: *** [drivers/usb] Error 2
> > make: *** [drivers] Error 2
> > 
> > This fixes it:
> > 
> > Thanks
> > Mirco
> > 
> > ---
> > From: Mirco Tischler <mt-ml@gmx.de>
> > 
> > Fixes the following compile error caused by commit
> > 3a2d5b700132f35401f1d9e22fe3c2cab02c2549

Ah, I see it's merged already.

Thanks for the fix, btw! :-)

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Pavel Machek]

> > Apart from those issues it looks fine to me.

> 
> OK, please have a look at the modified patch below.

Seems to work here after basic tests. ACK.

(I discovered that -rc2 swsusp will not power down in some cases, but
it was here before the patch, too...)
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Feb 21, 2008 1:28 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> That said, before you do anything else, try if suspend-to-RAM works.

Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.

And suspend-to-disk hangs, but I can still press and hold the power
button to power it off. Then upon powering on and resume, I get the
ugly green "console" screen. I can still type and move around.
Starting X runs fine. Ctrl-Alt-Del or switching back to console will
get back to the green screen.

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Thu, 21 Feb 2008, Jeff Chua wrote:
> 
> > That said, before you do anything else, try if suspend-to-RAM works.
> 
> Linus, guess I missed this part ... so before touch anything, I did
> tried suspend-to-ram, and it works on console and in X.

Ok, so this is with clean current -git, and nothing disabled?

> And suspend-to-disk hangs, but I can still press and hold the power
> button to power it off.

The "press and hold for five seconds" is actually a hardware feature of 
the southbridge (well, I guess there is "software" in there too, but it's 
the embedded kind). So the fact that it powers off at that point means 
nothing, it just means that ok, your kernel is hung, but the hardware
still works ;)

This *sounds* like some part of the suspend-to-disk sequence is doing 
something stupid like trying to access the screen after it has been turned 
off, which doesn't surprise me at all. My oft-stated opinion has been that 
suspend-to-disk isn't a suspend at all, and should never have been 
confused with "suspending" anything.

It's "snapshot-and-restore", and my opinion is that:

 - it should *never* call "suspend()"/"resume()" at all (that should be
   reserved purely for suspend-to-RAM and has real power management 
   issues!)

 - it should have a totally separate "halt/unhalt/restore" thing 
   that has nothing what-so-ever to do with power management, and is 
   purely about stopping the hardware for things like USB and network 
   cards (which otherwise do things like scan their command lists 
   asynchronously) and making sure that the driver state is consistent 
   with that stopped hw state.

 - the people who confuse snapshot/restore with suspend/resume are 
   horrible people that cause problems exactly because driver people then 
   get those things mixed up, and something like the video suspend/resume 
   should probably never have impacted suspend-to-disk in the first place!

HOWEVER, that's a separate fight I've had, and in the meantime:

> Then upon powering on and resume, I get the ugly green "console" screen. 
> I can still type and move around. Starting X runs fine. Ctrl-Alt-Del or 
> switching back to console will get back to the green screen.

.. so this implies that while the laptop apparently hung at the end of the 
snapshotting, the snapshotting did actually work, and it must have hung at 
the very end, presumably when it tried to actually turn the power off.

So there seems to be two (probably largely independent) problems:

 - the hang at shutdown that requires you to press-and-hold the power 
   button to actually cut power.

   At a guess: putting the VGA device into D3hot makes the ACPI code that 
   actually does the shutoff unhappy. Probably because it wants to access 
   the device, and ends up not ever getting the replies it wants, since 
   the hardware has been turned off.

 - the fact that we restore something wrong for you and the screen is 
   green.

   At a guess: the restore_vga ends up restoring some state that wasn't 
   correctly and fully saved.

IOW, I think your patch that disables the two lines actually ends up 
pretty much matching the two *different* problems. Can you confirm that 
doing those two parts of that patch individually actually does 
individually fix the two issues? (Ie disabling D3hot makes it shut down 
nicely but resume with green text, while disabling just restore_vga() ends 
up with shutdown problems, but once you press-and-hold the power button, 
the thing will then restore nicely)+

		Linus

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

[Pavel Machek]

Hi!

> It's "snapshot-and-restore", and my opinion is that:
> 
>  - it should *never* call "suspend()"/"resume()" at all (that should be
>    reserved purely for suspend-to-RAM and has real power management 
>    issues!)

Hmm, entering S4 seems like good place to call suspend() for... unless
you want separate freeze()/unfreeze(), suspend()/resume(),
suspend_s4() and halt() callbacks.
						Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]

On Feb 21, 2008 2:37 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Ok, so this is with clean current -git, and nothing disabled?

Clean as far as I can tell. Attached is my .config

>  - the hang at shutdown that requires you to press-and-hold the power
>    button to actually cut power.

Here's an interesting discovery. After I found that "echo reboot >
/sys/power/disk" does reboot, I tried "echo shutdown >
/sys/power/disk", it does shutdown properly.

With "platform" it refuses to shutdown. Both reboot and shutdown still
end up with Mr. Green at resume.


> IOW, I think your patch that disables the two lines actually ends up
> pretty much matching the two *different* problems. Can you confirm that
> doing those two parts of that patch individually actually does
> individually fix the two issues?

Yes, there were indeed two separate problems, and I did dissect them separately.

>  (Ie disabling D3hot makes it shut down nicely but resume with green text

Yes.

> , while disabling just restore_vga() ends up with shutdown problems, but once you press-and-hold the power button, the thing will then restore nicely)+

Yes.


Thanks,
Jeff.

[-- Attachment #2: .config --]
[-- Type: application/octet-stream, Size: 47058 bytes --]

#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc2
# Wed Feb 20 23:06:59 2008
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_X86_SMP=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
# CONFIG_CGROUPS is not set
CONFIG_GROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_USER_SCHED=y
# CONFIG_CGROUP_SCHED is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
CONFIG_BLK_DEV_BSG=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
# CONFIG_IOSCHED_DEADLINE is not set
# CONFIG_IOSCHED_CFQ is not set
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_CLASSIC_RCU=y
# CONFIG_PREEMPT_RCU is not set

#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
# CONFIG_XEN is not set
CONFIG_VMI=y
CONFIG_PARAVIRT=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
CONFIG_X86_GENERIC=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_IOMMU_HELPER is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
# CONFIG_RCU_TRACE is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
# CONFIG_NOHIGHMEM is not set
# CONFIG_HIGHMEM4G is not set
CONFIG_HIGHMEM64G=y
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_X86_PAE=y
CONFIG_NEED_NODE_MEMMAP_SIZE=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
# CONFIG_FLATMEM_MANUAL is not set
# CONFIG_DISCONTIGMEM_MANUAL is not set
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set

#
# Memory hotplug is currently incompatible with Software Suspend
#
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_NR_QUICK=1
CONFIG_VIRT_TO_BUS=y
CONFIG_HIGHPTE=y
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_300 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
CONFIG_COMPAT_VDSO=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y

#
# Power management options
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION="/dev/sda3"
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS is not set
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_WMI is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT_INITRD is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_SBS=y
# CONFIG_APM is not set

#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
CONFIG_PCI_GODIRECT=y
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_DIRECT=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
CONFIG_PCI_LEGACY=y
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
CONFIG_PCCARD=m
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=m
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=m
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=m
# CONFIG_HOTPLUG_PCI is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y

#
# Networking
#
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
CONFIG_NET_KEY=m
# CONFIG_NET_KEY_MIGRATE is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IP_VS is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
# CONFIG_NF_CT_ACCT is not set
CONFIG_NF_CONNTRACK_MARK=y
# CONFIG_NF_CONNTRACK_EVENTS is not set
CONFIG_NF_CT_PROTO_SCTP=y
# CONFIG_NF_CT_PROTO_UDPLITE is not set
# CONFIG_NF_CONNTRACK_AMANDA is not set
CONFIG_NF_CONNTRACK_FTP=y
# CONFIG_NF_CONNTRACK_H323 is not set
# CONFIG_NF_CONNTRACK_IRC is not set
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
# CONFIG_NF_CONNTRACK_PPTP is not set
# CONFIG_NF_CONNTRACK_SANE is not set
# CONFIG_NF_CONNTRACK_SIP is not set
CONFIG_NF_CONNTRACK_TFTP=y
# CONFIG_NF_CT_NETLINK is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
CONFIG_NETFILTER_XT_TARGET_MARK=y
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNBYTES is not set
# CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_CONNMARK is not set
# CONFIG_NETFILTER_XT_MATCH_CONNTRACK is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HELPER is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=y

#
# IP: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_RECENT is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
# CONFIG_IP_NF_MATCH_ADDRTYPE is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_NF_NAT=y
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
# CONFIG_NF_NAT_SNMP_BASIC is not set
CONFIG_NF_NAT_FTP=y
# CONFIG_NF_NAT_IRC is not set
CONFIG_NF_NAT_TFTP=y
# CONFIG_NF_NAT_AMANDA is not set
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
# CONFIG_NF_NAT_SIP is not set
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
# CONFIG_IP_NF_ARP_MANGLE is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
CONFIG_NET_SCH_FIFO=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
# CONFIG_BT_CMTP is not set
CONFIG_BT_HIDP=m

#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
# CONFIG_BT_HCIBTSDIO is not set
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIDTL1 is not set
# CONFIG_BT_HCIBT3C is not set
# CONFIG_BT_HCIBLUECARD is not set
# CONFIG_BT_HCIBTUART is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_AF_RXRPC is not set

#
# Wireless
#
CONFIG_CFG80211=m
CONFIG_NL80211=y
CONFIG_WIRELESS_EXT=y
CONFIG_MAC80211=m

#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_DEFAULT_PID=y
# CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set
# CONFIG_MAC80211_RC_DEFAULT_NONE is not set

#
# Selecting 'y' for an algorithm will
#

#
# build the algorithm into mac80211.
#
CONFIG_MAC80211_RC_DEFAULT="pid"
CONFIG_MAC80211_RC_PID=y
# CONFIG_MAC80211_RC_SIMPLE is not set
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
# CONFIG_MAC80211_DEBUG is not set
CONFIG_IEEE80211=m
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=m
CONFIG_IEEE80211_CRYPT_CCMP=m
CONFIG_IEEE80211_CRYPT_TKIP=m
# CONFIG_IEEE80211_SOFTMAC is not set
CONFIG_RFKILL=m
CONFIG_RFKILL_INPUT=m
CONFIG_RFKILL_LEDS=y
# CONFIG_NET_9P is not set

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=m
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=20480
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_VIRTIO_BLK=m
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ACER_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
CONFIG_THINKPAD_ACPI=y
# CONFIG_THINKPAD_ACPI_DEBUG is not set
# CONFIG_THINKPAD_ACPI_DOCK is not set
# CONFIG_THINKPAD_ACPI_BAY is not set
CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y
# CONFIG_INTEL_MENLOW is not set
# CONFIG_ENCLOSURE_SERVICES is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
# CONFIG_BLK_DEV_IDECS is not set
# CONFIG_BLK_DEV_DELKIN is not set
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
CONFIG_BLK_DEV_IDESCSI=m
CONFIG_BLK_DEV_IDEACPI=y
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y

#
# IDE chipset support/bugfixes
#
CONFIG_IDE_GENERIC=y
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y

#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_PCIBUS_ORDER=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
CONFIG_BLK_DEV_PIIX=y
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
CONFIG_BLK_DEV_PDC202XX_NEW=y
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDE_ARCH_OBSOLETE_INIT=y
# CONFIG_BLK_DEV_HD is not set

#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set

#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
CONFIG_MEGARAID_NEWGEN=y
CONFIG_MEGARAID_MM=y
CONFIG_MEGARAID_MAILBOX=y
# CONFIG_MEGARAID_LEGACY is not set
CONFIG_MEGARAID_SAS=y
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
CONFIG_PATA_MPIIX=y
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=m
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
CONFIG_FUSION=y
CONFIG_FUSION_SPI=y
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
CONFIG_FUSION_MAX_SGE=128
# CONFIG_FUSION_CTL is not set
# CONFIG_FUSION_LOGGING is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
CONFIG_IEEE1394=m

#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set

#
# Controllers
#

#
# Texas Instruments PCILynx requires I2C
#
CONFIG_IEEE1394_OHCI1394=m

#
# Protocols
#
CONFIG_IEEE1394_VIDEO1394=m
CONFIG_IEEE1394_SBP2=m
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
# CONFIG_IEEE1394_ETH1394_ROM_ENTRY is not set
# CONFIG_IEEE1394_ETH1394 is not set
# CONFIG_IEEE1394_DV1394 is not set
CONFIG_IEEE1394_RAWIO=m
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_MACVLAN is not set
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_PCNET32_NAPI is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=m
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
CONFIG_8139CP=m
# CONFIG_8139TOO is not set
# CONFIG_R6040 is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
CONFIG_E1000E=m
CONFIG_E1000E_ENABLED=y
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
CONFIG_BNX2=y
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
CONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGB is not set
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_NIU is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_TEHUTI is not set
# CONFIG_BNX2X is not set
# CONFIG_TR is not set

#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_P54_COMMON is not set
# CONFIG_ATH5K is not set
CONFIG_IWL4965=m
# CONFIG_IWL4965_QOS is not set
# CONFIG_IWL4965_SPECTRUM_MEASUREMENT is not set
# CONFIG_IWL4965_SENSITIVITY is not set
# CONFIG_IWL4965_DEBUG is not set
CONFIG_IWL3945=m
# CONFIG_IWL3945_QOS is not set
# CONFIG_IWL3945_SPECTRUM_MEASUREMENT is not set
# CONFIG_IWL3945_DEBUG is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
CONFIG_USB_PEGASUS=m
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_NET_PCMCIA is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
# CONFIG_PPP_SYNC_TTY is not set
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
# CONFIG_PPP_MPPE is not set
# CONFIG_PPPOE is not set
# CONFIG_PPPOL2TP is not set
# CONFIG_SLIP is not set
CONFIG_SLHC=m
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_VIRTIO_NET is not set
CONFIG_ISDN=m
# CONFIG_ISDN_I4L is not set
CONFIG_ISDN_CAPI=m
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set
CONFIG_CAPI_TRACE=y
# CONFIG_ISDN_CAPI_MIDDLEWARE is not set
CONFIG_ISDN_CAPI_CAPI20=m

#
# CAPI hardware drivers
#
# CONFIG_CAPI_AVM is not set

#
# Active Dialogic DIVA Server cards
#
CONFIG_CAPI_EICON=y
CONFIG_ISDN_DIVAS=m
CONFIG_ISDN_DIVAS_BRIPCI=y
CONFIG_ISDN_DIVAS_PRIPCI=y
CONFIG_ISDN_DIVAS_ANALOG=y
CONFIG_ISDN_DIVAS_DIVACAPI=m
CONFIG_ISDN_DIVAS_USERIDI=m
CONFIG_ISDN_DIVAS_MAINT=m
CONFIG_ISDN_DIVAS_HSI=m
# CONFIG_PHONE is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set

#
# Serial drivers
#
CONFIG_SERIAL_8250=m
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=m
CONFIG_SERIAL_8250_PNP=m
CONFIG_SERIAL_8250_CS=m
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set

#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=m
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
CONFIG_NVRAM=y
CONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_I2C is not set

#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
CONFIG_SENSORS_CORETEMP=y
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_HDAPS=y
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
# CONFIG_WATCHDOG is not set

#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set

#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set

#
# Graphics support
#
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
CONFIG_DRM_I915=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set

#
# Display device support
#
CONFIG_DISPLAY_SUPPORT=y

#
# Display hardware drivers
#

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_VIDEO_SELECT=y
CONFIG_DUMMY_CONSOLE=y

#
# Sound
#
CONFIG_SOUND=y

#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set

#
# Generic devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set

#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
CONFIG_SND_ENS1370=y
CONFIG_SND_ENS1371=y
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
# CONFIG_SND_HDA_HWDEP is not set
# CONFIG_SND_HDA_CODEC_REALTEK is not set
CONFIG_SND_HDA_CODEC_ANALOG=y
# CONFIG_SND_HDA_CODEC_SIGMATEL is not set
# CONFIG_SND_HDA_CODEC_VIA is not set
# CONFIG_SND_HDA_CODEC_ATIHDMI is not set
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SIS7019 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
# CONFIG_SND_AC97_POWER_SAVE is not set

#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set

#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set

#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set

#
# SoC Audio support for SuperH
#

#
# ALSA SoC audio for Freescale SOCs
#

#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set

#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set

#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
# CONFIG_USB_PRINTER is not set

#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#

#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_LIBUSUAL is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_MON is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
CONFIG_USB_LCD=m
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_GADGET is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set

#
# MMC/SD Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set

#
# MMC/SD Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
# CONFIG_MMC_RICOH_MMC is not set
# CONFIG_MMC_WBSD is not set
# CONFIG_MMC_TIFM_SD is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_CLEVO_MAIL is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y

#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=y
# CONFIG_EDAC_AMD76X is not set
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_R82600 is not set
# CONFIG_EDAC_I5000 is not set
# CONFIG_RTC_CLASS is not set

#
# Userspace I/O
#
# CONFIG_UIO is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
CONFIG_DMIID=y

#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
# CONFIG_EXT2_FS_POSIX_ACL is not set
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=m
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=m
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_DNOTIFY is not set
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set

#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_NETWORK_FILESYSTEMS is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
# CONFIG_MAGIC_SYSRQ is not set
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_DEBUG_FS is not set
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_KERNEL is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_LATENCYTOP is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_SAMPLES is not set
CONFIG_EARLY_PRINTK=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
CONFIG_IO_DELAY_0XED=y
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=1

#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_BLKCIPHER=y
# CONFIG_CRYPTO_SEQIV is not set
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
CONFIG_CRYPTO_NULL=m
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_SHA1=m
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_DES=m
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=m
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_AUTHENC is not set
CONFIG_CRYPTO_LZO=m
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
CONFIG_VIRTIO_PCI=m
CONFIG_VIRTIO_BALLOON=m

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Matthew Garrett]

On Thu, Feb 21, 2008 at 02:49:39AM +0800, Jeff Chua wrote:

> Here's an interesting discovery. After I found that "echo reboot >
> /sys/power/disk" does reboot, I tried "echo shutdown >
> /sys/power/disk", it does shutdown properly.
> 
> With "platform" it refuses to shutdown. Both reboot and shutdown still
> end up with Mr. Green at resume.

That kind of suggests that the ACPI platform code is hitting the 
hardware directly - we've seen similar issues with PATA controllers. The 
right thing to do here is almost certainly just to avoid explicitly 
powering down hardware on hibernation.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 10:37 am Linus Torvalds wrote:
> This *sounds* like some part of the suspend-to-disk sequence is doing
> something stupid like trying to access the screen after it has been turned
> off, which doesn't surprise me at all. My oft-stated opinion has been that
> suspend-to-disk isn't a suspend at all, and should never have been
> confused with "suspending" anything.
>
> It's "snapshot-and-restore", and my opinion is that:
>
>  - it should *never* call "suspend()"/"resume()" at all (that should be
>    reserved purely for suspend-to-RAM and has real power management
>    issues!)
>
>  - it should have a totally separate "halt/unhalt/restore" thing
>    that has nothing what-so-ever to do with power management, and is
>    purely about stopping the hardware for things like USB and network
>    cards (which otherwise do things like scan their command lists
>    asynchronously) and making sure that the driver state is consistent
>    with that stopped hw state.
>
>  - the people who confuse snapshot/restore with suspend/resume are
>    horrible people that cause problems exactly because driver people then
>    get those things mixed up, and something like the video suspend/resume
>    should probably never have impacted suspend-to-disk in the first place!

Totally agreed.  I remember when I started getting hibernation bug reports 
against this new code and boggling at how hibernate was actually done.  The 
driver actually gets its ->suspend routine called twice with two different 
pm_message_t values.  We tried to do different stuff depending on the 
pm_message_t (like only putting the device in D3hot if PM_EVENT_SUSPEND), but 
it appears we're not doing enough...

> So there seems to be two (probably largely independent) problems:
>
>  - the hang at shutdown that requires you to press-and-hold the power
>    button to actually cut power.
>
>    At a guess: putting the VGA device into D3hot makes the ACPI code that
>    actually does the shutoff unhappy. Probably because it wants to access
>    the device, and ends up not ever getting the replies it wants, since
>    the hardware has been turned off.

Sounds like a good theory... now if we could just use set_power_state in the 
suspend case only.  That's what the latest code *tries* to do...

JEsse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 9:17 am Jeff Chua wrote:
> On Feb 20, 2008 2:19 PM, Jeff Chua
>
> > I'll try the "idle=poll" to see if that works and will try some printk
>
> I don't know what exactly the i915_suspend() and i915_resume() are
> supposed to do because it works better without them.
>
> After inserting "return 0;" right at the top of those two functions,
> suspend (and power-off properly), and resume (without green screen) works
> just fine.
>
> I would like to know what they're for.

They're for saving and restoring GPU state across suspend/resume.  They're 
particularly useful if your machine doesn't re-POST at resume time.  In that 
case your GPU may be totally uninitialized, so either the kernel or X has to 
set it up for you (X only does that partially).

> Tested suspend-to-ram, and suspend-to-disk, both console and X on notebook
> internal LCD display, all works without these two functions.
>
> But, anyway, got down to just one line in i915_drv.c causing the hang
> during suspend. "pci_set_power_state(dev->pdev, PCI_D3hot);".

Interesting, which chipset do you have?  AFAIK that shouldn't cause a hang.

> And green screen problem during resume is caused by i915_restore_vga(dev);

I know I fixed that problem in at least one configuration...  Can you try:
  # echo test > /sys/power/disk
  # echo disk > /sys/power/state
and see if that also turns your screen green?

Also, getting a GPU register dump would be helpful.  The intel_reg_dumper tool 
is built as part of the xf86-video-driver build 
(git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel), can you 
pull that down and try it out?

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On Feb 21, 2008 1:50 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > I would like to know what they're for.
> They're for saving and restoring GPU state across suspend/resume.  They're
> particularly useful if your machine doesn't re-POST at resume time.  In that
> case your GPU may be totally uninitialized, so either the kernel or X has to
> set it up for you (X only does that partially).

Ok. A lot to digest.


> Interesting, which chipset do you have?  AFAIK that shouldn't cause a hang.

(II) intel(0): Integrated Graphics Chipset: Intel(R) 945GM


> I know I fixed that problem in at least one configuration...  Can you try:
>   # echo test > /sys/power/disk
>   # echo disk > /sys/power/state
> and see if that also turns your screen green?

Yes, still green. But I got it to actual reboot with ...

echo reboot > /sys/power/disk

So, next I'll try "shutdown" to see if it work. I was using "platform".


> Also, getting a GPU register dump would be helpful.  The intel_reg_dumper tool

Attached are the two dumps from console. One prior to suspend, and one
after resume.

Thanks,
Jeff.

[-- Attachment #2: prior.txt --]
[-- Type: text/plain, Size: 8584 bytes --]

(II): DumpRegsBegin
(II):    VCLK_DIVISOR_VGA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):    VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6)
(II):        VCLK_POST_DIV: 0x00020002 (vga0 p1 = 4, p2 = 2, vga1 p1 = 2, p2 = 2)
(II):            DPLL_TEST: 0x00010001 ()
(II):         CACHE_MODE_0: 0x00006820
(II):              D_STATE: 0x00000000
(II):        DSPCLK_GATE_D: 0x00001000 (clock gates disabled: DPLUNIT)
(II):       RENCLK_GATE_D1: 0x00000000
(II):       RENCLK_GATE_D2: 0x00000000
(II):                SDVOB: 0x00480000 (disabled, pipe A, stall disabled, not detected)
(II):                SDVOC: 0x00480000 (disabled, pipe A, stall disabled, not detected)
(II):              SDVOUDI: 0x00000077
(II):               DSPARB: 0x00001d9c
(II):               DSPFW1: 0x00000000
(II):               DSPFW2: 0x00000000
(II):               DSPFW3: 0x00000000
(II):                 ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
(II):                 LVDS: 0xc0000300 (enabled, pipe B, 18 bit, 1 channel)
(II):                 DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync)
(II):                 DVOB: 0x00480000 (disabled, pipe A, no stall, -hsync, -vsync)
(II):                 DVOC: 0x00480000 (disabled, pipe A, no stall, -hsync, -vsync)
(II):          DVOA_SRCDIM: 0x00000000
(II):          DVOB_SRCDIM: 0x00000000
(II):          DVOC_SRCDIM: 0x00000000
(II):           PP_CONTROL: 0x00000001 (power target: on)
(II):            PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
(II):         PFIT_CONTROL: 0x80002668
(II):      PFIT_PGM_RATIOS: 0x00000000
(II):      PORT_HOTPLUG_EN: 0x00000020
(II):    PORT_HOTPLUG_STAT: 0x00000000
(II):             DSPACNTR: 0x00000000 (disabled, pipe A)
(II):           DSPASTRIDE: 0x00000000 (0 bytes)
(II):              DSPAPOS: 0x00000000 (0, 0)
(II):             DSPASIZE: 0x00000000 (1, 1)
(II):             DSPABASE: 0x00000000
(II):             DSPASURF: 0x00000000
(II):          DSPATILEOFF: 0x00000000
(II):            PIPEACONF: 0x00000000 (disabled, single-wide)
(II):             PIPEASRC: 0x027f01df (640, 480)
(II):            PIPEASTAT: 0x80000203 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS)
(II):         FBC_CFB_BASE: 0x00000000
(II):          FBC_LL_BASE: 0x00000000
(II):          FBC_CONTROL: 0x00000000
(II):          FBC_COMMAND: 0x00000000
(II):           FBC_STATUS: 0x20000000
(II):         FBC_CONTROL2: 0x00000000
(II):        FBC_FENCE_OFF: 0x00000000
(II):          FBC_MOD_NUM: 0x00000000
(II):                 FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):                 FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):               DPLL_A: 0x04800003 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 8, p2 = 10, SDVO mult 1)
(II):            DPLL_A_MD: 0x00000000
(II):             HTOTAL_A: 0x031f027f (640 active, 800 total)
(II):             HBLANK_A: 0x03170287 (648 start, 792 end)
(II):              HSYNC_A: 0x02ef028f (656 start, 752 end)
(II):             VTOTAL_A: 0x020c01df (480 active, 525 total)
(II):             VBLANK_A: 0x020401e7 (488 start, 517 end)
(II):              VSYNC_A: 0x01eb01e9 (490 start, 492 end)
(II):            BCLRPAT_A: 0x00000000
(II):         VSYNCSHIFT_A: 0x00000000
(II):             DSPBCNTR: 0x49000000 (disabled, pipe B)
(II):           DSPBSTRIDE: 0x00000280 (640 bytes)
(II):              DSPBPOS: 0x00000000 (0, 0)
(II):             DSPBSIZE: 0x018f02cf (720, 400)
(II):             DSPBBASE: 0x00000000
(II):             DSPBSURF: 0x00000000
(II):          DSPBTILEOFF: 0x00000000
(II):            PIPEBCONF: 0x80000000 (enabled, single-wide)
(II):             PIPEBSRC: 0x027f018f (640, 400)
(II):            PIPEBSTAT: 0x80000202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS)
(II):                 FPB0: 0x00020e09 (n = 2, m1 = 14, m2 = 9)
(II):                 FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):               DPLL_B: 0x98046003 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 3, p2 = 14, SDVO mult 1)
(II):            DPLL_B_MD: 0x00000000
(II):             HTOTAL_B: 0x053f03ff (1024 active, 1344 total)
(II):             HBLANK_B: 0x053f03ff (1024 start, 1344 end)
(II):              HSYNC_B: 0x049f0417 (1048 start, 1184 end)
(II):             VTOTAL_B: 0x032502ff (768 active, 806 total)
(II):             VBLANK_B: 0x032502ff (768 start, 806 end)
(II):              VSYNC_B: 0x03080302 (771 start, 777 end)
(II):            BCLRPAT_B: 0x00000000
(II):         VSYNCSHIFT_B: 0x00000000
(II):    VCLK_DIVISOR_VGA0: 0x00031108
(II):    VCLK_DIVISOR_VGA1: 0x00031406
(II):        VCLK_POST_DIV: 0x00020002
(II):             VGACNTRL: 0x22c4008e (enabled)
(II):               TV_CTL: 0x00000000
(II):               TV_DAC: 0x70000000
(II):             TV_CSC_Y: 0x00000000
(II):            TV_CSC_Y2: 0x00000000
(II):             TV_CSC_U: 0x00000000
(II):            TV_CSC_U2: 0x00000000
(II):             TV_CSC_V: 0x00000000
(II):            TV_CSC_V2: 0x00000000
(II):         TV_CLR_KNOBS: 0x00000000
(II):         TV_CLR_LEVEL: 0x00000000
(II):           TV_H_CTL_1: 0x00000000
(II):           TV_H_CTL_2: 0x00000000
(II):           TV_H_CTL_3: 0x00000000
(II):           TV_V_CTL_1: 0x00000000
(II):           TV_V_CTL_2: 0x00000000
(II):           TV_V_CTL_3: 0x00000000
(II):           TV_V_CTL_4: 0x00000000
(II):           TV_V_CTL_5: 0x00000000
(II):           TV_V_CTL_6: 0x00000000
(II):           TV_V_CTL_7: 0x00000000
(II):          TV_SC_CTL_1: 0x00000000
(II):          TV_SC_CTL_2: 0x00000000
(II):          TV_SC_CTL_3: 0x00000000
(II):           TV_WIN_POS: 0x00000000
(II):          TV_WIN_SIZE: 0x00000000
(II):      TV_FILTER_CTL_1: 0x00000000
(II):      TV_FILTER_CTL_2: 0x00000000
(II):      TV_FILTER_CTL_3: 0x00000000
(II):        TV_CC_CONTROL: 0x00000000
(II):           TV_CC_DATA: 0x00000000
(II):          TV_H_LUMA_0: 0x00000000
(II):         TV_H_LUMA_59: 0x00000000
(II):        TV_H_CHROMA_0: 0x00000000
(II):       TV_H_CHROMA_59: 0x00000000
(II):              MI_MODE: 0x00000220
(II): MI_DISPLAY_POWER_DOW: 0x0000007f
(II):         MI_ARB_STATE: 0x00000040
(II):       MI_RDRET_STATE: 0x00000000
(II):              ECOSKPD: 0x00000307
(II):                 SR00: 0x03
(II):                 SR01: 0x00
(II):                 SR02: 0x03
(II):                 SR03: 0x00
(II):                 SR04: 0x02
(II):                 SR05: 0x00
(II):                 SR06: 0x00
(II):                 SR07: 0x00
(II):                  MSR: 0x67
(II):                  ARX: 0x20
(II):                 AR00: 0x00
(II):                 AR01: 0x01
(II):                 AR02: 0x02
(II):                 AR03: 0x03
(II):                 AR04: 0x04
(II):                 AR05: 0x05
(II):                 AR06: 0x06
(II):                 AR07: 0x07
(II):                 AR08: 0x08
(II):                 AR09: 0x09
(II):                 AR0a: 0x0a
(II):                 AR0b: 0x0b
(II):                 AR0c: 0x0c
(II):                 AR0d: 0x0d
(II):                 AR0e: 0x0e
(II):                 AR0f: 0x0f
(II):                 AR10: 0x0c
(II):                 AR11: 0x00
(II):                 AR12: 0x0f
(II):                 AR13: 0x08
(II):                 AR14: 0x00
(II):                 CR00: 0x5f
(II):                 CR01: 0x4f
(II):                 CR02: 0x50
(II):                 CR03: 0x82
(II):                 CR04: 0x55
(II):                 CR05: 0x81
(II):                 CR06: 0xbf
(II):                 CR07: 0x1f
(II):                 CR08: 0x00
(II):                 CR09: 0x4f
(II):                 CR0a: 0x0d
(II):                 CR0b: 0x0e
(II):                 CR0c: 0x21
(II):                 CR0d: 0x20
(II):                 CR0e: 0x28
(II):                 CR0f: 0xa0
(II):                 CR10: 0x9c
(II):                 CR11: 0x8e
(II):                 CR12: 0x8f
(II):                 CR13: 0x28
(II):                 CR14: 0x1f
(II):                 CR15: 0x96
(II):                 CR16: 0xb9
(II):                 CR17: 0xa3
(II):                 CR18: 0xff
(II):                 CR19: 0x00
(II):                 CR1a: 0x00
(II):                 CR1b: 0x00
(II):                 CR1c: 0x00
(II):                 CR1d: 0x00
(II):                 CR1e: 0x00
(II):                 CR1f: 0x00
(II):                 CR20: 0x00
(II):                 CR21: 0x00
(II):                 CR22: 0x20
(II):                 CR23: 0x00
(II):                 CR24: 0x80
(II): pipe A dot 25200 n 3 m1 17 m2 8 p1 8 p2 10
(II): pipe B dot 54166 n 2 m1 14 m2 9 p1 3 p2 14
(II): DumpRegsEnd

[-- Attachment #3: after.txt --]
[-- Type: text/plain, Size: 8602 bytes --]

(II): DumpRegsBegin
(II):    VCLK_DIVISOR_VGA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):    VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6)
(II):        VCLK_POST_DIV: 0x00020002 (vga0 p1 = 4, p2 = 2, vga1 p1 = 2, p2 = 2)
(II):            DPLL_TEST: 0x00010001 ()
(II):         CACHE_MODE_0: 0x00006820
(II):              D_STATE: 0x00000000
(II):        DSPCLK_GATE_D: 0x00001000 (clock gates disabled: DPLUNIT)
(II):       RENCLK_GATE_D1: 0x00000000
(II):       RENCLK_GATE_D2: 0x00000000
(II):                SDVOB: 0x00480000 (disabled, pipe A, stall disabled, not detected)
(II):                SDVOC: 0x00480000 (disabled, pipe A, stall disabled, not detected)
(II):              SDVOUDI: 0x00000016
(II):               DSPARB: 0x00001d9c
(II):               DSPFW1: 0x00000000
(II):               DSPFW2: 0x00000000
(II):               DSPFW3: 0x00000000
(II):                 ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
(II):                 LVDS: 0xc0000300 (enabled, pipe B, 18 bit, 1 channel)
(II):                 DVOA: 0x00000000 (disabled, pipe A, no stall, -hsync, -vsync)
(II):                 DVOB: 0x00480000 (disabled, pipe A, no stall, -hsync, -vsync)
(II):                 DVOC: 0x00480000 (disabled, pipe A, no stall, -hsync, -vsync)
(II):          DVOA_SRCDIM: 0x00000000
(II):          DVOB_SRCDIM: 0x00000000
(II):          DVOC_SRCDIM: 0x00000000
(II):           PP_CONTROL: 0x00000001 (power target: on)
(II):            PP_STATUS: 0xc0000008 (on, ready, sequencing idle)
(II):         PFIT_CONTROL: 0x80002668
(II):      PFIT_PGM_RATIOS: 0x00000000
(II):      PORT_HOTPLUG_EN: 0x00000020
(II):    PORT_HOTPLUG_STAT: 0x00000000
(II):             DSPACNTR: 0x00000000 (disabled, pipe A)
(II):           DSPASTRIDE: 0x00000000 (0 bytes)
(II):              DSPAPOS: 0x00000000 (0, 0)
(II):             DSPASIZE: 0x00000000 (1, 1)
(II):             DSPABASE: 0x00000000
(II):             DSPASURF: 0x00000000
(II):          DSPATILEOFF: 0x00000000
(II):            PIPEACONF: 0x00000000 (disabled, single-wide)
(II):             PIPEASRC: 0x027f01df (640, 480)
(II):            PIPEASTAT: 0x80000203 (status: FIFO_UNDERRUN VSYNC_INT_STATUS VBLANK_INT_STATUS OREG_UPDATE_STATUS)
(II):         FBC_CFB_BASE: 0x00000000
(II):          FBC_LL_BASE: 0x00000000
(II):          FBC_CONTROL: 0x00000000
(II):          FBC_COMMAND: 0x00000000
(II):           FBC_STATUS: 0x20000000
(II):         FBC_CONTROL2: 0x00000000
(II):        FBC_FENCE_OFF: 0x00000000
(II):          FBC_MOD_NUM: 0x00000000
(II):                 FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):                 FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):               DPLL_A: 0x04800003 (disabled, non-dvo, VGA, default clock, DAC/serial mode, p1 = 8, p2 = 10, SDVO mult 1)
(II):            DPLL_A_MD: 0x00000000
(II):             HTOTAL_A: 0x031f027f (640 active, 800 total)
(II):             HBLANK_A: 0x03170287 (648 start, 792 end)
(II):              HSYNC_A: 0x02ef028f (656 start, 752 end)
(II):             VTOTAL_A: 0x020c01df (480 active, 525 total)
(II):             VBLANK_A: 0x020401e7 (488 start, 517 end)
(II):              VSYNC_A: 0x01eb01e9 (490 start, 492 end)
(II):            BCLRPAT_A: 0x00000000
(II):         VSYNCSHIFT_A: 0x00000000
(II):             DSPBCNTR: 0x49000000 (disabled, pipe B)
(II):           DSPBSTRIDE: 0x00000280 (640 bytes)
(II):              DSPBPOS: 0x00000000 (0, 0)
(II):             DSPBSIZE: 0x018f02cf (720, 400)
(II):             DSPBBASE: 0x00000000
(II):             DSPBSURF: 0x00000000
(II):          DSPBTILEOFF: 0x00000000
(II):            PIPEBCONF: 0x80000000 (enabled, single-wide)
(II):             PIPEBSRC: 0x027f018f (640, 400)
(II):            PIPEBSTAT: 0x80000242 (status: FIFO_UNDERRUN VSYNC_INT_STATUS LBLC_EVENT_STATUS VBLANK_INT_STATUS)
(II):                 FPB0: 0x00020e09 (n = 2, m1 = 14, m2 = 9)
(II):                 FPB1: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):               DPLL_B: 0x98046003 (enabled, non-dvo, spread spectrum clock, LVDS mode, p1 = 3, p2 = 14, SDVO mult 1)
(II):            DPLL_B_MD: 0x00000000
(II):             HTOTAL_B: 0x053f03ff (1024 active, 1344 total)
(II):             HBLANK_B: 0x053f03ff (1024 start, 1344 end)
(II):              HSYNC_B: 0x049f0417 (1048 start, 1184 end)
(II):             VTOTAL_B: 0x032502ff (768 active, 806 total)
(II):             VBLANK_B: 0x032502ff (768 start, 806 end)
(II):              VSYNC_B: 0x03080302 (771 start, 777 end)
(II):            BCLRPAT_B: 0x00000000
(II):         VSYNCSHIFT_B: 0x00000000
(II):    VCLK_DIVISOR_VGA0: 0x00031108
(II):    VCLK_DIVISOR_VGA1: 0x00031406
(II):        VCLK_POST_DIV: 0x00020002
(II):             VGACNTRL: 0x22c4008e (enabled)
(II):               TV_CTL: 0x00000000
(II):               TV_DAC: 0x70000000
(II):             TV_CSC_Y: 0x00000000
(II):            TV_CSC_Y2: 0x00000000
(II):             TV_CSC_U: 0x00000000
(II):            TV_CSC_U2: 0x00000000
(II):             TV_CSC_V: 0x00000000
(II):            TV_CSC_V2: 0x00000000
(II):         TV_CLR_KNOBS: 0x00000000
(II):         TV_CLR_LEVEL: 0x00000000
(II):           TV_H_CTL_1: 0x00000000
(II):           TV_H_CTL_2: 0x00000000
(II):           TV_H_CTL_3: 0x00000000
(II):           TV_V_CTL_1: 0x00000000
(II):           TV_V_CTL_2: 0x00000000
(II):           TV_V_CTL_3: 0x00000000
(II):           TV_V_CTL_4: 0x00000000
(II):           TV_V_CTL_5: 0x00000000
(II):           TV_V_CTL_6: 0x00000000
(II):           TV_V_CTL_7: 0x00000000
(II):          TV_SC_CTL_1: 0x00000000
(II):          TV_SC_CTL_2: 0x00000000
(II):          TV_SC_CTL_3: 0x00000000
(II):           TV_WIN_POS: 0x00000000
(II):          TV_WIN_SIZE: 0x00000000
(II):      TV_FILTER_CTL_1: 0x00000000
(II):      TV_FILTER_CTL_2: 0x00000000
(II):      TV_FILTER_CTL_3: 0x00000000
(II):        TV_CC_CONTROL: 0x00000000
(II):           TV_CC_DATA: 0x00000000
(II):          TV_H_LUMA_0: 0x00000000
(II):         TV_H_LUMA_59: 0x00000000
(II):        TV_H_CHROMA_0: 0x00000000
(II):       TV_H_CHROMA_59: 0x00000000
(II):              MI_MODE: 0x00000220
(II): MI_DISPLAY_POWER_DOW: 0x0000007f
(II):         MI_ARB_STATE: 0x00000040
(II):       MI_RDRET_STATE: 0x00000000
(II):              ECOSKPD: 0x00000307
(II):                 SR00: 0x03
(II):                 SR01: 0x00
(II):                 SR02: 0x03
(II):                 SR03: 0x00
(II):                 SR04: 0x02
(II):                 SR05: 0x00
(II):                 SR06: 0x00
(II):                 SR07: 0x00
(II):                  MSR: 0x67
(II):                  ARX: 0x20
(II):                 AR00: 0x12
(II):                 AR01: 0x02
(II):                 AR02: 0x03
(II):                 AR03: 0x04
(II):                 AR04: 0x05
(II):                 AR05: 0x06
(II):                 AR06: 0x07
(II):                 AR07: 0x08
(II):                 AR08: 0x09
(II):                 AR09: 0x0a
(II):                 AR0a: 0x0b
(II):                 AR0b: 0x0c
(II):                 AR0c: 0x11
(II):                 AR0d: 0x0e
(II):                 AR0e: 0x0f
(II):                 AR0f: 0x13
(II):                 AR10: 0x0c
(II):                 AR11: 0x00
(II):                 AR12: 0x0f
(II):                 AR13: 0x08
(II):                 AR14: 0x00
(II):                 CR00: 0x5f
(II):                 CR01: 0x4f
(II):                 CR02: 0x50
(II):                 CR03: 0x82
(II):                 CR04: 0x55
(II):                 CR05: 0x81
(II):                 CR06: 0xbf
(II):                 CR07: 0x1f
(II):                 CR08: 0x00
(II):                 CR09: 0x4f
(II):                 CR0a: 0x0d
(II):                 CR0b: 0x0e
(II):                 CR0c: 0x0c
(II):                 CR0d: 0x30
(II):                 CR0e: 0x13
(II):                 CR0f: 0xb0
(II):                 CR10: 0x9c
(II):                 CR11: 0x0e
(II):                 CR12: 0x8f
(II):                 CR13: 0x28
(II):                 CR14: 0x1f
(II):                 CR15: 0x96
(II):                 CR16: 0xb9
(II):                 CR17: 0xa3
(II):                 CR18: 0xff
(II):                 CR19: 0x00
(II):                 CR1a: 0x00
(II):                 CR1b: 0x00
(II):                 CR1c: 0x00
(II):                 CR1d: 0x00
(II):                 CR1e: 0x00
(II):                 CR1f: 0x00
(II):                 CR20: 0x00
(II):                 CR21: 0x00
(II):                 CR22: 0x20
(II):                 CR23: 0x00
(II):                 CR24: 0x80
(II): pipe A dot 25200 n 3 m1 17 m2 8 p1 8 p2 10
(II): pipe B dot 54166 n 2 m1 14 m2 9 p1 3 p2 14
(II): DumpRegsEnd

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 10:29 am Jeff Chua wrote:
> > I know I fixed that problem in at least one configuration...  Can you
> > try: # echo test > /sys/power/disk
> >   # echo disk > /sys/power/state
> > and see if that also turns your screen green?
>
> Yes, still green. But I got it to actual reboot with ...
>
> echo reboot > /sys/power/disk
>
> So, next I'll try "shutdown" to see if it work. I was using "platform".

Ok, that would be good to try.

> > Also, getting a GPU register dump would be helpful.  The intel_reg_dumper
> > tool
>
> Attached are the two dumps from console. One prior to suspend, and one
> after resume.

Looks like the AR registers are hosed, which is what I thought I fixed...  Can 
you attach your i915_drv.c file just so I can sanity check it?

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

[-- Attachment #1: Type: text/plain, Size: 419 bytes --]

On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:

> > So, next I'll try "shutdown" to see if it work. I was using "platform".
> Ok, that would be good to try.

"shutdown" does power down properly. But still green on resume.


> Looks like the AR registers are hosed, which is what I thought I fixed...  Can
> you attach your i915_drv.c file just so I can sanity check it?

Attached.

Thanks,
Jeff.

[-- Attachment #2: i915_drv.c --]
[-- Type: text/plain, Size: 17809 bytes --]

/* i915_drv.c -- i830,i845,i855,i865,i915 driver -*- linux-c -*-
 */
/*
 *
 * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
 * All Rights Reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the
 * "Software"), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sub license, and/or sell copies of the Software, and to
 * permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 *
 * The above copyright notice and this permission notice (including the
 * next paragraph) shall be included in all copies or substantial portions
 * of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
 * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
 * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 *
 */

#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
#include "i915_drv.h"

#include "drm_pciids.h"

static struct pci_device_id pciidlist[] = {
	i915_PCI_IDS
};

enum pipe {
    PIPE_A = 0,
    PIPE_B,
};

static bool i915_pipe_enabled(struct drm_device *dev, enum pipe pipe)
{
	struct drm_i915_private *dev_priv = dev->dev_private;

	if (pipe == PIPE_A)
		return (I915_READ(DPLL_A) & DPLL_VCO_ENABLE);
	else
		return (I915_READ(DPLL_B) & DPLL_VCO_ENABLE);
}

static void i915_save_palette(struct drm_device *dev, enum pipe pipe)
{
	struct drm_i915_private *dev_priv = dev->dev_private;
	unsigned long reg = (pipe == PIPE_A ? PALETTE_A : PALETTE_B);
	u32 *array;
	int i;

	if (!i915_pipe_enabled(dev, pipe))
		return;

	if (pipe == PIPE_A)
		array = dev_priv->save_palette_a;
	else
		array = dev_priv->save_palette_b;

	for(i = 0; i < 256; i++)
		array[i] = I915_READ(reg + (i << 2));
}

static void i915_restore_palette(struct drm_device *dev, enum pipe pipe)
{
	struct drm_i915_private *dev_priv = dev->dev_private;
	unsigned long reg = (pipe == PIPE_A ? PALETTE_A : PALETTE_B);
	u32 *array;
	int i;

	if (!i915_pipe_enabled(dev, pipe))
		return;

	if (pipe == PIPE_A)
		array = dev_priv->save_palette_a;
	else
		array = dev_priv->save_palette_b;

	for(i = 0; i < 256; i++)
		I915_WRITE(reg + (i << 2), array[i]);
}

static u8 i915_read_indexed(u16 index_port, u16 data_port, u8 reg)
{
	outb(reg, index_port);
	return inb(data_port);
}

static u8 i915_read_ar(u16 st01, u8 reg, u16 palette_enable)
{
	inb(st01);
	outb(palette_enable | reg, VGA_AR_INDEX);
	return inb(VGA_AR_DATA_READ);
}

static void i915_write_ar(u8 st01, u8 reg, u8 val, u16 palette_enable)
{
	inb(st01);
	outb(palette_enable | reg, VGA_AR_INDEX);
	outb(val, VGA_AR_DATA_WRITE);
}

static void i915_write_indexed(u16 index_port, u16 data_port, u8 reg, u8 val)
{
	outb(reg, index_port);
	outb(val, data_port);
}

static void i915_save_vga(struct drm_device *dev)
{
	struct drm_i915_private *dev_priv = dev->dev_private;
	int i;
	u16 cr_index, cr_data, st01;

	/* VGA color palette registers */
	dev_priv->saveDACMASK = inb(VGA_DACMASK);
	/* DACCRX automatically increments during read */
	outb(0, VGA_DACRX);
	/* Read 3 bytes of color data from each index */
	for (i = 0; i < 256 * 3; i++)
		dev_priv->saveDACDATA[i] = inb(VGA_DACDATA);

	/* MSR bits */
	dev_priv->saveMSR = inb(VGA_MSR_READ);
	if (dev_priv->saveMSR & VGA_MSR_CGA_MODE) {
		cr_index = VGA_CR_INDEX_CGA;
		cr_data = VGA_CR_DATA_CGA;
		st01 = VGA_ST01_CGA;
	} else {
		cr_index = VGA_CR_INDEX_MDA;
		cr_data = VGA_CR_DATA_MDA;
		st01 = VGA_ST01_MDA;
	}

	/* CRT controller regs */
	i915_write_indexed(cr_index, cr_data, 0x11,
			   i915_read_indexed(cr_index, cr_data, 0x11) &
			   (~0x80));
	for (i = 0; i < 0x24; i++)
		dev_priv->saveCR[i] =
			i915_read_indexed(cr_index, cr_data, i);
	/* Make sure we don't turn off CR group 0 writes */
	dev_priv->saveCR[0x11] &= ~0x80;

	/* Attribute controller registers */
	inb(st01);
	dev_priv->saveAR_INDEX = inb(VGA_AR_INDEX);
	for (i = 0; i < 20; i++)
		dev_priv->saveAR[i] = i915_read_ar(st01, i, 0);
	inb(st01);
	outb(dev_priv->saveAR_INDEX, VGA_AR_INDEX);
	inb(st01);

	/* Graphics controller registers */
	for (i = 0; i < 9; i++)
		dev_priv->saveGR[i] =
			i915_read_indexed(VGA_GR_INDEX, VGA_GR_DATA, i);

	dev_priv->saveGR[0x10] =
		i915_read_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x10);
	dev_priv->saveGR[0x11] =
		i915_read_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x11);
	dev_priv->saveGR[0x18] =
		i915_read_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x18);

	/* Sequencer registers */
	for (i = 0; i < 8; i++)
		dev_priv->saveSR[i] =
			i915_read_indexed(VGA_SR_INDEX, VGA_SR_DATA, i);
}

static void i915_restore_vga(struct drm_device *dev)
{
	struct drm_i915_private *dev_priv = dev->dev_private;
	int i;
	u16 cr_index, cr_data, st01;

	/* MSR bits */
	outb(dev_priv->saveMSR, VGA_MSR_WRITE);
	if (dev_priv->saveMSR & VGA_MSR_CGA_MODE) {
		cr_index = VGA_CR_INDEX_CGA;
		cr_data = VGA_CR_DATA_CGA;
		st01 = VGA_ST01_CGA;
	} else {
		cr_index = VGA_CR_INDEX_MDA;
		cr_data = VGA_CR_DATA_MDA;
		st01 = VGA_ST01_MDA;
	}

	/* Sequencer registers, don't write SR07 */
	for (i = 0; i < 7; i++)
		i915_write_indexed(VGA_SR_INDEX, VGA_SR_DATA, i,
				   dev_priv->saveSR[i]);

	/* CRT controller regs */
	/* Enable CR group 0 writes */
	i915_write_indexed(cr_index, cr_data, 0x11, dev_priv->saveCR[0x11]);
	for (i = 0; i < 0x24; i++)
		i915_write_indexed(cr_index, cr_data, i, dev_priv->saveCR[i]);

	/* Graphics controller regs */
	for (i = 0; i < 9; i++)
		i915_write_indexed(VGA_GR_INDEX, VGA_GR_DATA, i,
				   dev_priv->saveGR[i]);

	i915_write_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x10,
			   dev_priv->saveGR[0x10]);
	i915_write_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x11,
			   dev_priv->saveGR[0x11]);
	i915_write_indexed(VGA_GR_INDEX, VGA_GR_DATA, 0x18,
			   dev_priv->saveGR[0x18]);

	/* Attribute controller registers */
	for (i = 0; i < 20; i++)
		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
	inb(st01); /* switch back to index mode */
	outb(dev_priv->saveAR_INDEX | 0x20, VGA_AR_INDEX);
	inb(st01);

	/* VGA color palette registers */
	outb(dev_priv->saveDACMASK, VGA_DACMASK);
	/* DACCRX automatically increments during read */
	outb(0, VGA_DACWX);
	/* Read 3 bytes of color data from each index */
	for (i = 0; i < 256 * 3; i++)
		outb(dev_priv->saveDACDATA[i], VGA_DACDATA);

}

static int i915_suspend(struct drm_device *dev, pm_message_t state)
{
	struct drm_i915_private *dev_priv = dev->dev_private;
	int i;

	if (!dev || !dev_priv) {
		printk(KERN_ERR "dev: %p, dev_priv: %p\n", dev, dev_priv);
		printk(KERN_ERR "DRM not initialized, aborting suspend.\n");
		return -ENODEV;
	}

	if (state.event == PM_EVENT_PRETHAW)
		return 0;

	pci_save_state(dev->pdev);
	pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);

	/* Pipe & plane A info */
	dev_priv->savePIPEACONF = I915_READ(PIPEACONF);
	dev_priv->savePIPEASRC = I915_READ(PIPEASRC);
	dev_priv->saveFPA0 = I915_READ(FPA0);
	dev_priv->saveFPA1 = I915_READ(FPA1);
	dev_priv->saveDPLL_A = I915_READ(DPLL_A);
	if (IS_I965G(dev))
		dev_priv->saveDPLL_A_MD = I915_READ(DPLL_A_MD);
	dev_priv->saveHTOTAL_A = I915_READ(HTOTAL_A);
	dev_priv->saveHBLANK_A = I915_READ(HBLANK_A);
	dev_priv->saveHSYNC_A = I915_READ(HSYNC_A);
	dev_priv->saveVTOTAL_A = I915_READ(VTOTAL_A);
	dev_priv->saveVBLANK_A = I915_READ(VBLANK_A);
	dev_priv->saveVSYNC_A = I915_READ(VSYNC_A);
	dev_priv->saveBCLRPAT_A = I915_READ(BCLRPAT_A);

	dev_priv->saveDSPACNTR = I915_READ(DSPACNTR);
	dev_priv->saveDSPASTRIDE = I915_READ(DSPASTRIDE);
	dev_priv->saveDSPASIZE = I915_READ(DSPASIZE);
	dev_priv->saveDSPAPOS = I915_READ(DSPAPOS);
	dev_priv->saveDSPABASE = I915_READ(DSPABASE);
	if (IS_I965G(dev)) {
		dev_priv->saveDSPASURF = I915_READ(DSPASURF);
		dev_priv->saveDSPATILEOFF = I915_READ(DSPATILEOFF);
	}
	i915_save_palette(dev, PIPE_A);
	dev_priv->savePIPEASTAT = I915_READ(I915REG_PIPEASTAT);

	/* Pipe & plane B info */
	dev_priv->savePIPEBCONF = I915_READ(PIPEBCONF);
	dev_priv->savePIPEBSRC = I915_READ(PIPEBSRC);
	dev_priv->saveFPB0 = I915_READ(FPB0);
	dev_priv->saveFPB1 = I915_READ(FPB1);
	dev_priv->saveDPLL_B = I915_READ(DPLL_B);
	if (IS_I965G(dev))
		dev_priv->saveDPLL_B_MD = I915_READ(DPLL_B_MD);
	dev_priv->saveHTOTAL_B = I915_READ(HTOTAL_B);
	dev_priv->saveHBLANK_B = I915_READ(HBLANK_B);
	dev_priv->saveHSYNC_B = I915_READ(HSYNC_B);
	dev_priv->saveVTOTAL_B = I915_READ(VTOTAL_B);
	dev_priv->saveVBLANK_B = I915_READ(VBLANK_B);
	dev_priv->saveVSYNC_B = I915_READ(VSYNC_B);
	dev_priv->saveBCLRPAT_A = I915_READ(BCLRPAT_A);

	dev_priv->saveDSPBCNTR = I915_READ(DSPBCNTR);
	dev_priv->saveDSPBSTRIDE = I915_READ(DSPBSTRIDE);
	dev_priv->saveDSPBSIZE = I915_READ(DSPBSIZE);
	dev_priv->saveDSPBPOS = I915_READ(DSPBPOS);
	dev_priv->saveDSPBBASE = I915_READ(DSPBBASE);
	if (IS_I965GM(dev) || IS_IGD_GM(dev)) {
		dev_priv->saveDSPBSURF = I915_READ(DSPBSURF);
		dev_priv->saveDSPBTILEOFF = I915_READ(DSPBTILEOFF);
	}
	i915_save_palette(dev, PIPE_B);
	dev_priv->savePIPEBSTAT = I915_READ(I915REG_PIPEBSTAT);

	/* CRT state */
	dev_priv->saveADPA = I915_READ(ADPA);

	/* LVDS state */
	dev_priv->savePP_CONTROL = I915_READ(PP_CONTROL);
	dev_priv->savePFIT_PGM_RATIOS = I915_READ(PFIT_PGM_RATIOS);
	dev_priv->saveBLC_PWM_CTL = I915_READ(BLC_PWM_CTL);
	if (IS_I965G(dev))
		dev_priv->saveBLC_PWM_CTL2 = I915_READ(BLC_PWM_CTL2);
	if (IS_MOBILE(dev) && !IS_I830(dev))
		dev_priv->saveLVDS = I915_READ(LVDS);
	if (!IS_I830(dev) && !IS_845G(dev))
		dev_priv->savePFIT_CONTROL = I915_READ(PFIT_CONTROL);
	dev_priv->saveLVDSPP_ON = I915_READ(LVDSPP_ON);
	dev_priv->saveLVDSPP_OFF = I915_READ(LVDSPP_OFF);
	dev_priv->savePP_CYCLE = I915_READ(PP_CYCLE);

	/* FIXME: save TV & SDVO state */

	/* FBC state */
	dev_priv->saveFBC_CFB_BASE = I915_READ(FBC_CFB_BASE);
	dev_priv->saveFBC_LL_BASE = I915_READ(FBC_LL_BASE);
	dev_priv->saveFBC_CONTROL2 = I915_READ(FBC_CONTROL2);
	dev_priv->saveFBC_CONTROL = I915_READ(FBC_CONTROL);

	/* Interrupt state */
	dev_priv->saveIIR = I915_READ(I915REG_INT_IDENTITY_R);
	dev_priv->saveIER = I915_READ(I915REG_INT_ENABLE_R);
	dev_priv->saveIMR = I915_READ(I915REG_INT_MASK_R);

	/* VGA state */
	dev_priv->saveVCLK_DIVISOR_VGA0 = I915_READ(VCLK_DIVISOR_VGA0);
	dev_priv->saveVCLK_DIVISOR_VGA1 = I915_READ(VCLK_DIVISOR_VGA1);
	dev_priv->saveVCLK_POST_DIV = I915_READ(VCLK_POST_DIV);
	dev_priv->saveVGACNTRL = I915_READ(VGACNTRL);

	/* Clock gating state */
	dev_priv->saveDSPCLK_GATE_D = I915_READ(DSPCLK_GATE_D);

	/* Cache mode state */
	dev_priv->saveCACHE_MODE_0 = I915_READ(CACHE_MODE_0);

	/* Memory Arbitration state */
	dev_priv->saveMI_ARB_STATE = I915_READ(MI_ARB_STATE);

	/* Scratch space */
	for (i = 0; i < 16; i++) {
		dev_priv->saveSWF0[i] = I915_READ(SWF0 + (i << 2));
		dev_priv->saveSWF1[i] = I915_READ(SWF10 + (i << 2));
	}
	for (i = 0; i < 3; i++)
		dev_priv->saveSWF2[i] = I915_READ(SWF30 + (i << 2));

	i915_save_vga(dev);

	if (state.event == PM_EVENT_SUSPEND) {
		/* Shut down the device */
		pci_disable_device(dev->pdev);
		pci_set_power_state(dev->pdev, PCI_D3hot);
	}

	return 0;
}

static int i915_resume(struct drm_device *dev)
{
	struct drm_i915_private *dev_priv = dev->dev_private;
	int i;

	pci_set_power_state(dev->pdev, PCI_D0);
	pci_restore_state(dev->pdev);
	if (pci_enable_device(dev->pdev))
		return -1;

	pci_write_config_byte(dev->pdev, LBB, dev_priv->saveLBB);

	/* Pipe & plane A info */
	/* Prime the clock */
	if (dev_priv->saveDPLL_A & DPLL_VCO_ENABLE) {
		I915_WRITE(DPLL_A, dev_priv->saveDPLL_A &
			   ~DPLL_VCO_ENABLE);
		udelay(150);
	}
	I915_WRITE(FPA0, dev_priv->saveFPA0);
	I915_WRITE(FPA1, dev_priv->saveFPA1);
	/* Actually enable it */
	I915_WRITE(DPLL_A, dev_priv->saveDPLL_A);
	udelay(150);
	if (IS_I965G(dev))
		I915_WRITE(DPLL_A_MD, dev_priv->saveDPLL_A_MD);
	udelay(150);

	/* Restore mode */
	I915_WRITE(HTOTAL_A, dev_priv->saveHTOTAL_A);
	I915_WRITE(HBLANK_A, dev_priv->saveHBLANK_A);
	I915_WRITE(HSYNC_A, dev_priv->saveHSYNC_A);
	I915_WRITE(VTOTAL_A, dev_priv->saveVTOTAL_A);
	I915_WRITE(VBLANK_A, dev_priv->saveVBLANK_A);
	I915_WRITE(VSYNC_A, dev_priv->saveVSYNC_A);
	I915_WRITE(BCLRPAT_A, dev_priv->saveBCLRPAT_A);

	/* Restore plane info */
	I915_WRITE(DSPASIZE, dev_priv->saveDSPASIZE);
	I915_WRITE(DSPAPOS, dev_priv->saveDSPAPOS);
	I915_WRITE(PIPEASRC, dev_priv->savePIPEASRC);
	I915_WRITE(DSPABASE, dev_priv->saveDSPABASE);
	I915_WRITE(DSPASTRIDE, dev_priv->saveDSPASTRIDE);
	if (IS_I965G(dev)) {
		I915_WRITE(DSPASURF, dev_priv->saveDSPASURF);
		I915_WRITE(DSPATILEOFF, dev_priv->saveDSPATILEOFF);
	}

	I915_WRITE(PIPEACONF, dev_priv->savePIPEACONF);

	i915_restore_palette(dev, PIPE_A);
	/* Enable the plane */
	I915_WRITE(DSPACNTR, dev_priv->saveDSPACNTR);
	I915_WRITE(DSPABASE, I915_READ(DSPABASE));

	/* Pipe & plane B info */
	if (dev_priv->saveDPLL_B & DPLL_VCO_ENABLE) {
		I915_WRITE(DPLL_B, dev_priv->saveDPLL_B &
			   ~DPLL_VCO_ENABLE);
		udelay(150);
	}
	I915_WRITE(FPB0, dev_priv->saveFPB0);
	I915_WRITE(FPB1, dev_priv->saveFPB1);
	/* Actually enable it */
	I915_WRITE(DPLL_B, dev_priv->saveDPLL_B);
	udelay(150);
	if (IS_I965G(dev))
		I915_WRITE(DPLL_B_MD, dev_priv->saveDPLL_B_MD);
	udelay(150);

	/* Restore mode */
	I915_WRITE(HTOTAL_B, dev_priv->saveHTOTAL_B);
	I915_WRITE(HBLANK_B, dev_priv->saveHBLANK_B);
	I915_WRITE(HSYNC_B, dev_priv->saveHSYNC_B);
	I915_WRITE(VTOTAL_B, dev_priv->saveVTOTAL_B);
	I915_WRITE(VBLANK_B, dev_priv->saveVBLANK_B);
	I915_WRITE(VSYNC_B, dev_priv->saveVSYNC_B);
	I915_WRITE(BCLRPAT_B, dev_priv->saveBCLRPAT_B);

	/* Restore plane info */
	I915_WRITE(DSPBSIZE, dev_priv->saveDSPBSIZE);
	I915_WRITE(DSPBPOS, dev_priv->saveDSPBPOS);
	I915_WRITE(PIPEBSRC, dev_priv->savePIPEBSRC);
	I915_WRITE(DSPBBASE, dev_priv->saveDSPBBASE);
	I915_WRITE(DSPBSTRIDE, dev_priv->saveDSPBSTRIDE);
	if (IS_I965G(dev)) {
		I915_WRITE(DSPBSURF, dev_priv->saveDSPBSURF);
		I915_WRITE(DSPBTILEOFF, dev_priv->saveDSPBTILEOFF);
	}

	I915_WRITE(PIPEBCONF, dev_priv->savePIPEBCONF);

	i915_restore_palette(dev, PIPE_B);
	/* Enable the plane */
	I915_WRITE(DSPBCNTR, dev_priv->saveDSPBCNTR);
	I915_WRITE(DSPBBASE, I915_READ(DSPBBASE));

	/* CRT state */
	I915_WRITE(ADPA, dev_priv->saveADPA);

	/* LVDS state */
	if (IS_I965G(dev))
		I915_WRITE(BLC_PWM_CTL2, dev_priv->saveBLC_PWM_CTL2);
	if (IS_MOBILE(dev) && !IS_I830(dev))
		I915_WRITE(LVDS, dev_priv->saveLVDS);
	if (!IS_I830(dev) && !IS_845G(dev))
		I915_WRITE(PFIT_CONTROL, dev_priv->savePFIT_CONTROL);

	I915_WRITE(PFIT_PGM_RATIOS, dev_priv->savePFIT_PGM_RATIOS);
	I915_WRITE(BLC_PWM_CTL, dev_priv->saveBLC_PWM_CTL);
	I915_WRITE(LVDSPP_ON, dev_priv->saveLVDSPP_ON);
	I915_WRITE(LVDSPP_OFF, dev_priv->saveLVDSPP_OFF);
	I915_WRITE(PP_CYCLE, dev_priv->savePP_CYCLE);
	I915_WRITE(PP_CONTROL, dev_priv->savePP_CONTROL);

	/* FIXME: restore TV & SDVO state */

	/* FBC info */
	I915_WRITE(FBC_CFB_BASE, dev_priv->saveFBC_CFB_BASE);
	I915_WRITE(FBC_LL_BASE, dev_priv->saveFBC_LL_BASE);
	I915_WRITE(FBC_CONTROL2, dev_priv->saveFBC_CONTROL2);
	I915_WRITE(FBC_CONTROL, dev_priv->saveFBC_CONTROL);

	/* VGA state */
	I915_WRITE(VGACNTRL, dev_priv->saveVGACNTRL);
	I915_WRITE(VCLK_DIVISOR_VGA0, dev_priv->saveVCLK_DIVISOR_VGA0);
	I915_WRITE(VCLK_DIVISOR_VGA1, dev_priv->saveVCLK_DIVISOR_VGA1);
	I915_WRITE(VCLK_POST_DIV, dev_priv->saveVCLK_POST_DIV);
	udelay(150);

	/* Clock gating state */
	I915_WRITE (DSPCLK_GATE_D, dev_priv->saveDSPCLK_GATE_D);

	/* Cache mode state */
	I915_WRITE (CACHE_MODE_0, dev_priv->saveCACHE_MODE_0 | 0xffff0000);

	/* Memory arbitration state */
	I915_WRITE (MI_ARB_STATE, dev_priv->saveMI_ARB_STATE | 0xffff0000);

	for (i = 0; i < 16; i++) {
		I915_WRITE(SWF0 + (i << 2), dev_priv->saveSWF0[i]);
		I915_WRITE(SWF10 + (i << 2), dev_priv->saveSWF1[i+7]);
	}
	for (i = 0; i < 3; i++)
		I915_WRITE(SWF30 + (i << 2), dev_priv->saveSWF2[i]);

	i915_restore_vga(dev);

	return 0;
}

static struct drm_driver driver = {
	/* don't use mtrr's here, the Xserver or user space app should
	 * deal with them for intel hardware.
	 */
	.driver_features =
	    DRIVER_USE_AGP | DRIVER_REQUIRE_AGP | /* DRIVER_USE_MTRR |*/
	    DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_IRQ_VBL |
	    DRIVER_IRQ_VBL2,
	.load = i915_driver_load,
	.unload = i915_driver_unload,
	.lastclose = i915_driver_lastclose,
	.preclose = i915_driver_preclose,
	.suspend = i915_suspend,
	.resume = i915_resume,
	.device_is_agp = i915_driver_device_is_agp,
	.vblank_wait = i915_driver_vblank_wait,
	.vblank_wait2 = i915_driver_vblank_wait2,
	.irq_preinstall = i915_driver_irq_preinstall,
	.irq_postinstall = i915_driver_irq_postinstall,
	.irq_uninstall = i915_driver_irq_uninstall,
	.irq_handler = i915_driver_irq_handler,
	.reclaim_buffers = drm_core_reclaim_buffers,
	.get_map_ofs = drm_core_get_map_ofs,
	.get_reg_ofs = drm_core_get_reg_ofs,
	.ioctls = i915_ioctls,
	.fops = {
		 .owner = THIS_MODULE,
		 .open = drm_open,
		 .release = drm_release,
		 .ioctl = drm_ioctl,
		 .mmap = drm_mmap,
		 .poll = drm_poll,
		 .fasync = drm_fasync,
#ifdef CONFIG_COMPAT
		 .compat_ioctl = i915_compat_ioctl,
#endif
	},

	.pci_driver = {
		 .name = DRIVER_NAME,
		 .id_table = pciidlist,
	},

	.name = DRIVER_NAME,
	.desc = DRIVER_DESC,
	.date = DRIVER_DATE,
	.major = DRIVER_MAJOR,
	.minor = DRIVER_MINOR,
	.patchlevel = DRIVER_PATCHLEVEL,
};

static int __init i915_init(void)
{
	driver.num_ioctls = i915_max_ioctl;
	return drm_init(&driver);
}

static void __exit i915_exit(void)
{
	drm_exit(&driver);
}

module_init(i915_init);
module_exit(i915_exit);

MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL and additional rights");

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > So, next I'll try "shutdown" to see if it work. I was using "platform".
> >
> > Ok, that would be good to try.
>
> "shutdown" does power down properly. But still green on resume.

Ok, so Linus' theory about something later in the resume path trying to touch 
video is looking good.

Rafael, is there anyway to prevent the device shutdown in the hibernate path?

> > Looks like the AR registers are hosed, which is what I thought I fixed...
> >  Can you attach your i915_drv.c file just so I can sanity check it?
>
> Attached.

Hm, looks right.  Let me see if I can reproduce this on my T61.

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > "platform".
> > >
> > > Ok, that would be good to try.
> >
> > "shutdown" does power down properly. But still green on resume.
>
> Ok, so Linus' theory about something later in the resume path trying to
> touch video is looking good.
>
> Rafael, is there anyway to prevent the device shutdown in the hibernate
> path?

Given the way the PM core works, do we need to set a flag like this?  I really 
hope there's a better way of doing this...

Thanks,
Jesse

diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 4048f39..a2d6242 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -238,6 +238,13 @@ static void i915_restore_vga(struct drm_device *dev)
 
 }
 
+/*
+ * If we're doing a suspend to disk, we don't want to power off the device.
+ * Unfortunately, the PM core doesn't tell us if we're headed for a regular
+ * S3 state or that it's about to shut down the machine, so we use this flag.
+ */
+static int i915_hibernate;
+
 static int i915_suspend(struct drm_device *dev, pm_message_t state)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
@@ -252,6 +259,9 @@ static int i915_suspend(struct drm_device *dev, 
pm_message_t state)
 	if (state.event == PM_EVENT_PRETHAW)
 		return 0;
 
+	if (state.event == PM_EVENT_FREEZE)
+		i915_hibernate = 1;
+
 	pci_save_state(dev->pdev);
 	pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
 
@@ -366,7 +376,7 @@ static int i915_suspend(struct drm_device *dev, 
pm_message_t state)
 
 	i915_save_vga(dev);
 
-	if (state.event == PM_EVENT_SUSPEND) {
+	if (!i915_hibernate) {
 		/* Shut down the device */
 		pci_disable_device(dev->pdev);
 		pci_set_power_state(dev->pdev, PCI_D3hot);
@@ -385,6 +395,8 @@ static int i915_resume(struct drm_device *dev)
 	if (pci_enable_device(dev->pdev))
 		return -1;
 
+	i915_hibernate = 0;
+
 	pci_write_config_byte(dev->pdev, LBB, dev_priv->saveLBB);
 
 	/* Pipe & plane A info */

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Wednesday, 20 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
> > On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > > On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > > "platform".
> > > >
> > > > Ok, that would be good to try.
> > >
> > > "shutdown" does power down properly. But still green on resume.
> >
> > Ok, so Linus' theory about something later in the resume path trying to
> > touch video is looking good.
> >
> > Rafael, is there anyway to prevent the device shutdown in the hibernate
> > path?
> 
> Given the way the PM core works, do we need to set a flag like this?  I really 
> hope there's a better way of doing this...

I think we should export the target sleep state somehow.

> diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
> index 4048f39..a2d6242 100644
> --- a/drivers/char/drm/i915_drv.c
> +++ b/drivers/char/drm/i915_drv.c
> @@ -238,6 +238,13 @@ static void i915_restore_vga(struct drm_device *dev)
>  
>  }
>  
> +/*
> + * If we're doing a suspend to disk, we don't want to power off the device.
> + * Unfortunately, the PM core doesn't tell us if we're headed for a regular
> + * S3 state or that it's about to shut down the machine, so we use this flag.
> + */
> +static int i915_hibernate;
> +
>  static int i915_suspend(struct drm_device *dev, pm_message_t state)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -252,6 +259,9 @@ static int i915_suspend(struct drm_device *dev, 
> pm_message_t state)
>  	if (state.event == PM_EVENT_PRETHAW)
>  		return 0;
>  
> +	if (state.event == PM_EVENT_FREEZE)
> +		i915_hibernate = 1;
> +
>  	pci_save_state(dev->pdev);
>  	pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
>  
> @@ -366,7 +376,7 @@ static int i915_suspend(struct drm_device *dev, 
> pm_message_t state)
>  
>  	i915_save_vga(dev);
>  
> -	if (state.event == PM_EVENT_SUSPEND) {
> +	if (!i915_hibernate) {
>  		/* Shut down the device */
>  		pci_disable_device(dev->pdev);
>  		pci_set_power_state(dev->pdev, PCI_D3hot);
> @@ -385,6 +395,8 @@ static int i915_resume(struct drm_device *dev)
>  	if (pci_enable_device(dev->pdev))
>  		return -1;
>  
> +	i915_hibernate = 0;
> +
>  	pci_write_config_byte(dev->pdev, LBB, dev_priv->saveLBB);
>  
>  	/* Pipe & plane A info */

Then, the .resume() called after the image creation will clear the flag and I
don't think it's safe to allow it to survive i915_resume() ...

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> 
> I think we should export the target sleep state somehow.

Yeah. By *not* using "->suspend()" for freezing or hibernate.

Please, Rafael - just make the f*cking suspend-to-disk use other routines 
already. 99% of all hardware needs to do exactly *nothing* on 
suspend-to-disk, and the ones that really do need things tend to need to 
not do a whole lot.

For example, the "freeze" action for USB (which is one of the hardest 
things to suspend) should literally be something like just setting the 
controller STOP bit, and waiting for it to have stopped. The "unfreeze" 
should be to just clear the stop bit, while the "restart" should be just a 
controller reset to use the current memory image.

NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND.

It never did. I've told people so for years. Maybe actually seeing the 
problems will make people realize.

So please, we shouldn't call "->suspend[_late]" or "->resume[_early]" at 
all. Not with PMSG_FREEZE, not with PMSG_*anything*.

Can we please get this fixed some day? 

		Linus

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

[Pablo Sanchez]

On Wednesday 20 February 2008 at 3:29 pm, Linus Torvalds penned
about "Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green."

> Can we please get this fixed some day? 

I can't say I even come close to understand what's going on but
getting s2ram to work on my Dell M4300 has been a nightmare.  Even
after writing up how to get it to work (posted on the suspend-devel
list - but no one answered .. yet again), I'm having some quirks.

If I had a bizillion $'s, I'd buy an M4300 for Linus and give him a
million to get it to s2ram!  :p

Cheers,
-- 
Pablo Sanchez - Blueoak Database Engineering, Inc
Ph:    819.459.1926          Toll free:  888.459.1926
Fax:   603.720.7723 (US)     Text Page:  pablo_p@blueoakdb.com

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 12:29 pm Linus Torvalds wrote:
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> > I think we should export the target sleep state somehow.
>
> Yeah. By *not* using "->suspend()" for freezing or hibernate.
>
> Please, Rafael - just make the f*cking suspend-to-disk use other routines
> already. 99% of all hardware needs to do exactly *nothing* on
> suspend-to-disk, and the ones that really do need things tend to need to
> not do a whole lot.

In talking with Rafael on IRC about this, I think we're agreed that we need 
separate entry points.  Even with a kexec based hibernate, we'll probably 
want ->hibernate callbacks so we don't end up shutting down the device.

The current callback system looks like this (according to Rafael and the last 
time I looked):
  ->suspend(PMSG_FREEZE)
  ->resume()
  ->suspend(PMSG_SUSPEND)
  *enter S3 or power off*
  ->resume()
The fact that we get suspend/resume called once before suspend again in the 
hibernate case is somewhat obnoxious, but it's even worse that we don't know 
what we're about to enter after ->suspend(PMSG_SUSPEND).  So in the short 
term it would be nice to at least get the target state exported.

And in the long term we could have:
  ->suspend()
  *enter S3*
  ->resume()
or:
  ->hibernate()
  *kexec to another kernel to save image*
  *power off*
  ->return_from_hibernate() (or somesuch)

Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Wed, 20 Feb 2008, Jesse Barnes wrote:
> 
> The current callback system looks like this (according to Rafael and the last 
> time I looked):
>   ->suspend(PMSG_FREEZE)
>   ->resume()
>   ->suspend(PMSG_SUSPEND)
>   *enter S3 or power off*
>   ->resume()

Yes, it's very messy.

It's messy for a few different reasons:

 - the one you hit: a driver actually has a really hard time telling what 
   PMSG_SUSPEND really means.

 - more importantly, we generally don't want to "suspend/resume" the 
   hardware at all around a power-off, because we're going to resume with 
   the state at the time of the PMSG_FREEZE, which means that the hardware 
   has actually *changed* and been used in between!

that second case is very fundamental for things like USB devices, which in 
theory you can hold alive over a real suspend event (ie a STR event), but 
which absolutely MUST NOT be resumed over a suspend-to-disk event, because 
all the low-level request state is bogus!

So the "->resume" really isn't a resume at all. It's much closer to a 
"->reset".

Of course, the "solution" to this all right now is that we have to reset 
everything even if it *is* a suspend event, so it basically means that STR 
ends up using the much weaker model that snapshot-to-disk uses.

The fundamental problem being that the two really have nothing 
what-so-ever to do with each other. They aren't even similar. Never were.

> And in the long term we could have:
>   ->suspend()
>   *enter S3*
>   ->resume()

Yes, apart from all the complexities (suspend_late/resume_early). So in 
reality it's more than that, but the suspend/resume things are clearly 
nesting, and they have the potential to actually keep state around 
(because we *know* this machine is not going to mess with the devices in 
between).

IOW, here we actually can have as an option "assume the device is there 
when you return".

> or:
>   ->hibernate()
>   *kexec to another kernel to save image*
>   *power off*
>   ->return_from_hibernate() (or somesuch)

Enough people don't trust kexec that I suspect the right thing simply is

	->freeze()		// stop dma, synchronize device state
	*snapshot*
	->unfreeze();		// resume dma
	*save image*
	[ optionally ->poweroff() ]	// do we really care? I'd say no
	*power off*
	->restore()		// reset device to the frozen one

which may have four entry-points that can be illogically mapped to the 
suspend/resume ones like we do now, but they really have nothing to do 
with suspending/resuming.

And notice how while "freeze/restore" kind of pairs like a 
"suspend/resume", it really shouldn't be expected to realistically restore 
the same state at all. The "restore" part is generally much better seen as 
a "reset hardware" than a "resume" thing. Because we literally cannot 
trust *anything* about the state since we froze it - we might have booted 
a different OS in between etc. Very different from suspend/resume.

			Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 1:13 pm Linus Torvalds wrote:
> On Wed, 20 Feb 2008, Jesse Barnes wrote:
> > The current callback system looks like this (according to Rafael and the
> > last time I looked):
> >   ->suspend(PMSG_FREEZE)
> >   ->resume()
> >   ->suspend(PMSG_SUSPEND)
> >   *enter S3 or power off*
> >   ->resume()
>
> Yes, it's very messy.
>
> It's messy for a few different reasons:
>
>  - the one you hit: a driver actually has a really hard time telling what
>    PMSG_SUSPEND really means.
>
>  - more importantly, we generally don't want to "suspend/resume" the
>    hardware at all around a power-off, because we're going to resume with
>    the state at the time of the PMSG_FREEZE, which means that the hardware
>    has actually *changed* and been used in between!

Exactly.

> So the "->resume" really isn't a resume at all. It's much closer to a
> "->reset".

Yeah, in the hibernate case this is definitely true.

> Of course, the "solution" to this all right now is that we have to reset
> everything even if it *is* a suspend event, so it basically means that STR
> ends up using the much weaker model that snapshot-to-disk uses.
>
> The fundamental problem being that the two really have nothing
> what-so-ever to do with each other. They aren't even similar. Never were.
>
> > And in the long term we could have:
> >   ->suspend()
> >   *enter S3*
> >   ->resume()
>
> Yes, apart from all the complexities (suspend_late/resume_early). So in
> reality it's more than that, but the suspend/resume things are clearly
> nesting, and they have the potential to actually keep state around
> (because we *know* this machine is not going to mess with the devices in
> between).

Really, in the simple s3 case we still need early/late stuff?

> IOW, here we actually can have as an option "assume the device is there
> when you return".
>
> > or:
> >   ->hibernate()
> >   *kexec to another kernel to save image*
> >   *power off*
> >   ->return_from_hibernate() (or somesuch)
>
> Enough people don't trust kexec that I suspect the right thing simply is
>
> 	->freeze()		// stop dma, synchronize device state
> 	*snapshot*
> 	->unfreeze();		// resume dma
> 	*save image*
> 	[ optionally ->poweroff() ]	// do we really care? I'd say no
> 	*power off*
> 	->restore()		// reset device to the frozen one
>
> which may have four entry-points that can be illogically mapped to the
> suspend/resume ones like we do now, but they really have nothing to do
> with suspending/resuming.

Well, it seems like we'll have to fix drivers in either case, and isn't a 
kexec approach fundamentally more sound and simple, design-wise?  Rafael 
pointed out some problems with properly setting wakeup states, but I think 
that could be overcome...

> And notice how while "freeze/restore" kind of pairs like a
> "suspend/resume", it really shouldn't be expected to realistically restore
> the same state at all. The "restore" part is generally much better seen as
> a "reset hardware" than a "resume" thing. Because we literally cannot
> trust *anything* about the state since we froze it - we might have booted
> a different OS in between etc. Very different from suspend/resume.

Yeah, definitely.  It has to be much more robust and deal with configuration 
changes, etc. (within reason).

Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Wed, 20 Feb 2008, Jesse Barnes wrote:
> 
> Really, in the simple s3 case we still need early/late stuff?

Absolutely. 

Two big reasons:

 - debuggability

   I know we don't do this correctly right now, but I want to be able to 
   at least feel like we can some day actually do printk's etc through 99% 
   of the suspend/resume cycle. It's a *huge* thing for debugging problems 
   that happen in the wild, and one of the biggest issues is that we 
   currently usualyl just get a "the machine died" message when suspend or 
   resume doesn't work.

   Yes, doing printk's to the Intel management flash stuff can help a lot 
   here, and I want that too, but I'd really like to shut down consoles 
   individually rather than having the "big hammer" approach that shuts 
   them up entirely over the whole suspend/resume sequence (or not at all, 
   if you use "no_console_suspend").

   And I'd *really* like to do things like VGA-console shutdown in the 
   late phase (and resume early).

 - it's actually likely *much* simpler for some devices. 

   Simple devices (and that includes things like PCI bridges etc, but 
   also potentially USB host controllers etc) are things that can often be 
   trivially suspended - all the complexity is really not in the 
   controller itself, but beyond, in the bus that it actually drives.

   And the late-suspend/early-resume means that you don't have to worry 
   about things like interrupts happening while you're suspended. Yes, 
   putting the device into D3 will disable interrupts from that device too 
   (unless there are bugs), *BUT* you may be sharing an interrupt line, 
   and interrupts may be posted and delayed, so an earlier interrupt may 
   well be pending etc.

   suspending late and resuming early just avoids those issues entirely.

Sometimes these things interact. For example, firewire is certainly not 
trivial to suspend as a "subsystem" thing (ie all the devices behind the 
firewire bridge need to do magic things, like spinning down etc that 
obviously can not happen in the final "late" phase), but the firewire 
controller itself is likely trivial to suspend/resume and can easily be 
handled in the late/early routines. And guess what? It's also exactly what 
you want to happen in case you end up using the firewire RDMA as a debug 
aid.

IOW, you want that firewire controller (and the PCI bridges) working 
really early, so that if a problem does happen when you resume some more 
complex device (say, one of the graphics chips that need X to really come 
alive), you can use the firewire rdma to read out the kernel log buffer 
from memory.

> Well, it seems like we'll have to fix drivers in either case, and isn't a 
> kexec approach fundamentally more sound and simple, design-wise?  Rafael 
> pointed out some problems with properly setting wakeup states, but I think 
> that could be overcome...

I don't personally mind kexec at all, but on the other hand, I don't care 
about suspend-to-disk in the first place. I do know that some people 
really don't want it, and I suspect that they have valid reasons. Ranging 
from memory use to simply just performance. 

		Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[david]

On Wed, 20 Feb 2008, Linus Torvalds wrote:

>> Well, it seems like we'll have to fix drivers in either case, and isn't a
>> kexec approach fundamentally more sound and simple, design-wise?  Rafael
>> pointed out some problems with properly setting wakeup states, but I think
>> that could be overcome...
>
> I don't personally mind kexec at all, but on the other hand, I don't care
> about suspend-to-disk in the first place. I do know that some people
> really don't want it, and I suspect that they have valid reasons. Ranging
> from memory use to simply just performance.

I've been watching for kexec hibernate for a little while now, and the 
last I saw was that acpi was incompatible with the kexec hibernate (but 
the suspend folks were still claiming that devices needed to be put in the 
'right mode' not just powered off. I've been waiting to see this resolved.

David Lang

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Mark Lord]

david@lang.hm wrote:
..
> I've been watching for kexec hibernate for a little while now, and the 
> last I saw was that acpi was incompatible with the kexec hibernate (but 
> the suspend folks were still claiming that devices needed to be put in 
> the 'right mode' not just powered off. I've been waiting to see this 
> resolved.
..

Yeah, exactly.  What's so special about poweroff on hibernation?
Why even bother with the special "S4" state there?
I want a real full poweroff, or at least I think I do.  Why wouldn't I?

????

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Mark Lord wrote:
> david@lang.hm wrote:
> ..
> > I've been watching for kexec hibernate for a little while now, and the 
> > last I saw was that acpi was incompatible with the kexec hibernate (but 
> > the suspend folks were still claiming that devices needed to be put in 
> > the 'right mode' not just powered off. I've been waiting to see this 
> > resolved.
> ..
> 
> Yeah, exactly.  What's so special about poweroff on hibernation?
> Why even bother with the special "S4" state there?

(1) To be able to wake up with the help of devices that can't wake
    the system up from S5 (power off)
(2) To handle some platform devices appropriately over the cycle

> I want a real full poweroff, or at least I think I do.  Why wouldn't I?
> 
> ????

You may want that, some people may not want it.

We are supposed to handle S4, the BIOS/platform may expect us to do that, so
IMO this is a good enough reason to do it.  Especially that we can.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Mark Lord]

Rafael J. Wysocki wrote:
> On Friday, 22 of February 2008, Mark Lord wrote:
>> david@lang.hm wrote:
>> ..
>>> I've been watching for kexec hibernate for a little while now, and the 
>>> last I saw was that acpi was incompatible with the kexec hibernate (but 
>>> the suspend folks were still claiming that devices needed to be put in 
>>> the 'right mode' not just powered off. I've been waiting to see this 
>>> resolved.
>> ..
>>
>> Yeah, exactly.  What's so special about poweroff on hibernation?
>> Why even bother with the special "S4" state there?
> 
> (1) To be able to wake up with the help of devices that can't wake
>     the system up from S5 (power off)
> (2) To handle some platform devices appropriately over the cycle
..

That's the theory.  I've read about it, but have yet to imagine
any real-life situation where it applies.

But this isn't my speciality, so.. do you have experience with any real examples?

Thanks!

>> I want a real full poweroff, or at least I think I do.  Why wouldn't I?
>>
>> ????
> 
> You may want that, some people may not want it.
> 
> We are supposed to handle S4, the BIOS/platform may expect us to do that, so
> IMO this is a good enough reason to do it.  Especially that we can.
> 
> Thanks,
> Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Mark Lord wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 22 of February 2008, Mark Lord wrote:
> >> david@lang.hm wrote:
> >> ..
> >>> I've been watching for kexec hibernate for a little while now, and the 
> >>> last I saw was that acpi was incompatible with the kexec hibernate (but 
> >>> the suspend folks were still claiming that devices needed to be put in 
> >>> the 'right mode' not just powered off. I've been waiting to see this 
> >>> resolved.
> >> ..
> >>
> >> Yeah, exactly.  What's so special about poweroff on hibernation?
> >> Why even bother with the special "S4" state there?
> > 
> > (1) To be able to wake up with the help of devices that can't wake
> >     the system up from S5 (power off)
> > (2) To handle some platform devices appropriately over the cycle
> ..
> 
> That's the theory.  I've read about it, but have yet to imagine
> any real-life situation where it applies.
> 
> But this isn't my speciality, so.. do you have experience with any real examples?

Yup.  The fan in my notebook behaves incorrectly after a resume from
hibernation if S5 is entered instead of S4 during it.

I don't know why exactly it happens, but that's how it goes.

Also, some machines are reported to behave incorrectly after a "shutdown"
mode hibernation, while the same machines work just fine after a "platform"
mode hibernation.  So at least for these machines it seems to matter.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[david]

On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:

> On Friday, 22 of February 2008, Mark Lord wrote:
>> Rafael J. Wysocki wrote:
>>> On Friday, 22 of February 2008, Mark Lord wrote:
>>>> david@lang.hm wrote:
>>>> ..
>>>>> I've been watching for kexec hibernate for a little while now, and the
>>>>> last I saw was that acpi was incompatible with the kexec hibernate (but
>>>>> the suspend folks were still claiming that devices needed to be put in
>>>>> the 'right mode' not just powered off. I've been waiting to see this
>>>>> resolved.
>>>> ..
>>>>
>>>> Yeah, exactly.  What's so special about poweroff on hibernation?
>>>> Why even bother with the special "S4" state there?
>>>
>>> (1) To be able to wake up with the help of devices that can't wake
>>>     the system up from S5 (power off)
>>> (2) To handle some platform devices appropriately over the cycle
>> ..
>>
>> That's the theory.  I've read about it, but have yet to imagine
>> any real-life situation where it applies.
>>
>> But this isn't my speciality, so.. do you have experience with any real examples?
>
> Yup.  The fan in my notebook behaves incorrectly after a resume from
> hibernation if S5 is entered instead of S4 during it.

so if you power off your laptop the fan doesn't work when you turn it back 
on?????

> I don't know why exactly it happens, but that's how it goes.
>
> Also, some machines are reported to behave incorrectly after a "shutdown"
> mode hibernation, while the same machines work just fine after a "platform"
> mode hibernation.  So at least for these machines it seems to matter.

given that we don't have a pure "shutdown" option available to try I don't 
see how this can be said to have been tested.

currently any attempts to do a shutdown type hibernate are tangled in the 
other code that is there for the suspend modes. this makes it _very_ hard 
to say that the hardware requires something as opposed to the strong 
possibility that the software is doing something wrong.

there are also a _lot_ of people who are not able to reliably use the 
existing "platform" mode hibernation, so it's not a fair statement to say 
that it's the 'right' thing to do. If you want to make it an option, fine. 
But please give those of us who don't care about these other wakeup 
options, and who want to be able to use other OS's while linux is stopped 
an option as well.

David Lang

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Friday, 22 of February 2008, david@lang.hm wrote:
> On Fri, 22 Feb 2008, Rafael J. Wysocki wrote:
> 
> > On Friday, 22 of February 2008, Mark Lord wrote:
> >> Rafael J. Wysocki wrote:
> >>> On Friday, 22 of February 2008, Mark Lord wrote:
> >>>> david@lang.hm wrote:
> >>>> ..
> >>>>> I've been watching for kexec hibernate for a little while now, and the
> >>>>> last I saw was that acpi was incompatible with the kexec hibernate (but
> >>>>> the suspend folks were still claiming that devices needed to be put in
> >>>>> the 'right mode' not just powered off. I've been waiting to see this
> >>>>> resolved.
> >>>> ..
> >>>>
> >>>> Yeah, exactly.  What's so special about poweroff on hibernation?
> >>>> Why even bother with the special "S4" state there?
> >>>
> >>> (1) To be able to wake up with the help of devices that can't wake
> >>>     the system up from S5 (power off)
> >>> (2) To handle some platform devices appropriately over the cycle
> >> ..
> >>
> >> That's the theory.  I've read about it, but have yet to imagine
> >> any real-life situation where it applies.
> >>
> >> But this isn't my speciality, so.. do you have experience with any real examples?
> >
> > Yup.  The fan in my notebook behaves incorrectly after a resume from
> > hibernation if S5 is entered instead of S4 during it.
> 
> so if you power off your laptop the fan doesn't work when you turn it back 
> on?????

No, it works fine then.

> > I don't know why exactly it happens, but that's how it goes.
> >
> > Also, some machines are reported to behave incorrectly after a "shutdown"
> > mode hibernation, while the same machines work just fine after a "platform"
> > mode hibernation.  So at least for these machines it seems to matter.
> 
> given that we don't have a pure "shutdown" option available to try I don't 
> see how this can be said to have been tested.

Yes, we have.

> currently any attempts to do a shutdown type hibernate are tangled in the 
> other code that is there for the suspend modes. this makes it _very_ hard 
> to say that the hardware requires something as opposed to the strong 
> possibility that the software is doing something wrong.

How is it tangled exactly?

> there are also a _lot_ of people who are not able to reliably use the 
> existing "platform" mode hibernation, so it's not a fair statement to say 
> that it's the 'right' thing to do. If you want to make it an option, fine. 
> But please give those of us who don't care about these other wakeup 
> options, and who want to be able to use other OS's while linux is stopped 
> an option as well.

There is such an option.  Put

# echo shutdown > /sys/power/disk

into the init scripts and it will do the trick.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Wednesday, 20 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 1:13 pm Linus Torvalds wrote:
> > On Wed, 20 Feb 2008, Jesse Barnes wrote:
> > > The current callback system looks like this (according to Rafael and the
> > > last time I looked):
> > >   ->suspend(PMSG_FREEZE)
> > >   ->resume()
> > >   ->suspend(PMSG_SUSPEND)
> > >   *enter S3 or power off*
> > >   ->resume()
> >
> > Yes, it's very messy.
> >
> > It's messy for a few different reasons:
> >
> >  - the one you hit: a driver actually has a really hard time telling what
> >    PMSG_SUSPEND really means.

In fact the driver can find out in which state to put the device into,
depending on the target ACPI state which is known.

> >  - more importantly, we generally don't want to "suspend/resume" the
> >    hardware at all around a power-off, because we're going to resume with
> >    the state at the time of the PMSG_FREEZE, which means that the hardware
> >    has actually *changed* and been used in between!
> 
> Exactly.
> 
> > So the "->resume" really isn't a resume at all. It's much closer to a
> > "->reset".
> 
> Yeah, in the hibernate case this is definitely true.

Agreed.

> > Of course, the "solution" to this all right now is that we have to reset
> > everything even if it *is* a suspend event, so it basically means that STR
> > ends up using the much weaker model that snapshot-to-disk uses.
> >
> > The fundamental problem being that the two really have nothing
> > what-so-ever to do with each other. They aren't even similar. Never were.
> >
> > > And in the long term we could have:
> > >   ->suspend()
> > >   *enter S3*
> > >   ->resume()
> >
> > Yes, apart from all the complexities (suspend_late/resume_early). So in
> > reality it's more than that, but the suspend/resume things are clearly
> > nesting, and they have the potential to actually keep state around
> > (because we *know* this machine is not going to mess with the devices in
> > between).
> 
> Really, in the simple s3 case we still need early/late stuff?

Yes, we do.  There are devices that need to be suspended with interrupts off.

> > IOW, here we actually can have as an option "assume the device is there
> > when you return".

That is, unless the user pulls out that pendrive while suspended, no?

> > > or:
> > >   ->hibernate()
> > >   *kexec to another kernel to save image*
> > >   *power off*
> > >   ->return_from_hibernate() (or somesuch)
> >
> > Enough people don't trust kexec that I suspect the right thing simply is
> >
> > 	->freeze()		// stop dma, synchronize device state
> > 	*snapshot*
> > 	->unfreeze();		// resume dma
> > 	*save image*
> > 	[ optionally ->poweroff() ]	// do we really care? I'd say no

We do, if there are devices that wake us up from S4 and don't wake us up from
S5, for example.  Plus this f*cking fan in my box that doesn't work after the
resume if we don't do ->poweroff() ...

> > 	*power off*
> > 	->restore()		// reset device to the frozen one
> >
> > which may have four entry-points that can be illogically mapped to the
> > suspend/resume ones like we do now, but they really have nothing to do
> > with suspending/resuming.

Apart from putting devices into the right low power states, that is.

> Well, it seems like we'll have to fix drivers in either case, and isn't a 
> kexec approach fundamentally more sound and simple, design-wise?  Rafael 
> pointed out some problems with properly setting wakeup states, but I think 
> that could be overcome...

Your honor, I would like to register a differing opinion ...
 
> > And notice how while "freeze/restore" kind of pairs like a
> > "suspend/resume", it really shouldn't be expected to realistically restore
> > the same state at all. The "restore" part is generally much better seen as
> > a "reset hardware" than a "resume" thing.

That's absolutely correct.

> > Because we literally cannot trust *anything* about the state since we froze
> > it - we might have booted a different OS in between etc. Very different from
> > suspend/resume. 
> 
> Yeah, definitely.  It has to be much more robust and deal with configuration 
> changes, etc. (within reason).

Agreed.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> > >
> > > which may have four entry-points that can be illogically mapped to the
> > > suspend/resume ones like we do now, but they really have nothing to do
> > > with suspending/resuming.
> 
> Apart from putting devices into the right low power states, that is.

And by "right low power states" you mean "wrong low-power states", right?

The thing is, they really *are* the wrong states for 99% of all hardware.

If you really have a piece of hardware that you want to have the 
"->poweroff()" thing do the same as "->suspend()", then hey, just use the 
same function (or better yet, use two different functions with a call to a
shared part).

Because IT IS NOT TRUE that ->suspend() puts the devices in the "right 
power state". The power states are likely to be totally different for S3 
and for poweroff, and they are going to differ in different ways depending 
on the device type.

One example would be the one that started this version of the whole 
discussion (shock horror! We're on subject!) ie when you do a system 
shutdown, you generally do not even *want* to put individual devices into 
low-power states at all, because the actual "power off the system" thing 
will take care of it for you much better.

So to take just something as simple as VGA as an example: you really do 
not want to suspend that device, because you want to see the poweroff 
messages until the very end. 

So that final device ->poweroff function really has absolutely *nothing* 
in common with the device ->suspend[_late] functions, simply because 
almost any sane driver would decide to do different things.

Of course, we can continue to do the insane thing and just continue to use 
inappropriate and misleadign function callback names, and then encodign 
what the *real* action should be in the argument and/or in magic 
system-wide state parameters.

So in that sense, it's certainly totally the same thing whether we call it 
->shutdown or ->poweroff or ->eat_a_banana, since you could always just 
look at the argument and other clues, and decide that *this* time, for 
*this* kind of device, the "eat a banana" callback actually means that we 
should power it off, but wouldn't it be a lot more logical to just make it 
clear in the first place that they aren't called for the same reason at 
all?

I'd claim that it's much easier for everybody (and _especially_ for device 
driver writers) to have

	static int my_shutdown(struct pci_device *dev, int state)
	{
		.. do something ..
	}

	static int my_suspend(struct pci_device *dev, int state)
	{
		.. do something ..
	}

	...
	.shutdown = my_shutdown,
	.suspend = my_suspend,
	...	

than to have

	static int my_suspend(struct pci_device *dev, state)
	{
		.. common code ..
		if (state == XYZZY)
			..special code..
		else
			..other case code..
	}

	...
	.suspend = my_suspend
	...

even if the latter might be fewer lines. It doesn't really matter if it's 
fewer, does it, if the alternate version is more obvious about what it 
does?

The other issue is that I've long wanted to make sure that when people fix 
suspend-to-ram, they don't screw up suspend-to-disk by mistake and vice 
versa. When a driver writer makes changes, he shouldn't have the kind of 
illogical "oops, unintended consequences" issues in general. It should be 
pretty damn obvious when he changes suspend code vs when he changes 
snapshot/restore code.

We've somewhat untangled that on the "core kernel" layer, but we've left 
the driver confusion alone.

		Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Linus Torvalds wrote:
> 
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> > > >
> > > > which may have four entry-points that can be illogically mapped to the
> > > > suspend/resume ones like we do now, but they really have nothing to do
> > > > with suspending/resuming.
> > 
> > Apart from putting devices into the right low power states, that is.
> 
> And by "right low power states" you mean "wrong low-power states", right?

No, I don't.

> The thing is, they really *are* the wrong states for 99% of all hardware.
> 
> If you really have a piece of hardware that you want to have the 
> "->poweroff()" thing do the same as "->suspend()", then hey, just use the 
> same function (or better yet, use two different functions with a call to a
> shared part).
> 
> Because IT IS NOT TRUE that ->suspend() puts the devices in the "right 
> power state". The power states are likely to be totally different for S3 
> and for poweroff, and they are going to differ in different ways depending 
> on the device type.

In fact we have acpi_pci_choose_state() that tells the driver which power
state to put the device into in ->suspend().  If that is used, the device ends
up in the state expected by to BIOS for S4.

> One example would be the one that started this version of the whole 
> discussion (shock horror! We're on subject!) ie when you do a system 
> shutdown, you generally do not even *want* to put individual devices into 
> low-power states at all, because the actual "power off the system" thing 
> will take care of it for you much better.

No.  Again, if there are devices that wake us up from S4, but not from S5,
they need to be handled differently in the *enter S4* case (hibernation) and
in the *enter S5* case (powering off the system).
 
> So to take just something as simple as VGA as an example: you really do 
> not want to suspend that device, because you want to see the poweroff 
> messages until the very end. 
> 
> So that final device ->poweroff function really has absolutely *nothing* 
> in common with the device ->suspend[_late] functions, simply because 
> almost any sane driver would decide to do different things.

Yes, it would.  Still, the common thing is, it (ie. ->poweroff) _may_ want to
put the device into a low power state different from D3.

> Of course, we can continue to do the insane thing and just continue to use 
> inappropriate and misleadign function callback names, and then encodign 
> what the *real* action should be in the argument and/or in magic 
> system-wide state parameters.

To clarify, I agree that we should use different callbacks for hibernation.
I'm only saying that _in_ _general_ we may need the ->poweroff callback.

> So in that sense, it's certainly totally the same thing whether we call it 
> ->shutdown or ->poweroff or ->eat_a_banana, since you could always just 
> look at the argument and other clues, and decide that *this* time, for 
> *this* kind of device, the "eat a banana" callback actually means that we 
> should power it off, but wouldn't it be a lot more logical to just make it 
> clear in the first place that they aren't called for the same reason at 
> all?
> 
> I'd claim that it's much easier for everybody (and _especially_ for device 
> driver writers) to have
> 
> 	static int my_shutdown(struct pci_device *dev, int state)
> 	{
> 		.. do something ..
> 	}
> 
> 	static int my_suspend(struct pci_device *dev, int state)
> 	{
> 		.. do something ..
> 	}
> 
> 	...
> 	.shutdown = my_shutdown,
> 	.suspend = my_suspend,
> 	...	
> 
> than to have
> 
> 	static int my_suspend(struct pci_device *dev, state)
> 	{
> 		.. common code ..
> 		if (state == XYZZY)
> 			..special code..
> 		else
> 			..other case code..
> 	}
> 
> 	...
> 	.suspend = my_suspend
> 	...
> 
> even if the latter might be fewer lines. It doesn't really matter if it's 
> fewer, does it, if the alternate version is more obvious about what it 
> does?
> 
> The other issue is that I've long wanted to make sure that when people fix 
> suspend-to-ram, they don't screw up suspend-to-disk by mistake and vice 
> versa. When a driver writer makes changes, he shouldn't have the kind of 
> illogical "oops, unintended consequences" issues in general. It should be 
> pretty damn obvious when he changes suspend code vs when he changes 
> snapshot/restore code.
> 
> We've somewhat untangled that on the "core kernel" layer, but we've left 
> the driver confusion alone.

Well, I agree with that.

As I said before, that's mainly because I've been busy with other stuff
recently.  Now, with the Alex's help, I'm hoping to take care of it soon.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> 
> In fact we have acpi_pci_choose_state() that tells the driver which power
> state to put the device into in ->suspend().  If that is used, the device ends
> up in the state expected by to BIOS for S4.

First off, nobody should *ever* use that directly anyway.

Secondly, the one that people should use ("pci_choose_state()") doesn't 
actually do what you claim it does. It does all kinds of wrong things, and 
doesn't even take the target state into account at all. So look again.

> No.  Again, if there are devices that wake us up from S4, but not from S5,
> they need to be handled differently in the *enter S4* case (hibernation) and
> in the *enter S5* case (powering off the system).

And again, what does this have to do with (the example I used) the 
graphics hardware? Answer: nothing. The example I gave you we simply DO 
THE WRONG THING FOR.

Same thing for things like USB devices - where pci_choose_state() doesn't 
work to begin with. Why do we call "suspend()" on such a thing when we 
don't want to suspend it? We shouldn't. We should call "freeze/unfreeze" 
(which are no-ops) and then finally perhaps "poweroff", and that final 
stage might want to spin things down or similar.

But *none* of it has anything to do with suspend, and none of it has 
anything to do with pci_choose_state() (much less acpi_pci_choose_state)

The fact is, we should let the driver decide, and we should make it clear 
to the driver writer what he is deciding about - rather than basically lie 
and say "suspend the device and put it into D3" even when that's the last 
thing it should ever do.

			Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Linus Torvalds wrote:
> 
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> > 
> > In fact we have acpi_pci_choose_state() that tells the driver which power
> > state to put the device into in ->suspend().  If that is used, the device ends
> > up in the state expected by to BIOS for S4.
> 
> First off, nobody should *ever* use that directly anyway.

Yes, sorry.

> Secondly, the one that people should use ("pci_choose_state()") doesn't 
> actually do what you claim it does. It does all kinds of wrong things, and 
> doesn't even take the target state into account at all. So look again.

Well, if platform_pci_choose_state() is defined, pci_choose_state() returns
its result and on ACPI systems that points to acpi_pci_choose_state(), so in
fact it does what I said (apart from the error path). 

> > No.  Again, if there are devices that wake us up from S4, but not from S5,
> > they need to be handled differently in the *enter S4* case (hibernation) and
> > in the *enter S5* case (powering off the system).
> 
> And again, what does this have to do with (the example I used) the 
> graphics hardware? Answer: nothing. The example I gave you we simply DO 
> THE WRONG THING FOR.
> 
> Same thing for things like USB devices - where pci_choose_state() doesn't 
> work to begin with. Why do we call "suspend()" on such a thing when we 
> don't want to suspend it? We shouldn't. We should call "freeze/unfreeze" 
> (which are no-ops) and then finally perhaps "poweroff", and that final 
> stage might want to spin things down or similar.

I'm already convinced, really. :-)

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Linus Torvalds]

On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> 
> > Secondly, the one that people should use ("pci_choose_state()") doesn't 
> > actually do what you claim it does. It does all kinds of wrong things, and 
> > doesn't even take the target state into account at all. So look again.
> 
> Well, if platform_pci_choose_state() is defined, pci_choose_state() returns
> its result and on ACPI systems that points to acpi_pci_choose_state(), so in
> fact it does what I said (apart from the error path). 

Did you check closer?

I repeat: acpi_pci_choose_state() (when called from pci_choose_state()) 
doesn't even look at the target 'state'. It just blindly assumes that you 
want the deepest sleep-state you can have.

Which happens to be correct for normal suspend, but means that if you want 
to test other states (through '/sys/devices/.../power'), that sounds 
broken.

I didn't check any closer, but go check it yourself. The short and sweet: 
acpi_pci_choose_state() totally ignores its 'state' argument. Do you 
really think that's correct? But yes, "pci_choose_state()' effectively 
does that too, apart from PM_EVENT_ON, which is never used.

(But the whole and only point of pci_choose_state() was to do the 
PM_EVENT_FREEZE thing differently, which it doesn't do, so I think the 
real issue here is that the interface is really rather mis-designed)

I suspect most people who ever really looked and worked on this code had a 
specific device in mind, and I'm sure that all of the code individually 
always ends up making sense from the standpoint of some specific device 
driver. It's just that it never seems to make sense from a bigger issues 
standpoint, and often seems senseless from the standpoint of other devices 
of other types.

			Linus

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Linus Torvalds wrote:
> 
> On Thu, 21 Feb 2008, Rafael J. Wysocki wrote:
> > 
> > > Secondly, the one that people should use ("pci_choose_state()") doesn't 
> > > actually do what you claim it does. It does all kinds of wrong things, and 
> > > doesn't even take the target state into account at all. So look again.
> > 
> > Well, if platform_pci_choose_state() is defined, pci_choose_state() returns
> > its result and on ACPI systems that points to acpi_pci_choose_state(), so in
> > fact it does what I said (apart from the error path). 
> 
> Did you check closer?

Yes, I did.

> I repeat: acpi_pci_choose_state() (when called from pci_choose_state()) 
> doesn't even look at the target 'state'. It just blindly assumes that you 
> want the deepest sleep-state you can have.

acpi_pm_device_sleep_state() (that is called by acpi_pci_choose_state())
takes the target state directly from the ACPI layer.

We just want to get rid of the argument passed to ->suspend() eventually, but
there may be many _suspend_ states available (eg. "mem" and "standby") and
for each of them there may be different constraints on the device's state.  We
have to tell the driver which device states are possible in the target system
sleep state.  Right now we arbitrarily choose the one with the lowest power
usage - for given target system sleep state.

> Which happens to be correct for normal suspend, but means that if you want 
> to test other states (through '/sys/devices/.../power'), that sounds 
> broken.

This interface is not available any more (ie. there's only "wakeup" in
/sys/devices/.../power).

> I didn't check any closer, but go check it yourself. The short and sweet: 
> acpi_pci_choose_state() totally ignores its 'state' argument. Do you 
> really think that's correct?

Yes, I do.

> But yes, "pci_choose_state()' effectively does that too, apart from
> PM_EVENT_ON, which is never used. 
> 
> (But the whole and only point of pci_choose_state() was to do the 
> PM_EVENT_FREEZE thing differently, which it doesn't do, so I think the 
> real issue here is that the interface is really rather mis-designed)

You're wrong, sorry.  With PM_EVENT_FREEZE it wouldn't even be necessary.
It's there, because potentially there are many possibilities with
PM_EVENT_SUSPEND and in fact it shouldn't even be used with
PM_EVENT_FREEZE.

All of this is more or less orthogonal to the issue at hand, which boils down
to the fact that we use the _suspend_ callbacks for hibernation and we
shouldn't be doing that.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Mark Lord]

Rafael J. Wysocki wrote:
>
> No.  Again, if there are devices that wake us up from S4, but not from S5,
> they need to be handled differently in the *enter S4* case (hibernation) and
> in the *enter S5* case (powering off the system).
..

Something I've never understood, is why we would ever want to bother with *S4* at all?

I actually like hibernation (great for travelling), but I treat it as if
it were a complete power-off (S5?).  I pull batteries, unplug drives,
boot other operating systems, etc..

And when I put it all back together again with the Linux disk inserted,
I fully expect it to "resume" from the hibernation of 3 months ago.
And it does.

Why would I ever want anything less than a full poweroff for hibernation ????

Thanks.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Nigel Cunningham]

Hi.

Jesse Barnes wrote:
> Well, it seems like we'll have to fix drivers in either case, and isn't a 
> kexec approach fundamentally more sound and simple, design-wise?  Rafael 
> pointed out some problems with properly setting wakeup states, but I think 
> that could be overcome...

No. AFAICS, kexec is going to be more complex and ugly in many ways.

To summarise, a kexec based hibernation is going to need the following 
additional requirements to just replace what we already have:

- get the original kernel to allocate storage while racing against the 
rest of the system (currently allocation is done post-atomic copy & 
post-freezing - no racing). This makes it potentially slower, too;
- get the original kernel to transfer the information about what swap 
was allocated to the kexec'd kernel, probably together with a lot of 
other information (which pages are nosave etc).
- get the original kernel to keep memory free for the kexec'd kernel 
which would otherwise be usable. Not a biggy on desktops or laptops, but 
think about embedded.
- people keep talking about hibernating to an ext3 fs mounted on fuse as 
a limitation of the freezer. To do that with kexec, you're still going 
to have to bmap the ext3 fs and pass the block list (in which case we 
can also do it without kexec) or umount all the ext3/fuse part and 
remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it?

I also wonder about how much of a pain it's going to be setting up 
userspace for this kexec'd kernel. Will you need a separate partition 
just for it? If not, will the userspace be loaded into memory all the 
time (more memory wasted for normal use), or loaded from ordinary 
partitions at kexec time (how to do safely? - more info to transfer 
between kernels?).

I'd love it if kexec really was the panacea to the freezer issues, but 
problems like these make me think it isn't a viable solution.

Nigel

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Matthew Garrett]

On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:

> - people keep talking about hibernating to an ext3 fs mounted on fuse as 
> a limitation of the freezer. To do that with kexec, you're still going 
> to have to bmap the ext3 fs and pass the block list (in which case we 
> can also do it without kexec) or umount all the ext3/fuse part and 
> remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it?

No, with a freezer-based model you can basically *never* suspend to 
anything related to FUSE or a userspace USB device or anything involving 
userspace iSCSI initiators or whatever. Sure, there are cases where 
moving away from the current model doesn't buy you anything, but that 
doesn't mean that the current model is a good thing. It's not. The 
freezer is a fundamentally broken concept.

> I also wonder about how much of a pain it's going to be setting up 
> userspace for this kexec'd kernel. Will you need a separate partition 
> just for it? If not, will the userspace be loaded into memory all the 
> time (more memory wasted for normal use), or loaded from ordinary 
> partitions at kexec time (how to do safely? - more info to transfer 
> between kernels?).

You're looking at a tiny amount of memory when compared to current 
systems. It's really not a problem.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Nigel Cunningham]

Hi.

Matthew Garrett wrote:
> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
> 
>> - people keep talking about hibernating to an ext3 fs mounted on fuse as 
>> a limitation of the freezer. To do that with kexec, you're still going 
>> to have to bmap the ext3 fs and pass the block list (in which case we 
>> can also do it without kexec) or umount all the ext3/fuse part and 
>> remount in the kexec'd kernel. Sort of defeats the purpose, doesn't it?
> 
> No, with a freezer-based model you can basically *never* suspend to 
> anything related to FUSE or a userspace USB device or anything involving 
> userspace iSCSI initiators or whatever. Sure, there are cases where 
> moving away from the current model doesn't buy you anything, but that 
> doesn't mean that the current model is a good thing. It's not. The 
> freezer is a fundamentally broken concept.

Putting drivers and filesystems in userspace is the fundamentally broken 
concept. Not just when it comes to the freezer. The whole idea is 
inherently racy. You can draw silly diagrams about how the freezer 
supposedly works in LCA slides and spread FUD as much as you like. In 
the end, though, it's not nearly as hit-and-miss as you say, and 
replacing the freezer with a kexec based freezer is only going to create 
as many problems as it removes.

>> I also wonder about how much of a pain it's going to be setting up 
>> userspace for this kexec'd kernel. Will you need a separate partition 
>> just for it? If not, will the userspace be loaded into memory all the 
>> time (more memory wasted for normal use), or loaded from ordinary 
>> partitions at kexec time (how to do safely? - more info to transfer 
>> between kernels?).
> 
> You're looking at a tiny amount of memory when compared to current 
> systems. It's really not a problem.

Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked 
on embedded solutions. I'm not pulling problems out of thin air.

Regards,

Nigel

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Greg KH]

On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
> Hi.
>
> Matthew Garrett wrote:
>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>> - people keep talking about hibernating to an ext3 fs mounted on fuse as 
>>> a limitation of the freezer. To do that with kexec, you're still going to 
>>> have to bmap the ext3 fs and pass the block list (in which case we can 
>>> also do it without kexec) or umount all the ext3/fuse part and remount in 
>>> the kexec'd kernel. Sort of defeats the purpose, doesn't it?
>> No, with a freezer-based model you can basically *never* suspend to 
>> anything related to FUSE or a userspace USB device or anything involving 
>> userspace iSCSI initiators or whatever. Sure, there are cases where moving 
>> away from the current model doesn't buy you anything, but that doesn't 
>> mean that the current model is a good thing. It's not. The freezer is a 
>> fundamentally broken concept.
>
> Putting drivers and filesystems in userspace is the fundamentally broken 
> concept. Not just when it comes to the freezer. The whole idea is 
> inherently racy.

Racy with regards to other things becides trying to suspend a machine?
If so, what?

thanks,

greg k-h

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Nigel Cunningham]

Hi.

Greg KH wrote:
> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>> Hi.
>>
>> Matthew Garrett wrote:
>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse as 
>>>> a limitation of the freezer. To do that with kexec, you're still going to 
>>>> have to bmap the ext3 fs and pass the block list (in which case we can 
>>>> also do it without kexec) or umount all the ext3/fuse part and remount in 
>>>> the kexec'd kernel. Sort of defeats the purpose, doesn't it?
>>> No, with a freezer-based model you can basically *never* suspend to 
>>> anything related to FUSE or a userspace USB device or anything involving 
>>> userspace iSCSI initiators or whatever. Sure, there are cases where moving 
>>> away from the current model doesn't buy you anything, but that doesn't 
>>> mean that the current model is a good thing. It's not. The freezer is a 
>>> fundamentally broken concept.
>> Putting drivers and filesystems in userspace is the fundamentally broken 
>> concept. Not just when it comes to the freezer. The whole idea is 
>> inherently racy.
> 
> Racy with regards to other things becides trying to suspend a machine?
> If so, what?

That depends on what sort of tangled web you want to weave. Low memory 
situations is one other situation that occurs to me quickly, especially 
(though not only) if your ability to swap were to depend upon a 
userspace driver and/or filesystem.

Regards,

Nigel

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Greg KH]

On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
> Hi.
>
> Greg KH wrote:
>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>>> Hi.
>>>
>>> Matthew Garrett wrote:
>>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse 
>>>>> as a limitation of the freezer. To do that with kexec, you're still 
>>>>> going to have to bmap the ext3 fs and pass the block list (in which 
>>>>> case we can also do it without kexec) or umount all the ext3/fuse part 
>>>>> and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't 
>>>>> it?
>>>> No, with a freezer-based model you can basically *never* suspend to 
>>>> anything related to FUSE or a userspace USB device or anything involving 
>>>> userspace iSCSI initiators or whatever. Sure, there are cases where 
>>>> moving away from the current model doesn't buy you anything, but that 
>>>> doesn't mean that the current model is a good thing. It's not. The 
>>>> freezer is a fundamentally broken concept.
>>> Putting drivers and filesystems in userspace is the fundamentally broken 
>>> concept. Not just when it comes to the freezer. The whole idea is 
>>> inherently racy.
>> Racy with regards to other things becides trying to suspend a machine?
>> If so, what?
>
> That depends on what sort of tangled web you want to weave.

Lots of them :)

We have tanks running Linux using userspace USB drivers for vision
control systems (scary, I know...)  They seem to be successfully running
for many years now, and I'm interested in making sure those kinds of
things keep working.

We also have laser welding robots with userspace PCI drivers in car
manufacturing plants.  And other laser cutting robots slicing wood in
patterns moving at a rate of over 3 meters a second.  Again, with
userspace drivers and Linux.

Those users would also love to know of any potential problems you know
of for this situation.

> Low memory situations is one other situation that occurs to me
> quickly, especially (though not only) if your ability to swap were to
> depend upon a userspace driver and/or filesystem.

Sure, swap over a userspace filesystem or driver isn't a sane idea.  And
neither is swaping over NFS over a PPP connection attached to a USB to
serial device.  Yes, it's possible, and all in the kernel, but not a
wise decision.

Other than foolish configurations, if you come up with other issues
surrounding userspace drivers that could cause problems, please let me
know.

thanks,

greg k-h

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Nigel Cunningham]

Hi Greg.

Greg KH wrote:
> On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
>> Hi.
>>
>> Greg KH wrote:
>>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>>>> Hi.
>>>>
>>>> Matthew Garrett wrote:
>>>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse 
>>>>>> as a limitation of the freezer. To do that with kexec, you're still 
>>>>>> going to have to bmap the ext3 fs and pass the block list (in which 
>>>>>> case we can also do it without kexec) or umount all the ext3/fuse part 
>>>>>> and remount in the kexec'd kernel. Sort of defeats the purpose, doesn't 
>>>>>> it?
>>>>> No, with a freezer-based model you can basically *never* suspend to 
>>>>> anything related to FUSE or a userspace USB device or anything involving 
>>>>> userspace iSCSI initiators or whatever. Sure, there are cases where 
>>>>> moving away from the current model doesn't buy you anything, but that 
>>>>> doesn't mean that the current model is a good thing. It's not. The 
>>>>> freezer is a fundamentally broken concept.
>>>> Putting drivers and filesystems in userspace is the fundamentally broken 
>>>> concept. Not just when it comes to the freezer. The whole idea is 
>>>> inherently racy.
>>> Racy with regards to other things becides trying to suspend a machine?
>>> If so, what?
>> That depends on what sort of tangled web you want to weave.
> 
> Lots of them :)
> 
> We have tanks running Linux using userspace USB drivers for vision
> control systems (scary, I know...)  They seem to be successfully running
> for many years now, and I'm interested in making sure those kinds of
> things keep working.
> 
> We also have laser welding robots with userspace PCI drivers in car
> manufacturing plants.  And other laser cutting robots slicing wood in
> patterns moving at a rate of over 3 meters a second.  Again, with
> userspace drivers and Linux.
> 
> Those users would also love to know of any potential problems you know
> of for this situation.
> 
>> Low memory situations is one other situation that occurs to me
>> quickly, especially (though not only) if your ability to swap were to
>> depend upon a userspace driver and/or filesystem.
> 
> Sure, swap over a userspace filesystem or driver isn't a sane idea.  And
> neither is swaping over NFS over a PPP connection attached to a USB to
> serial device.  Yes, it's possible, and all in the kernel, but not a
> wise decision.
> 
> Other than foolish configurations, if you come up with other issues
> surrounding userspace drivers that could cause problems, please let me
> know.

A simple OOM condition isn't an issue? Surely a driver stalling because 
some of its memory gets swapped out just before it goes to use it would 
be a problem if it resulted in getting the length of a cut wrong or 
caused some distorted vision or a late turn :>

Am I missing something? Maybe these drivers mlock memory to avoid those 
issues or something like that?

Regards,

Nigel

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Greg KH]

On Thu, Feb 21, 2008 at 05:05:32PM +1100, Nigel Cunningham wrote:
> Hi Greg.
>
> Greg KH wrote:
>> On Thu, Feb 21, 2008 at 12:17:06PM +1100, Nigel Cunningham wrote:
>>> Hi.
>>>
>>> Greg KH wrote:
>>>> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>>>>> Hi.
>>>>>
>>>>> Matthew Garrett wrote:
>>>>>> On Thu, Feb 21, 2008 at 09:45:02AM +1100, Nigel Cunningham wrote:
>>>>>>> - people keep talking about hibernating to an ext3 fs mounted on fuse 
>>>>>>> as a limitation of the freezer. To do that with kexec, you're still 
>>>>>>> going to have to bmap the ext3 fs and pass the block list (in which 
>>>>>>> case we can also do it without kexec) or umount all the ext3/fuse 
>>>>>>> part and remount in the kexec'd kernel. Sort of defeats the purpose, 
>>>>>>> doesn't it?
>>>>>> No, with a freezer-based model you can basically *never* suspend to 
>>>>>> anything related to FUSE or a userspace USB device or anything 
>>>>>> involving userspace iSCSI initiators or whatever. Sure, there are 
>>>>>> cases where moving away from the current model doesn't buy you 
>>>>>> anything, but that doesn't mean that the current model is a good 
>>>>>> thing. It's not. The freezer is a fundamentally broken concept.
>>>>> Putting drivers and filesystems in userspace is the fundamentally 
>>>>> broken concept. Not just when it comes to the freezer. The whole idea 
>>>>> is inherently racy.
>>>> Racy with regards to other things becides trying to suspend a machine?
>>>> If so, what?
>>> That depends on what sort of tangled web you want to weave.
>> Lots of them :)
>> We have tanks running Linux using userspace USB drivers for vision
>> control systems (scary, I know...)  They seem to be successfully running
>> for many years now, and I'm interested in making sure those kinds of
>> things keep working.
>> We also have laser welding robots with userspace PCI drivers in car
>> manufacturing plants.  And other laser cutting robots slicing wood in
>> patterns moving at a rate of over 3 meters a second.  Again, with
>> userspace drivers and Linux.
>> Those users would also love to know of any potential problems you know
>> of for this situation.
>>> Low memory situations is one other situation that occurs to me
>>> quickly, especially (though not only) if your ability to swap were to
>>> depend upon a userspace driver and/or filesystem.
>> Sure, swap over a userspace filesystem or driver isn't a sane idea.  And
>> neither is swaping over NFS over a PPP connection attached to a USB to
>> serial device.  Yes, it's possible, and all in the kernel, but not a
>> wise decision.
>> Other than foolish configurations, if you come up with other issues
>> surrounding userspace drivers that could cause problems, please let me
>> know.
>
> A simple OOM condition isn't an issue? Surely a driver stalling because 
> some of its memory gets swapped out just before it goes to use it would be 
> a problem if it resulted in getting the length of a cut wrong or caused 
> some distorted vision or a late turn :>
>
> Am I missing something? Maybe these drivers mlock memory to avoid those 
> issues or something like that?

I think the mlock their memory to prevent this from happening, it's not
hard when you control all the applications on the box :)

thanks,

greg k-h

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Matthew Garrett]

On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
> Matthew Garrett wrote:
> >No, with a freezer-based model you can basically *never* suspend to 
> >anything related to FUSE or a userspace USB device or anything involving 
> >userspace iSCSI initiators or whatever. Sure, there are cases where 
> >moving away from the current model doesn't buy you anything, but that 
> >doesn't mean that the current model is a good thing. It's not. The 
> >freezer is a fundamentally broken concept.
> 
> Putting drivers and filesystems in userspace is the fundamentally broken 
> concept. Not just when it comes to the freezer. The whole idea is 
> inherently racy. You can draw silly diagrams about how the freezer 
> supposedly works in LCA slides and spread FUD as much as you like. In 
> the end, though, it's not nearly as hit-and-miss as you say, and 
> replacing the freezer with a kexec based freezer is only going to create 
> as many problems as it removes.

I'm really not interested in debating the matter. There are all sorts of 
potential uses for the freezer, but hibernation isn't one of them. We 
*need* to get rid of the freezer for suspend to RAM (because a band-aid 
to ensure atomicity is kind of pointless when the operation you're 
entering is inherently atomic), and once all the drivers are able to 
deal with that then it's trivial to get rid of it for hibernation as 
well. Arguing that the reality of userspace drivers is broken doesn't 
help here. It's what we have to work with.

> >You're looking at a tiny amount of memory when compared to current 
> >systems. It's really not a problem.
> 
> Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked 
> on embedded solutions. I'm not pulling problems out of thin air.

Then the in-kernel solution has already lost anyway, and I'm desperately 
unconcerned about out of tree stuff.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Nigel Cunningham]

Hi.

Matthew Garrett wrote:
> On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
>> Matthew Garrett wrote:
>>> No, with a freezer-based model you can basically *never* suspend to 
>>> anything related to FUSE or a userspace USB device or anything involving 
>>> userspace iSCSI initiators or whatever. Sure, there are cases where 
>>> moving away from the current model doesn't buy you anything, but that 
>>> doesn't mean that the current model is a good thing. It's not. The 
>>> freezer is a fundamentally broken concept.
>> Putting drivers and filesystems in userspace is the fundamentally broken 
>> concept. Not just when it comes to the freezer. The whole idea is 
>> inherently racy. You can draw silly diagrams about how the freezer 
>> supposedly works in LCA slides and spread FUD as much as you like. In 
>> the end, though, it's not nearly as hit-and-miss as you say, and 
>> replacing the freezer with a kexec based freezer is only going to create 
>> as many problems as it removes.
> 
> I'm really not interested in debating the matter. There are all sorts of 
> potential uses for the freezer, but hibernation isn't one of them. We 
> *need* to get rid of the freezer for suspend to RAM (because a band-aid 
> to ensure atomicity is kind of pointless when the operation you're 
> entering is inherently atomic), and once all the drivers are able to 
> deal with that then it's trivial to get rid of it for hibernation as 
> well. Arguing that the reality of userspace drivers is broken doesn't 
> help here. It's what we have to work with.

Re suspend to ram, I agree. No argument there. Re hibernation, I think 
your assertion that it will be trivial to get rid of it for hibernation 
is just plain wrong. Perhaps you don't understand the issues as well as 
you think you do.

Re arguing that the reality of userspace drivers is broken doesn't help 
here: Yeah, I know. But sometimes if you point out broken ideas for long 
enough, people do actually listen. Or you learn. Or both.

Frankly, I don't want to debate the issue either. What I really want is 
just to have a hibernation implementation that works, is flexibile, 
reliable and quick, and one that I don't have to keep maintaining. 
Unfortunately for me, most people seem to be more concerned with fixing 
hypothetical problems than with giving users something they can actually 
use.

>>> You're looking at a tiny amount of memory when compared to current 
>>> systems. It's really not a problem.
>> Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked 
>> on embedded solutions. I'm not pulling problems out of thin air.
> 
> Then the in-kernel solution has already lost anyway, and I'm desperately 
> unconcerned about out of tree stuff.

I know. I'd submit it, or work on breaking it into pieces and submitting 
them one at a time, but that seems to me to be a waste of time.

Nigel

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

[Rafael J. Wysocki]

On Wednesday, 20 of February 2008, Linus Torvalds wrote:
> 
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> > 
> > I think we should export the target sleep state somehow.
> 
> Yeah. By *not* using "->suspend()" for freezing or hibernate.
> 
> Please, Rafael - just make the f*cking suspend-to-disk use other routines 
> already.

Okay, I think I'll just start sending patches for that, but rather not earlier
than in the 2.6.27 time frame.  No one else works on that and I've been busy
with other things recently.  Besides, I'm not even a full time kernel
developer ...

> 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the
> ones that really do need things tend to need to not do a whole lot.
> 
> For example, the "freeze" action for USB (which is one of the hardest 
> things to suspend) should literally be something like just setting the 
> controller STOP bit, and waiting for it to have stopped. The "unfreeze" 
> should be to just clear the stop bit, while the "restart" should be just a 
> controller reset to use the current memory image.
> 
> NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND.
> 
> It never did. I've told people so for years. Maybe actually seeing the 
> problems will make people realize.

I think so.

> So please, we shouldn't call "->suspend[_late]" or "->resume[_early]" at 
> all. Not with PMSG_FREEZE, not with PMSG_*anything*.
> 
> Can we please get this fixed some day? 

Yes, we can (hopefully).

Thanks,
Rafael

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

[Alexey Starikovskiy]

Rafael J. Wysocki wrote:
> On Wednesday, 20 of February 2008, Linus Torvalds wrote:
>   
>> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
>>     
>>> I think we should export the target sleep state somehow.
>>>       
>> Yeah. By *not* using "->suspend()" for freezing or hibernate.
>>
>> Please, Rafael - just make the f*cking suspend-to-disk use other routines 
>> already.
>>     
>
> Okay, I think I'll just start sending patches for that, but rather not earlier
> than in the 2.6.27 time frame.  No one else works on that and I've been busy
> with other things recently.  Besides, I'm not even a full time kernel
> developer ...
>
>   
Rafael,
If I can help, please  say so.

Regards,
Alex.
>> 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the
>> ones that really do need things tend to need to not do a whole lot.
>>
>> For example, the "freeze" action for USB (which is one of the hardest 
>> things to suspend) should literally be something like just setting the 
>> controller STOP bit, and waiting for it to have stopped. The "unfreeze" 
>> should be to just clear the stop bit, while the "restart" should be just a 
>> controller reset to use the current memory image.
>>
>> NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND.
>>
>> It never did. I've told people so for years. Maybe actually seeing the 
>> problems will make people realize.
>>     
>
> I think so.
>
>   
>> So please, we shouldn't call "->suspend[_late]" or "->resume[_early]" at 
>> all. Not with PMSG_FREEZE, not with PMSG_*anything*.
>>
>> Can we please get this fixed some day? 
>>     
>
> Yes, we can (hopefully).
>
> Thanks,
> Rafael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > So, next I'll try "shutdown" to see if it work. I was using "platform".
> >
> > Ok, that would be good to try.
>
> "shutdown" does power down properly. But still green on resume.
>
> > Looks like the AR registers are hosed, which is what I thought I fixed...
> >  Can you attach your i915_drv.c file just so I can sanity check it?
>
> Attached.

Ok, can you give this patch a try with the 'platform' method?  It should at 
least tell us what ACPI would like the device to do at suspend time, but it 
probably won't fix the hang.

Thanks,
Jesse

diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 4048f39..d8aa2c9 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -366,11 +366,11 @@ static int i915_suspend(struct drm_device *dev, 
pm_message_t state)
 
 	i915_save_vga(dev);
 
-	if (state.event == PM_EVENT_SUSPEND) {
-		/* Shut down the device */
-		pci_disable_device(dev->pdev);
-		pci_set_power_state(dev->pdev, PCI_D3hot);
-	}
+	/* Ask ACPI which state the device should be put in */
+	pci_disable_device(dev->pdev);
+	printk("calling pci_set_power_state with %d\n",
+	       acpi_pci_choose_state(dev, state));
+	pci_set_power_state(dev->pdev, acpi_pci_choose_state(dev, state));
 
 	return 0;
 }
@@ -380,7 +380,7 @@ static int i915_resume(struct drm_device *dev)
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	int i;
 
-	pci_set_power_state(dev->pdev, PCI_D0);
+	pci_set_power_state(dev->pdev, acpi_pci_choose_state(dev, state));
 	pci_restore_state(dev->pdev);
 	if (pci_enable_device(dev->pdev))
 		return -1;

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:

>  Ok, can you give this patch a try with the 'platform' method?  It should at
>  least tell us what ACPI would like the device to do at suspend time, but it
>  probably won't fix the hang.

I can't get it to compile.

drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: error: implicit declaration of
function 'acpi_pci_choose_state'
drivers/char/drm/i915_drv.c: In function 'i915_resume':
drivers/char/drm/i915_drv.c:383: error: 'state' undeclared (first use
in this function)
drivers/char/drm/i915_drv.c:383: error: (Each undeclared identifier is
reported only once
drivers/char/drm/i915_drv.c:383: error: for each function it appears in.)
make[3]: *** [drivers/char/drm/i915_drv.o] Error 1
make[2]: *** [drivers/char/drm] Error 2
make[1]: *** [drivers/char] Error 2
make: *** [drivers] Error 2

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <jesse.barnes@intel.com> 
wrote:
> >  Ok, can you give this patch a try with the 'platform' method?  It should
> > at least tell us what ACPI would like the device to do at suspend time,
> > but it probably won't fix the hang.
>
> I can't get it to compile.
>
> drivers/char/drm/i915_drv.c: In function 'i915_suspend':
> drivers/char/drm/i915_drv.c:372: error: implicit declaration of
> function 'acpi_pci_choose_state'

Oops, maybe this should just be pci_choose_state instead.

> drivers/char/drm/i915_drv.c: In function 'i915_resume':
> drivers/char/drm/i915_drv.c:383: error: 'state' undeclared (first use
> in this function)
> drivers/char/drm/i915_drv.c:383: error: (Each undeclared identifier is
> reported only once
> drivers/char/drm/i915_drv.c:383: error: for each function it appears in.)

And this change should just be reverted (leave it as PCI_D0).

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
>  Oops, maybe this should just be pci_choose_state instead.
>  And this change should just be reverted (leave it as PCI_D0).

drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: warning: passing argument 1 of
'pci_choose_state' from incompatible pointer type
drivers/char/drm/i915_drv.c:373: warning: passing argument 1 of
'pci_choose_state' from incompatible pointer type

I hope those are just warning that can just be ignored.

Ok, rebooting and will get back shortly.

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 5:19 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> 
wrote:
> >  Oops, maybe this should just be pci_choose_state instead.
> >  And this change should just be reverted (leave it as PCI_D0).
>
> drivers/char/drm/i915_drv.c: In function 'i915_suspend':
> drivers/char/drm/i915_drv.c:372: warning: passing argument 1 of
> 'pci_choose_state' from incompatible pointer type
> drivers/char/drm/i915_drv.c:373: warning: passing argument 1 of
> 'pci_choose_state' from incompatible pointer type
>
> I hope those are just warning that can just be ignored.

Oops again, should be dev->pdev.  Silly DRM layer obfuscation.

Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:

>  > I hope those are just warning that can just be ignored.
>
>  Oops again, should be dev->pdev.  Silly DRM layer obfuscation.

I was just about to write that the test didn't work. Both std str
hangs even before attempting to suspend.

Anyway, I'm compiling and rebooting now.

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jeff Chua]

On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
>  > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <jesse.barnes@intel.com>
>  wrote:
>  > >  Ok, can you give this patch a try with the 'platform' method?  It should
>  > > at least tell us what ACPI would like the device to do at suspend time,
>  > > but it probably won't fix the hang.

It says "calling pci_set_power_state with 3". Then after all then it
still hangs, and then resume with Mr Green.

PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
PM: Shrinking memory...  ^H-^Hdone (0 pages freed)
PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
ACPI: Preparing to enter system sleep state S4
Suspending console(s)
sd 0:0:0:0: [sda] Synchronizing SCSI cache
drm_sysfs_suspend
ACPI: PCI interrupt for device 0000:00:02.0 disabled
calling pci_set_power_state with 3
ACPI: PCI interrupt for device 0000:00:1d.7 disabled
ACPI: PCI interrupt for device 0000:00:1d.3 disabled
ACPI: PCI interrupt for device 0000:00:1d.2 disabled
ACPI: PCI interrupt for device 0000:00:1d.1 disabled
ACPI: PCI interrupt for device 0000:00:1d.0 disabled
ACPI: PCI interrupt for device 0000:00:1b.0 disabled
Disabling non-boot CPUs ...
PM: Creating hibernation image:
PM: Need to copy 25136 pages
tick-braodcast: ignoring broadcast for offline CPU #1
PM: Writing back config space on device 0000:00:02.0 at offset 1 (was
900007, writing 900003)
ACPI: PCI Interrupt 0000:00:1b.0[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1b.0 to 64
PCI: Setting latency timer of device 0000:00:1c.0 to 64
PCI: Setting latency timer of device 0000:00:1c.1 to 64
...


Thanks,
Jeff.

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

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> >  > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <jesse.barnes@intel.com>
> >  wrote:
> >  > >  Ok, can you give this patch a try with the 'platform' method?  It should
> >  > > at least tell us what ACPI would like the device to do at suspend time,
> >  > > but it probably won't fix the hang.
> 
> It says "calling pci_set_power_state with 3". Then after all then it
> still hangs, and then resume with Mr Green.
> 
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.00 seconds) done.
> Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> PM: Shrinking memory...  ^H-^Hdone (0 pages freed)
> PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
> ACPI: Preparing to enter system sleep state S4
> Suspending console(s)
> sd 0:0:0:0: [sda] Synchronizing SCSI cache
> drm_sysfs_suspend
> ACPI: PCI interrupt for device 0000:00:02.0 disabled
> calling pci_set_power_state with 3

So it returns the right value.

Jeff, Jesse, please check one thing for me.

Please boot 2.6.25-rc2 (or better, the current head of the Linus' tree) with
no_console_suspend and try to do the following:

# echo 8 > /proc/sys/kernel/printk
# echo core > /sys/power/pm_test
# echo disk > /sys/power/state

(that will run a test of the freeze/unfreeze code without creating the image)
and then

# echo mem > /sys/power/state

(that will run a test of the suspend/resume code without actually suspending).

I'd like to know if that works.

Thanks,
Rafael

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

[Jesse Barnes]

On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> On Thursday, 21 of February 2008, Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> 
wrote:
> > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > >  > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes
> > >  > <jesse.barnes@intel.com>
> > >
> > >  wrote:
> > >  > >  Ok, can you give this patch a try with the 'platform' method?  It
> > >  > > should at least tell us what ACPI would like the device to do at
> > >  > > suspend time, but it probably won't fix the hang.
> >
> > It says "calling pci_set_power_state with 3". Then after all then it
> > still hangs, and then resume with Mr Green.
> >
> > PM: Syncing filesystems ... done.
> > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > PM: Shrinking memory...  ^H-^Hdone (0 pages freed)
> > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
> > ACPI: Preparing to enter system sleep state S4
> > Suspending console(s)
> > sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > drm_sysfs_suspend
> > ACPI: PCI interrupt for device 0000:00:02.0 disabled
> > calling pci_set_power_state with 3
>
> So it returns the right value.
>
> Jeff, Jesse, please check one thing for me.
>
> Please boot 2.6.25-rc2 (or better, the current head of the Linus' tree)
> with no_console_suspend and try to do the following:
>
> # echo 8 > /proc/sys/kernel/printk
> # echo core > /sys/power/pm_test
> # echo disk > /sys/power/state
>
> (that will run a test of the freeze/unfreeze code without creating the
> image) and then

That comes back for me, without creating the green screen.  There's a long 
delay between it saying "entering S4" and actually resuming back to my 
console though.

> # echo mem > /sys/power/state
>
> (that will run a test of the suspend/resume code without actually
> suspending).
>
> I'd like to know if that works.

This also works (after doing the echo disk > ...) above.  There's still a 
delay between "entering S3" and the resume to my console though.

Jesse

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

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> > On Thursday, 21 of February 2008, Jeff Chua wrote:
> > > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> 
> wrote:
> > > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > > >  > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes
> > > >  > <jesse.barnes@intel.com>
> > > >
> > > >  wrote:
> > > >  > >  Ok, can you give this patch a try with the 'platform' method?  It
> > > >  > > should at least tell us what ACPI would like the device to do at
> > > >  > > suspend time, but it probably won't fix the hang.
> > >
> > > It says "calling pci_set_power_state with 3". Then after all then it
> > > still hangs, and then resume with Mr Green.
> > >
> > > PM: Syncing filesystems ... done.
> > > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > > PM: Shrinking memory...  ^H-^Hdone (0 pages freed)
> > > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
> > > ACPI: Preparing to enter system sleep state S4
> > > Suspending console(s)
> > > sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > > drm_sysfs_suspend
> > > ACPI: PCI interrupt for device 0000:00:02.0 disabled
> > > calling pci_set_power_state with 3
> >
> > So it returns the right value.
> >
> > Jeff, Jesse, please check one thing for me.
> >
> > Please boot 2.6.25-rc2 (or better, the current head of the Linus' tree)
> > with no_console_suspend and try to do the following:
> >
> > # echo 8 > /proc/sys/kernel/printk
> > # echo core > /sys/power/pm_test
> > # echo disk > /sys/power/state
> >
> > (that will run a test of the freeze/unfreeze code without creating the
> > image) and then
> 
> That comes back for me, without creating the green screen.  There's a long 
> delay between it saying "entering S4" and actually resuming back to my 
> console though.

There's an intentional 5 sec. wait.  If the delay is longer that 5 sec., that's a
bit strange.
 
> > # echo mem > /sys/power/state
> >
> > (that will run a test of the suspend/resume code without actually
> > suspending).
> >
> > I'd like to know if that works.
> 
> This also works (after doing the echo disk > ...) above.

That's what I wanted to know, thanks.

> There's still a delay between "entering S3" and the resume to my console
> though. 

If that's 5 sec., it's fine.

Please apply the appended patch and try to hibernate.  I wonder if you get the
reboot or it hangs earlier.

Thanks,
Rafael

---
 kernel/power/disk.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -405,11 +405,7 @@ int hibernation_platform_enter(void)
 
 	local_irq_disable();
 	error = device_power_down(PMSG_SUSPEND);
-	if (!error) {
-		hibernation_ops->enter();
-		/* We should never get here */
-		while (1);
-	}
+	mdelay(1000);
 	local_irq_enable();
 
 	/*
@@ -424,6 +420,7 @@ int hibernation_platform_enter(void)
 	resume_console();
  Close:
 	hibernation_ops->end();
+	kernel_restart(NULL);
 	return error;
 }
 

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

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> > On Thursday, 21 of February 2008, Jeff Chua wrote:
> > > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <jesse.barnes@intel.com> 
> wrote:
> > > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > > >  > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes
> > > >  > <jesse.barnes@intel.com>
> > > >
> > > >  wrote:
> > > >  > >  Ok, can you give this patch a try with the 'platform' method?  It
> > > >  > > should at least tell us what ACPI would like the device to do at
> > > >  > > suspend time, but it probably won't fix the hang.
> > >
> > > It says "calling pci_set_power_state with 3". Then after all then it
> > > still hangs, and then resume with Mr Green.
> > >
> > > PM: Syncing filesystems ... done.
> > > Freezing user space processes ... (elapsed 0.00 seconds) done.
> > > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
> > > PM: Shrinking memory...  ^H-^Hdone (0 pages freed)
> > > PM: Freed 0 kbytes in 0.20 seconds (0.00 MB/s)
> > > ACPI: Preparing to enter system sleep state S4
> > > Suspending console(s)
> > > sd 0:0:0:0: [sda] Synchronizing SCSI cache
> > > drm_sysfs_suspend
> > > ACPI: PCI interrupt for device 0000:00:02.0 disabled
> > > calling pci_set_power_state with 3
> >
> > So it returns the right value.
> >
> > Jeff, Jesse, please check one thing for me.

Below is a patch that should work around the issue.  Please try it and let me
know if it helps.

Thanks,
Rafael

---
 drivers/char/drm/i915_drv.c |    3 +++
 include/linux/suspend.h     |    2 ++
 kernel/power/disk.c         |    9 ++++++++-
 3 files changed, 13 insertions(+), 1 deletion(-)

Index: linux-2.6/include/linux/suspend.h
===================================================================
--- linux-2.6.orig/include/linux/suspend.h
+++ linux-2.6/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t
 
 extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
 extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
 #else /* CONFIG_HIBERNATION */
 static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
 static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_fre
 
 static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) {}
 static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
 #endif /* CONFIG_HIBERNATION */
 
 #ifdef CONFIG_PM_SLEEP
Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -24,7 +24,7 @@
 
 #include "power.h"
 
-
+static bool entering_sleep_state;
 static int noresume = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
 	if (!hibernation_ops)
 		return -ENOSYS;
 
+	entering_sleep_state = true;
 	/*
 	 * We have cancelled the power transition by running
 	 * hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
 	}
 	local_irq_enable();
 
+	entering_sleep_state = false;
 	/*
 	 * We don't need to reenable the nonboot CPUs or resume consoles, since
 	 * the system is going to be halted anyway.
@@ -427,6 +429,11 @@ int hibernation_platform_enter(void)
 	return error;
 }
 
+bool in_hibernation_power_off(void)
+{
+	return entering_sleep_state;
+}
+
 /**
  *	power_down - Shut the machine down for hibernation.
  *
Index: linux-2.6/drivers/char/drm/i915_drv.c
===================================================================
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -247,6 +247,9 @@ static int i915_suspend(struct drm_devic
 		return -ENODEV;
 	}
 
+	if (in_hibernation_power_off())
+		return 0;
+
 	pci_save_state(dev->pdev);
 	pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
 

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

[Jesse Barnes]

On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> Below is a patch that should work around the issue.  Please try it and let
> me know if it helps.

I ended up applying the below patch instead, so it would build, and 
unfortunately it still hung at suspend time.

So at this point, the known workarounds to the hang at suspend time are to 
remove the device power down call or to boot with 'no_console_suspend'.  
The 'screen turns green' problem is fixed by the extra 'inb' added in the 
patch below (at least for me).

Jesse

diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 35758a6..35b5a60 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
  *
  */
 
+#include <linux/suspend.h>
 #include "drmP.h"
 #include "drm.h"
 #include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_device *dev)
 			   dev_priv->saveGR[0x18]);
 
 	/* Attribute controller registers */
+	inb(st01); /* switch back to index mode */
 	for (i = 0; i < 20; i++)
 		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
 	inb(st01); /* switch back to index mode */
@@ -249,6 +251,9 @@ static int i915_suspend(struct drm_device *dev)
 		return -ENODEV;
 	}
 
+	if (in_hibernation_power_off())
+		return 0;
+
 	pci_save_state(dev->pdev);
 	pci_read_config_byte(dev->pdev, LBB, &dev_priv->saveLBB);
 
@@ -364,7 +369,6 @@ static int i915_suspend(struct drm_device *dev)
 	i915_save_vga(dev);
 
 	/* Shut down the device */
-	pci_disable_device(dev->pdev);
 	pci_set_power_state(dev->pdev, PCI_D3hot);
 
 	return 0;
diff --git a/include/linux/suspend.h b/include/linux/suspend.h
index 1d7d4c5..58d9f67 100644
--- a/include/linux/suspend.h
+++ b/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t gfp_mask);
 
 extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
 extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
 #else /* CONFIG_HIBERNATION */
 static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
 static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_free(struct page *p) 
{}
 
 static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) 
{}
 static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
 #endif /* CONFIG_HIBERNATION */
 
 #ifdef CONFIG_PM_SLEEP
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
index 859a8e5..d842bf0 100644
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -24,7 +24,7 @@
 
 #include "power.h"
 
-
+static bool entering_sleep_state;
 static int noresume = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
 	if (!hibernation_ops)
 		return -ENOSYS;
 
+	entering_sleep_state = true;
 	/*
 	 * We have cancelled the power transition by running
 	 * hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
 	}
 	local_irq_enable();
 
+	entering_sleep_state = false;
 	/*
 	 * We don't need to reenable the nonboot CPUs or resume consoles, since
 	 * the system is going to be halted anyway.
@@ -427,6 +429,12 @@ int hibernation_platform_enter(void)
 	return error;
 }
 
+bool in_hibernation_power_off(void)
+{
+	return entering_sleep_state;
+}
+EXPORT_SYMBOL(in_hibernation_power_off);
+
 /**
  *	power_down - Shut the machine down for hibernation.
  *

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

[Rafael J. Wysocki]

On Friday, 22 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> > Below is a patch that should work around the issue.  Please try it and let
> > me know if it helps.
> 
> I ended up applying the below patch instead, so it would build, and 
> unfortunately it still hung at suspend time.

Hmm.

> So at this point, the known workarounds to the hang at suspend time are to 
> remove the device power down call or to boot with 'no_console_suspend'.  
> The 'screen turns green' problem is fixed by the extra 'inb' added in the 
> patch below (at least for me).

That is suspicious (see below).

> 
> diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
> index 35758a6..35b5a60 100644
> --- a/drivers/char/drm/i915_drv.c
> +++ b/drivers/char/drm/i915_drv.c
> @@ -27,6 +27,7 @@
>   *
>   */
>  
> +#include <linux/suspend.h>
>  #include "drmP.h"
>  #include "drm.h"
>  #include "i915_drm.h"
> @@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_device *dev)
>  			   dev_priv->saveGR[0x18]);
>  
>  	/* Attribute controller registers */
> +	inb(st01); /* switch back to index mode */
>  	for (i = 0; i < 20; i++)
>  		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
>  	inb(st01); /* switch back to index mode */
> @@ -249,6 +251,9 @@ static int i915_suspend(struct drm_device *dev)
>  		return -ENODEV;
>  	}
>  
> +	if (in_hibernation_power_off())
> +		return 0;
> +

This thing should make i915_suspend() a noop in the last phase of hibernation,
so if it still only works when you remove the
pci_set_power_state(dev->pdev, PCI_D3hot), then I don't get it.

Can you please try the pach below instead?

Thanks,
Rafael


On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> Below is a patch that should work around the issue.  Please try it and let
> me know if it helps.

I ended up applying the below patch instead, so it would build, and 
unfortunately it still hung at suspend time.

So at this point, the known workarounds to the hang at suspend time are to 
remove the device power down call or to boot with 'no_console_suspend'.  
The 'screen turns green' problem is fixed by the extra 'inb' added in the 
patch below (at least for me).

Jesse

---
 drivers/char/drm/i915_drv.c |    5 +++--
 include/linux/suspend.h     |    2 ++
 kernel/power/disk.c         |   10 +++++++++-
 3 files changed, 14 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/char/drm/i915_drv.c
===================================================================
--- linux-2.6.orig/drivers/char/drm/i915_drv.c
+++ linux-2.6/drivers/char/drm/i915_drv.c
@@ -27,6 +27,7 @@
  *
  */
 
+#include <linux/suspend.h>
 #include "drmP.h"
 #include "drm.h"
 #include "i915_drm.h"
@@ -222,6 +223,7 @@ static void i915_restore_vga(struct drm_
 			   dev_priv->saveGR[0x18]);
 
 	/* Attribute controller registers */
+	inb(st01); /* switch back to index mode */
 	for (i = 0; i < 20; i++)
 		i915_write_ar(st01, i, dev_priv->saveAR[i], 0);
 	inb(st01); /* switch back to index mode */
@@ -366,9 +368,8 @@ static int i915_suspend(struct drm_devic
 
 	i915_save_vga(dev);
 
-	if (state.event == PM_EVENT_SUSPEND) {
+	if (state.event == PM_EVENT_SUSPEND && !in_hibernation_power_off()) {
 		/* Shut down the device */
-		pci_disable_device(dev->pdev);
 		pci_set_power_state(dev->pdev, PCI_D3hot);
 	}
 
Index: linux-2.6/include/linux/suspend.h
===================================================================
--- linux-2.6.orig/include/linux/suspend.h
+++ linux-2.6/include/linux/suspend.h
@@ -209,6 +209,7 @@ extern unsigned long get_safe_page(gfp_t
 
 extern void hibernation_set_ops(struct platform_hibernation_ops *ops);
 extern int hibernate(void);
+extern bool in_hibernation_power_off(void);
 #else /* CONFIG_HIBERNATION */
 static inline int swsusp_page_is_forbidden(struct page *p) { return 0; }
 static inline void swsusp_set_page_free(struct page *p) {}
@@ -216,6 +217,7 @@ static inline void swsusp_unset_page_fre
 
 static inline void hibernation_set_ops(struct platform_hibernation_ops *ops) {}
 static inline int hibernate(void) { return -ENOSYS; }
+static inline bool in_hibernation_power_off(void) { return false; }
 #endif /* CONFIG_HIBERNATION */
 
 #ifdef CONFIG_PM_SLEEP
Index: linux-2.6/kernel/power/disk.c
===================================================================
--- linux-2.6.orig/kernel/power/disk.c
+++ linux-2.6/kernel/power/disk.c
@@ -24,7 +24,7 @@
 
 #include "power.h"
 
-
+static bool entering_sleep_state;
 static int noresume = 0;
 static char resume_file[256] = CONFIG_PM_STD_PARTITION;
 dev_t swsusp_resume_device;
@@ -381,6 +381,7 @@ int hibernation_platform_enter(void)
 	if (!hibernation_ops)
 		return -ENOSYS;
 
+	entering_sleep_state = true;
 	/*
 	 * We have cancelled the power transition by running
 	 * hibernation_ops->finish() before saving the image, so we should let
@@ -412,6 +413,7 @@ int hibernation_platform_enter(void)
 	}
 	local_irq_enable();
 
+	entering_sleep_state = false;
 	/*
 	 * We don't need to reenable the nonboot CPUs or resume consoles, since
 	 * the system is going to be halted anyway.
@@ -427,6 +429,12 @@ int hibernation_platform_enter(void)
 	return error;
 }
 
+bool in_hibernation_power_off(void)
+{
+	return entering_sleep_state;
+}
+EXPORT_SYMBOL(in_hibernation_power_off);
+
 /**
  *	power_down - Shut the machine down for hibernation.
  *

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

[Jeff Chua]

On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
>  > Below is a patch that should work around the issue.  Please try it and let
>  > me know if it helps.
>
>  I ended up applying the below patch instead, so it would build, and
>  unfortunately it still hung at suspend time.

I encountered the same patching problem, but realized that it was due
to earlier patch that you had wanted me to test, so if you revert your
patch back to the current git, Rafael's patch will apply and compile
cleanly.

Thanks,
Jeff.

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > So, next I'll try "shutdown" to see if it work. I was using "platform".
> >
> > Ok, that would be good to try.
>
> "shutdown" does power down properly. But still green on resume.
>
> > Looks like the AR registers are hosed, which is what I thought I fixed...
> >  Can you attach your i915_drv.c file just so I can sanity check it?
>
> Attached.

Jeff, for the hang on suspend problem, I know suspect something else in 
2.6.25-rc2 caused that.

Can you try the 2.6.25-rc1 version of i915_drv.c (in fact all of 
drivers/char/drm from 2.6.25-rc1) but in a 2.6.25-rc2 kernel?  I ask because 
2.6.25-rc1 suspends to disk just fine for me and resumes w/o a green screen, 
while 2.6.25-rc2 fails to suspend (hangs like you say) and gives me a green 
screen.

Were there other changes in ACPI or the PM core that might have caused this I 
wonder?

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
> On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > "platform".
> > >
> > > Ok, that would be good to try.
> >
> > "shutdown" does power down properly. But still green on resume.
> >
> > > Looks like the AR registers are hosed, which is what I thought I
> > > fixed... Can you attach your i915_drv.c file just so I can sanity check
> > > it?
> >
> > Attached.
>
> Jeff, for the hang on suspend problem, I know suspect something else in
> 2.6.25-rc2 caused that.

Looks like 2.6.25-rc1 also had broken suspend (my test was broken).  IIRC, 
Dave and I had it working at LCA using the out of tree DRM modules on 
2.6.23.14 or 15...  Maybe you could give that a try?

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 3:03 pm Jesse Barnes wrote:
> On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
> > On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > > On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > > "platform".
> > > >
> > > > Ok, that would be good to try.
> > >
> > > "shutdown" does power down properly. But still green on resume.
> > >
> > > > Looks like the AR registers are hosed, which is what I thought I
> > > > fixed... Can you attach your i915_drv.c file just so I can sanity
> > > > check it?
> > >
> > > Attached.
> >
> > Jeff, for the hang on suspend problem, I know suspect something else in
> > 2.6.25-rc2 caused that.
>
> Looks like 2.6.25-rc1 also had broken suspend (my test was broken).  IIRC,
> Dave and I had it working at LCA using the out of tree DRM modules on
> 2.6.23.14 or 15...  Maybe you could give that a try?

And just to confirm that, I just tested the current DRM modules against a 
2.6.23.15 kernel.  It suspends to disk correctly (w/o a hang) and doesn't 
give me a green screen, so something in 2.6.25 must be causing that (even 
2.6.25-rc1 seems to have the problem).

Also, this patch against 2.6.25-rc1 seemed to prevent the 'green screen' 
problem.  2.6.25-rc2 already has part of it...

Anyway, let me know how your testing goes.

Thanks,
Jesse

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 3:03 pm Jesse Barnes wrote:
> > On Wednesday, February 20, 2008 2:32 pm Jesse Barnes wrote:
> > > On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> > > > On Feb 21, 2008 2:53 AM, Jesse Barnes <jesse.barnes@intel.com> wrote:
> > > > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > > > "platform".
> > > > >
> > > > > Ok, that would be good to try.
> > > >
> > > > "shutdown" does power down properly. But still green on resume.
> > > >
> > > > > Looks like the AR registers are hosed, which is what I thought I
> > > > > fixed... Can you attach your i915_drv.c file just so I can sanity
> > > > > check it?
> > > >
> > > > Attached.
> > >
> > > Jeff, for the hang on suspend problem, I know suspect something else in
> > > 2.6.25-rc2 caused that.
> >
> > Looks like 2.6.25-rc1 also had broken suspend (my test was broken).  IIRC,
> > Dave and I had it working at LCA using the out of tree DRM modules on
> > 2.6.23.14 or 15...  Maybe you could give that a try?
> 
> And just to confirm that, I just tested the current DRM modules against a 
> 2.6.23.15 kernel.

In 2.6.23.x there's no second ->suspend() during hibernation, so no wonder.

I'll figure out how to work around this issue in the current mainline, but a
real fix will only be possible when we have separate callbacks for
hibernation.

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Jesse Barnes]

On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
> > And just to confirm that, I just tested the current DRM modules against a
> > 2.6.23.15 kernel.
>
> In 2.6.23.x there's no second ->suspend() during hibernation, so no wonder.

In 2.6.23 it's just:
  ->suspend()
  ->resume()
  *S4*
?

I ask because we still do the D3hot call in the DRM tree, so the hang should 
still occur unless the PM or ACPI core has changed.

> I'll figure out how to work around this issue in the current mainline, but
> a real fix will only be possible when we have separate callbacks for
> hibernation.

Ok, thanks.

Jesse

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

[Rafael J. Wysocki]

On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
> > > And just to confirm that, I just tested the current DRM modules against a
> > > 2.6.23.15 kernel.
> >
> > In 2.6.23.x there's no second ->suspend() during hibernation, so no wonder.
> 
> In 2.6.23 it's just:
>   ->suspend()
>   ->resume()

->shutdown()

(that breaks wake up from S4 with many devices, including but not limited to
the RTC wake alarm).

>   *S4*
> ?
> 

Thanks,
Rafael

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

[Mark Lord]

Jeff Chua wrote:
> 
> 
> On Feb 20, 2008 2:19 PM, Jeff Chua
>> I'll try the "idle=poll" to see if that works and will try some printk
> 
> I don't know what exactly the i915_suspend() and i915_resume() are 
> supposed to do because it works better without them.
> 
> After inserting "return 0;" right at the top of those two functions, 
> suspend (and power-off properly), and resume (without green screen) 
> works just fine.
..

Does this machine have more than one CPU core?  If so..
Does your kernel have CONFIG_HOTPLUG_CPU=y (if not, enable it).

??