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 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
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 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 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-acpi in
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 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
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 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
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
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 thought I
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 resume.
Ok,
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 would be good to try.
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 if it work. I
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, 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
On Wednesday 20 February 2008 at 3:29 pm, Linus Torvalds penned
about Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off after
suspend-to-disk. Screen becomes green.
Can we please get this fixed some day?
I can't say I even come close to understand what's going on but
getting s2ram
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
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 resume.
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*
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:
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, 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)
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 resume.
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, 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 would be good to try.
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
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.
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 see if it work.
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 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
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
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
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 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.
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 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
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 probably
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
On Thursday, 21 of February 2008, Jesse Barnes wrote:
On Wednesday, February 20, 2008 3:49 pm Rafael J. Wysocki wrote:
And just to confirm that, I just tested the current DRM modules against a
2.6.23.15 kernel.
In 2.6.23.x there's no second -suspend() during hibernation, so no wonder.
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
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 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:
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 function
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 to
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 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
at least
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
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 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,
On Feb 16, 2008 5:00 AM, Greg KH [EMAIL PROTECTED] 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
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,
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
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
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
On Feb 20, 2008 12:32 PM, Jesse Barnes [EMAIL PROTECTED] 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
71 matches
Mail list logo
