On Tue, May 17, 2011 at 5:15 AM, Dong, Chuanxiao <chuanxiao.dong@xxxxxxxxx> wrote: > > >> -----Original Message----- >> From: linux-mmc-owner@xxxxxxxxxxxxxxx >> [mailto:linux-mmc-owner@xxxxxxxxxxxxxxx] On Behalf Of Andrei Warkentin >> Sent: Tuesday, April 05, 2011 4:31 AM >> To: linux-mmc@xxxxxxxxxxxxxxx >> Cc: Andrei Warkentin >> Subject: [RFC] MMC: Request for comments attempt at dealing with removeable >> suspend/resume. >> >> Is there any value to doing something like this in order to be able to >> suspend/resume >> with a (manually, or rootfs) mounted filesystem on mmcblk? >> >> Thoughts? > Hi Andrei, > I also encountered the same issue with you when system is suspending. And the modification in core.c actually can fix my issue. > For the mounted root file system, I think it makes sense for such medias to use MMC_UNSAFE_RESUME. Is there some use case need to remove root file system media? > Except that if the filesystem (non-root) fails to unmount or it's a root filesystem on a device on a host which isn't MMC_UNSAFE_RESUME, then you will re-enumerate incorrectly on resume. On resume, fs will be on a now "dead" device (say mmc0), while kernel will re-enumerate card as mmc1 now since mmc0 never tore down. Basically even if you're smart enough to avoid switching cards on suspend/resume, this can still get to you and you will wind up with either just a hang (if root fs on card), or weird re-enumeration and countless I/O errors to dead device. What above patch does is that it uses a two step process to clean up MDs. MDs are put on an orphan list when the backing device goes away. If they can be safely cleaned up - great, and they go away completely when the refcount drops. Otherwise, they'll be "reconnected" to if the *same* backing device reappears again. A -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
