Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933636AbYCFUdu (ORCPT ); Thu, 6 Mar 2008 15:33:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755101AbYCFUdm (ORCPT ); Thu, 6 Mar 2008 15:33:42 -0500 Received: from iolanthe.rowland.org ([192.131.102.54]:45416 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752036AbYCFUdm (ORCPT ); Thu, 6 Mar 2008 15:33:42 -0500 Date: Thu, 6 Mar 2008 15:33:41 -0500 (EST) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Pavel Machek cc: David Brownell , Pierre Ossman , "Rafael J. Wysocki" , pm list , Zdenek Kabelac , Kernel development list Subject: Re: Bugs in MMC [was: [Bug 10030] Suspend doesn't work when SD card is inserted] In-Reply-To: <20080306155553.GA3908@ucw.cz> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1644 Lines: 39 On Thu, 6 Mar 2008, Pavel Machek wrote: > On Tue 2008-03-04 16:00:51, Alan Stern wrote: > > On Tue, 4 Mar 2008, David Brownell wrote: > > > > > > What's wrong with a superfluous probe at resume time, besides the waste > > > > of a few milliseconds? > > > > > > I'm more concerned with the undesirable removal of devices at suspend > > > time ... ones with mounted filesystems etc. > > > > On that we can agree. The removal is done if the host doesn't define a > > resume method. There doesn't seem to be any point to that, given that > > the probing during resume will determine whether a card has in fact > > been removed. > > Hmm, if the driver is sleeping too deeply, user might have removed the > card and put in different one, without driver noticing. That would be > _bad_. Ironically, the very same problem now exists with the USB mass-storage driver. I don't see any way for the driver itself to solve it, especially during a hibernation (which can be a _very_ deep sleep). One thing that could be done is for filesystems to verify, after a system sleep, that their superblocks haven't changed. There could still be issues with non-mounted partitions, if they have live entries in the block cache, but it would be an improvement. Do you know the right people to mention this to? Anybody in filesystem development interested in suspend/hibernation issues? Alan Stern -- 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/