Message-ID: <alpine.LFD.1.00.0802201355590.7833@woody.linux-foundation.org>
Date:	Wed, 20 Feb 2008 14:22:13 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jesse Barnes <jesse.barnes@...el.com>
cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Jeff Chua <jeff.chua.linux@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Dave Airlie <airlied@...ux.ie>, linux-acpi@...r.kernel.org,
	suspend-devel List <suspend-devel@...ts.sourceforge.net>,
	Greg KH <gregkh@...e.de>
Subject: Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk.
 Screen becomes 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 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists