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

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

[Jeff Chua]

On Feb 16, 2008 5:00 AM, Greg KH <gregkh@suse.de> wrote:

> > Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it either.
>
> Ok, this looks to be something else.
>
> > Here's the last dmesg after suspend-to-disk and hang there...
> >
> > CPU 1 is now offline
> > SMP alternatives: switching to UP code
> > 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.10 seconds (0.00 MB/s)
> > ACPI: Preparing to enter system sleep state S4
> > Suspending console(s)
> >
> > [ ... it just hangs here ... press power-switch does the job, and
> > system is able to resume upon powering on ]
>
> Wait, this is a suspend-to-disk issue.  Totally different than the "will
> not power off" issue.
>
> Can you start a new thread on this, and add the suspend people to it?


I bisected down this one commit that causes the problem with
suspend-to-disk on Lenovo X60s (i945 chipset).

commit ba8bbcf6ff4650712f64c0ef61139c73898e2165
Author: Jesse Barnes <jesse.barnes@intel.com>
Date:   Thu Nov 22 14:14:14 2007 +1000

    i915: add suspend/resume support

    Add suspend/resume support to the i915 driver.  Moves some of the
    initialization into the driver load routine, and fixes up places where we
    assumed no dev_private existed in some of the cleanup paths.  This allows
    us to suspend/resume properly even if X isn't running.

    Signed-off-by: Dave Airlie <airlied@linux.ie>


There where problem reverting the some i915 files with the latest
linux git pull, so I copied those i915*.{h,c} prior to this commit,
and problem went away.


Suspend-to-ram, suspend-to-disk all working now.


Thanks,
Jeff.

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

[Jesse Barnes]

I found the same poweroff issue on my T61.  It turned out to be related to the 
C state code disabling interrupts when it shouldn't iirc.  Booting 
with 'idle=poll' seems to work around the problem.

The "green screen" problem should be fixed (see the DRM git tree for details).

Jesse

On Tuesday, February 19, 2008 4:53 pm Jeff Chua wrote:
> On Feb 16, 2008 5:00 AM, Greg KH <gregkh@suse.de> wrote:
> > > Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it
> > > either.
> >
> > Ok, this looks to be something else.
> >
> > > Here's the last dmesg after suspend-to-disk and hang there...
> > >
> > > CPU 1 is now offline
> > > SMP alternatives: switching to UP code
> > > 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.10 seconds (0.00 MB/s)
> > > ACPI: Preparing to enter system sleep state S4
> > > Suspending console(s)
> > >
> > > [ ... it just hangs here ... press power-switch does the job, and
> > > system is able to resume upon powering on ]
> >
> > Wait, this is a suspend-to-disk issue.  Totally different than the "will
> > not power off" issue.
> >
> > Can you start a new thread on this, and add the suspend people to it?
>
> I bisected down this one commit that causes the problem with
> suspend-to-disk on Lenovo X60s (i945 chipset).
>
> commit ba8bbcf6ff4650712f64c0ef61139c73898e2165
> Author: Jesse Barnes <jesse.barnes@intel.com>
> Date:   Thu Nov 22 14:14:14 2007 +1000
>
>     i915: add suspend/resume support
>
>     Add suspend/resume support to the i915 driver.  Moves some of the
>     initialization into the driver load routine, and fixes up places where
> we assumed no dev_private existed in some of the cleanup paths.  This
> allows us to suspend/resume properly even if X isn't running.
>
>     Signed-off-by: Dave Airlie <airlied@linux.ie>
>
>
> There where problem reverting the some i915 files with the latest
> linux git pull, so I copied those i915*.{h,c} prior to this commit,
> and problem went away.
>
>
> Suspend-to-ram, suspend-to-disk all working now.
>
>
> Thanks,
> Jeff.

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:
> I found the same poweroff issue on my T61.  It turned out to be related to the 
> C state code disabling interrupts when it shouldn't iirc.  Booting 
> with 'idle=poll' seems to work around the problem.

However, this issue is supposed to be fixed in 2.6.25-rc2, so most probably
there is another problem in there.

Thanks,
Rafael

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

[Linus Torvalds]

On Tue, 19 Feb 2008, Jesse Barnes wrote:
>
> I found the same poweroff issue on my T61.  It turned out to be related to the 
> C state code disabling interrupts when it shouldn't iirc.  Booting 
> with 'idle=poll' seems to work around the problem.
> 
> The "green screen" problem should be fixed (see the DRM git tree for details).

..and the latter is hopefully now merged in my tree too (at least some of 
the drm updates are).

		Linus

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

[Jesse Barnes]

On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote:
> On Tue, 19 Feb 2008, Jesse Barnes wrote:
> > I found the same poweroff issue on my T61.  It turned out to be related
> > to the C state code disabling interrupts when it shouldn't iirc.  Booting
> > with 'idle=poll' seems to work around the problem.
> >
> > The "green screen" problem should be fixed (see the DRM git tree for
> > details).
>
> ..and the latter is hopefully now merged in my tree too (at least some of
> the drm updates are).

Cool, thanks.

Jeff, can you retest with Linus' tree?  If you're still seeing problems, it 
might help to add some printks to the i915 driver's suspend routine.  Just 
reading the regs really shouldn't cause a hang, but maybe the VGA bits are 
subtly wrong again...

Thanks,
Jesse

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

[Jeff Chua]

On Feb 20, 2008 12:32 PM, Jesse Barnes <jesse.barnes@intel.com> wrote:
>
> On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote:
> > On Tue, 19 Feb 2008, Jesse Barnes wrote:
> > > I found the same poweroff issue on my T61.  It turned out to be related
> > > to the C state code disabling interrupts when it shouldn't iirc.  Booting
> > > with 'idle=poll' seems to work around the problem.
> > >
> > > The "green screen" problem should be fixed (see the DRM git tree for
> > > details).
> Jeff, can you retest with Linus' tree?  If you're still seeing problems, it
> might help to add some printks to the i915 driver's suspend routine.  Just
> reading the regs really shouldn't cause a hang, but maybe the VGA bits are
> subtly wrong again...

The funny thing is the screen is now normal during suspend, but the
green came back after suspend!

And the suspend still does NOT power off with lastest Linus's tree.

I'll try the "idle=poll" to see if that works and will try some printk as well.

Thanks,
Jeff.

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.

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

[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:
> 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]

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.

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

[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:
> 
> 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, 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.

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

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

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

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

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

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

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

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

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

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

[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 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, 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: 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.

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

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

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

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

??

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

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

[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]

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

[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;
  }