Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762856AbYBUEia (ORCPT ); Wed, 20 Feb 2008 23:38:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755226AbYBUEiU (ORCPT ); Wed, 20 Feb 2008 23:38:20 -0500 Received: from mx1.suse.de ([195.135.220.2]:54244 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755223AbYBUEiS (ORCPT ); Wed, 20 Feb 2008 23:38:18 -0500 Date: Wed, 20 Feb 2008 20:43:31 -0800 From: Greg KH To: Nigel Cunningham Cc: Matthew Garrett , Jesse Barnes , Linus Torvalds , "Rafael J. Wysocki" , Jeff Chua , lkml , Dave Airlie , linux-acpi@vger.kernel.org, suspend-devel List Subject: Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green. Message-ID: <20080221044331.GB21499@suse.de> References: <200802201241.30952.jesse.barnes@intel.com> <200802201344.11643.jesse.barnes@intel.com> <47BCAD6E.9080704@nigel.suspend2.net> <20080221001357.GA29796@srcf.ucam.org> <47BCC866.9000102@nigel.suspend2.net> <20080221004632.GA25869@suse.de> <47BCD112.3010708@nigel.suspend2.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47BCD112.3010708@nigel.suspend2.net> User-Agent: Mutt/1.5.16 (2007-06-09) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2818 Lines: 65 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 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? >>>> 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 where >>>> moving away from the current model doesn't buy you anything, but that >>>> doesn't mean that the current model is a good thing. It's not. The >>>> freezer is a fundamentally broken concept. >>> Putting drivers and filesystems in userspace is the fundamentally broken >>> concept. Not just when it comes to the freezer. The whole idea is >>> inherently racy. >> Racy with regards to other things becides trying to suspend a machine? >> If so, what? > > That depends on what sort of tangled web you want to weave. Lots of them :) We have tanks running Linux using userspace USB drivers for vision control systems (scary, I know...) They seem to be successfully running for many years now, and I'm interested in making sure those kinds of things keep working. We also have laser welding robots with userspace PCI drivers in car manufacturing plants. And other laser cutting robots slicing wood in patterns moving at a rate of over 3 meters a second. Again, with userspace drivers and Linux. Those users would also love to know of any potential problems you know of for this situation. > Low memory situations is one other situation that occurs to me > quickly, especially (though not only) if your ability to swap were to > depend upon a userspace driver and/or filesystem. Sure, swap over a userspace filesystem or driver isn't a sane idea. And neither is swaping over NFS over a PPP connection attached to a USB to serial device. Yes, it's possible, and all in the kernel, but not a wise decision. Other than foolish configurations, if you come up with other issues surrounding userspace drivers that could cause problems, please let me know. thanks, greg k-h -- 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/