Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763468AbYBTWp0 (ORCPT ); Wed, 20 Feb 2008 17:45:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753676AbYBTWpL (ORCPT ); Wed, 20 Feb 2008 17:45:11 -0500 Received: from crca.org.au ([67.207.131.56]:57715 "EHLO crca.org.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753182AbYBTWpJ (ORCPT ); Wed, 20 Feb 2008 17:45:09 -0500 X-Bogosity: Ham, spamicity=0.000000 Message-ID: <47BCAD6E.9080704@nigel.suspend2.net> Date: Thu, 21 Feb 2008 09:45:02 +1100 From: Nigel Cunningham Reply-To: nigel@nigel.suspend2.net User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Jesse Barnes CC: Linus Torvalds , "Rafael J. Wysocki" , Jeff Chua , lkml , Dave Airlie , linux-acpi@vger.kernel.org, suspend-devel List , Greg KH Subject: Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green. References: <200802201241.30952.jesse.barnes@intel.com> <200802201344.11643.jesse.barnes@intel.com> In-Reply-To: <200802201344.11643.jesse.barnes@intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2163 Lines: 44 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/