On Friday, 22 of February 2008, [EMAIL PROTECTED] 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:
> [EMAIL PROTECTED] 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:
[EMAIL PROTECTED] wrote:
..
I've been watching for kexec hibernate for a little while now, and the
last I saw was that
On Friday, 22 of February 2008, Mark Lord wrote:
> Rafael J. Wysocki wrote:
> > On Friday, 22 of February 2008, Mark Lord wrote:
> >> [EMAIL PROTECTED] wrote:
> >> ..
> >>> I've been watching for kexec hibernate for a little while now, and the
> >>> last I saw was that acpi was incompatible with
Rafael J. Wysocki wrote:
On Friday, 22 of February 2008, Mark Lord wrote:
[EMAIL PROTECTED] 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
On Friday, 22 of February 2008, Mark Lord wrote:
> [EMAIL PROTECTED] 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
[EMAIL PROTECTED] 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
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
Hi!
> It's "snapshot-and-restore", and my opinion is that:
>
> - it should *never* call "suspend()"/"resume()" at all (that should be
>reserved purely for suspend-to-RAM and has real power management
>issues!)
Hmm, entering S4 seems like good place to call suspend() for... unless
you
Hi!
It's snapshot-and-restore, and my opinion is that:
- it should *never* call suspend()/resume() at all (that should be
reserved purely for suspend-to-RAM and has real power management
issues!)
Hmm, entering S4 seems like good place to call suspend() for... unless
you want
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
[EMAIL PROTECTED] 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
On Friday, 22 of February 2008, Mark Lord wrote:
[EMAIL PROTECTED] 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
Rafael J. Wysocki wrote:
On Friday, 22 of February 2008, Mark Lord wrote:
[EMAIL PROTECTED] 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
On Friday, 22 of February 2008, Mark Lord wrote:
Rafael J. Wysocki wrote:
On Friday, 22 of February 2008, Mark Lord wrote:
[EMAIL PROTECTED] 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
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:
[EMAIL PROTECTED] wrote:
..
I've been watching for kexec hibernate for a little while now, and the
last I saw was that
On Friday, 22 of February 2008, [EMAIL PROTECTED] 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:
[EMAIL PROTECTED] wrote:
..
I've been watching for kexec
On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> > Below is a patch that should work around the issue. Please try it and let
> > me know if it helps.
>
> I ended up applying the below patch instead, so
On Friday, 22 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> > Below is a patch that should work around the issue. Please try it and let
> > me know if it helps.
>
> I ended up applying the below patch instead, so it would build, and
>
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> Below is a patch that should work around the issue. Please try it and let
> me know if it helps.
I ended up applying the below patch instead, so it would build, and
unfortunately it still hung at suspend time.
So at this point,
Here are some USB fixes against your 2.6.25-rc2 git tree.
It includes:
- lots of device id updates for the wireless usb-serial cards
- more quirk additions
- bugfixes in various drivers
Please pull from:
On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> > On Thursday, 21 of February 2008, Jeff Chua wrote:
> > > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > > On Wednesday, February 20, 2008
On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
> On Thursday, 21 of February 2008, Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
wrote:
> > > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > > > On Thu, Feb 21, 2008 at 5:37
On Thursday, 21 of February 2008, Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
> > wrote:
> > > > Ok, can you give
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
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
On Thursday, 21 of February 2008, Jeff Chua wrote:
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
Ok, can you give this patch a
On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
On Thursday, 21 of February 2008, Jeff Chua wrote:
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse
On Thursday, 21 of February 2008, Jesse Barnes wrote:
On Thursday, February 21, 2008 8:27 am Rafael J. Wysocki wrote:
On Thursday, 21 of February 2008, Jeff Chua wrote:
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes [EMAIL PROTECTED]
wrote:
On Wednesday, February 20, 2008 4:35 pm Jeff
Here are some USB fixes against your 2.6.25-rc2 git tree.
It includes:
- lots of device id updates for the wireless usb-serial cards
- more quirk additions
- bugfixes in various drivers
Please pull from:
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
Below is a patch that should work around the issue. Please try it and let
me know if it helps.
I ended up applying the below patch instead, so it would build, and
unfortunately it still hung at suspend time.
So at this point,
On Friday, 22 of February 2008, Jesse Barnes wrote:
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
Below is a patch that should work around the issue. Please try it and let
me know if it helps.
I ended up applying the below patch instead, so it would build, and
On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
Below is a patch that should work around the issue. Please try it and let
me know if it helps.
I ended up applying the below patch instead, so it would
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
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
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
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > Ok, can you give this patch a try with the 'platform' method? It should
> >
On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes <[EMAIL PROTECTED]> 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
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
On Wednesday, February 20, 2008 5:19 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]>
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
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> 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:
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
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
On Thursday, 21 of February 2008, Jesse Barnes wrote:
> On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
> > > And just to confirm that, I just tested the current DRM modules against a
> > > 2.6.23.15 kernel.
> >
> > In 2.6.23.x there's no second ->suspend() during hibernation, so
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
On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
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
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
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
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]> 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.
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
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()
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
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
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
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 <[EMAIL
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 <[EMAIL PROTECTED]> wrote:
> > > > > So, next I'll try "shutdown" to
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
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
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 <[EMAIL PROTECTED]> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > "platform".
> > >
> > > Ok, that
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
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):
> > >
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> 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 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
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
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> 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
Rafael J. Wysocki wrote:
On Wednesday, 20 of February 2008, Linus Torvalds wrote:
On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
I think we should export the target sleep state somehow.
Yeah. By *not* using "->suspend()" for freezing or hibernate.
Please, Rafael - just make the
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
On Wednesday 20 February 2008 at 3:29 pm, Linus Torvalds penned
about "Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after
suspend-to-disk. Screen becomes green."
> Can we please get this fixed some day?
I can't say I even come close to understand what's going on but
On Wednesday, 20 of February 2008, Linus Torvalds wrote:
>
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> >
> > I think we should export the target sleep state somehow.
>
> Yeah. By *not* using "->suspend()" for freezing or hibernate.
>
> Please, Rafael - just make the f*cking
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
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
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 <[EMAIL PROTECTED]> wrote:
> > > > > So, next I'll try "shutdown" to see
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 <[EMAIL PROTECTED]> wrote:
> > > > So, next I'll try "shutdown" to see if it work. I was using
> > > > "platform".
> > >
> > > Ok, that
On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
> On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> 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 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
On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> 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
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
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
>
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
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
On Feb 21, 2008 1:50 AM, Jesse Barnes <[EMAIL PROTECTED]> 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
On Feb 21, 2008 1:52 AM, Linus Torvalds <[EMAIL PROTECTED]> 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
On Feb 21, 2008 1:28 AM, Linus Torvalds <[EMAIL PROTECTED]> 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
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
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.
>
On Feb 21, 2008 1:28 AM, Linus Torvalds <[EMAIL PROTECTED]> 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
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
On Feb 21, 2008 1:17 AM, Jeff Chua <[EMAIL PROTECTED]> 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.
--
To unsubscribe from this list: send the line "unsubscribe
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
On Feb 21, 2008 1:28 AM, Linus Torvalds [EMAIL PROTECTED] 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
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
On Feb 21, 2008 1:17 AM, Jeff Chua [EMAIL PROTECTED] 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.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
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
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
On Feb 21, 2008 1:52 AM, Linus Torvalds [EMAIL PROTECTED] 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
On Feb 21, 2008 1:28 AM, Linus Torvalds [EMAIL PROTECTED] 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
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
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
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
On Feb 21, 2008 1:50 AM, Jesse Barnes [EMAIL PROTECTED] 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
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
1 - 100 of 155 matches
Mail list logo
