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 alternative
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
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 fixe
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
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
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 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 linu
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 functi
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
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
al
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 acpi_slee
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 c
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.
>
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 o
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 unin
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 act
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 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 shutd
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-
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 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, 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
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 us
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, 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 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 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 t
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
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
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 w
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 st
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/re
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 se
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 P
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 dir
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 als
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 e
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
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 pl
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.
driver
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 kexe
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 p
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 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
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 w
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
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 whatev
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 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 a
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 Ga
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 d
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 bo
[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 wait
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
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 device
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 t
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 acpi
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'v
On Wednesday, 20 of February 2008, Linus Torvalds wrote:
>
> On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
> >
> > I think we should export the target sleep state somehow.
>
> Yeah. By *not* using "->suspend()" for freezing or hibernate.
>
> Please, Rafael - just make the f*cking suspend-to-dis
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 goi
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 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 n
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 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,
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:
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:
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, t
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
> u
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 i
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 w
78 matches
Mail list logo