Re: Power Management with rootfs on SDMMC.
- From: Andreas Mohr <andi@xxxxxxxx>
- Date: Sun, 29 Mar 2009 18:26:01 +0200
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Prev by Date: [PATCH] Staging: otus: remove old irqreturn_t definition
- Next by Date: Re: [PATCH 0/2] ptrace_vm: ptrace for syscall emulation virtual machines
- Previous by thread: [PATCH] Staging: otus: remove old irqreturn_t definition
- Next by thread: [rfc] scale dcache locking
- Index(es):
Relevant Pages
|
Loading
