Messages in this thread | | | Date | Sun, 29 Mar 2009 18:26:01 +0200 | From | Andreas Mohr <> | Subject | Re: Power Management with rootfs on SDMMC. |
| |
Hi,
On Fri, Jan 02, 2009 at 06:24:13PM +0100, Pavel Machek wrote: > > IMHO in this strongly increasingly netbook- and mobile phone-enabled world it's > > a bloody shame that: > ... > > - installing a swap partition on an SD card and then resuming can easily > > go as far as __even completely corrupting__ the entire SD card partitioning > > plus first partition (corrupts first 1kB of the card: both table and partition) > > People then immediately resort to a non-helpful "Don't Do This, Ever" reply > > (using swap partition on SD and suspend, see http://dev.laptop.org/ticket/6532#comment:10), > > but to this I'd say: > > News Flash, if this can theoretically be made to work at all using software > > (i.e. there are no VM-related _hard_ blockers to such an operation > > of using swap itself on a non-fixed SD slot), then this should goddamn be made > > to work practically on Linux, _somehow_, since on SSD netbooks this is > > the most natural thing to do to avoid wear of the builtin device. > > I'd like to help with this one... can you reproduce this?
Replying now since I'd like to give a status update:
I'm currently running a 2.6.29-rc8 with CONFIG_MMC_UNSAFE_RESUME enabled, and an external SD card mount (ext2) _does_ survive resume properly (most likely without this option it would still corrupt the partition after resume). Not sure whether use of the swap partition on this card is troublefree during resume, though... (not seen much use so far, and no issues yet either)
However while UNSAFE_RESUME does work, obviously it's not a good idea at all to have the Kconfig option described as:
config MMC_UNSAFE_RESUME bool "Allow unsafe resume (DANGEROUS)" help If you say Y here, the MMC layer will assume that all cards stayed in their respective slots during the suspend. The normal behaviour is to remove them at suspend and redetecting them at resume. Breaking this assumption will in most cases result in data corruption.
This option is usually just for embedded systems which use a MMC/SD card for rootfs. Most people should say N here.
since in such a use case it's obviously dangerous to _not_ have this option enabled.
Or, in other words (as I have written before), media management should get smarter to not need this option at all.
The least that should be done now is to drastically change this Kconfig description (mention that _both_ settings can be dangerous, and help people decide which one to use), to reflect current knowledge. I'd be willing to submit a patch... (--> Pierre, right?)
[[ JFYI:
I'm very relieved to see those severe SSD bio performance problems being addressed currently (Fengguang et al).
2.6.29-rc8 is too rough otherwise: still i915 issues: x.org crash every ~ half-dozen resumes; some ath5k weirdness (a suspected ath5k oops when doing rfkill, ...). Plus e100 non-MII variants still not supported in 2.6.29 (let's see how many complaints we get ;).
Going to install 2.6.29.1 (the one with network dropout fixed) once it appears.
]]
Thanks,
Andreas Mohr
| |