SD boot resume status

Andy Green andy at
Fri Feb 29 05:47:28 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
> Hi folks -
> Suspend / resume is working for SD Boot allowing for the current LCM
> resume issues.
> But even with the config option to allow "UNSAFE RESUME", on resume the
> *logical* ext2 filesystem is corrupted from the Linux side, even when

Well after a lot of struggle when it got to the point there were no more
excuses from our side like PSU suspend ordering, I found this:

''...On Sun, 2007-07-22 at 16:05 +0200, Pierre Ossman wrote:
> On Sun, 22 Jul 2007 14:18:33 +0100
> Richard Purdie <rpurdie at> wrote:
> > I enabled the MMC_UNSAFE_RESUME option and the problems I was seeing
> > was "fixed". I think having this option is a bad idea (in its current
> > form) as it doesn't actually stop filesystem corruption.
> >
> > With the option disabled, if a filesystem is mounted when you suspend
> > my tests show the filesystem is corrupted. At least if the option is
> > enabled, the filesystem is only corrupted if you remove the card
> > whilst suspended which is more preferable.
> I disagree. With this option you get silent corruption, without you get
> noisy corruption. And I would always prefer the latter, even if it
> increases the risk of it happening.

Corruption is corruption and it shouldn't happen if we can avoid it. It
happens with complete certainty in one case and only happens in the
other if the user does something which is a fairly obvious bad idea
(which is documented as such).

> > I guess the solution would be to abort the suspend if mounted systems
> > were detected and the option was disabled? Alternatively the option
> > could be "auto" enabled only for mounted systems maybe with a printk
> > warning?
> This is a general problem for all removable/hotpluggable storage. So
> sticking it in the MMC block device would be the wrong layer IMO.

It is however if the MMC layer is going to add Kconfig options which
corrupt things, it can add things to start fixing things too. If those
things can be adapted into more generic code paths, so much the better.


so basically it seems suspend with boot from SD is broken in the kernel
at the moment and results in exactly the filesystem corruption I see.


- -Andy

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list