[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m3k505qfyl.fsf@pullcord.laptop.org>
Date: Fri, 11 Sep 2009 18:22:42 -0400
From: Chris Ball <cjb@...top.org>
To: Zdenek Kabelac <zdenek.kabelac@...il.com>
Cc: Pavel Machek <pavel@....cz>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Christoph Hellwig <hch@....de>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mmc@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: Regression in suspend to ram in 2.6.31-rc kernels
Hi,
> IMHO steps 2..6 are only valid for the case I would 'remove'
> unexpectedly card - but if I suspend and resume my laptop and I
> keep the card inside - all those step looks plain wrong.
How can the MMC stack tell whether you kept the card inside or
modified it during suspend?
There's no way to know, and an incorrect guess gives you filesystem
corruption, so we remove cards on suspend and reprobe them on resume.
(If you did know that cards would never be removed during suspend,
you could set CONFIG_MMC_UNSAFE_RESUME=y.)
So, I'd say:
>> a) card removed event from mmc for suspend is right design?
Yes, for a card containing a filesystem with CONFIG_MMC_UNSAFE_RESUME
not set.
>> b) the card can be changed/removed before system was resumed, mmc
>> can be detect/handle it properly?
Yes, precisely because we removed it before suspend.
>> c) flushing buffers on _deleted_ device is right design?
No, something's obviously gone wrong here.
--
Chris Ball <cjb@...top.org>
One Laptop Per Child
--
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