On Mon, 25 Nov 2013, Daniel Mack wrote: > >>> What if you have a mounted file system on a pendrive ? Should we allow > >>> suspend in that case ? > >> > >> Well, I would have expected that, but in fact, the opposite is true. > >> With 3.12, mounting a filesystem on a USB media and accessing it after > >> resume was exactly my test case, and it worked just fine with that patch. > > > > so you had a mounted file system, suspend, resume, it was still mounted? > > Yes, exactly. > > > or did it reenumerate and you remounted it ? > > No, it did not reenumerate, but the core did a reset on it. See the > following log. ... > [ 32.030792] usb 1-1: reset high-speed USB device number 2 using > musb-hdrc <<<< ! Like I said, you get a reset-resume. > > Try to do the same with transfers in flight, it's likely to corrupt your > > file system. It's not so easy to suspend a system with USB mass-storage transfers in flight. For one thing, userspace gets frozen before the suspend starts, so there's nothing to initiate new I/O requests (except perhaps for dirty-block writebacks). Also, the child SCSI device gets suspended before the USB device, so its I/O queue stops running. In addition, the usb-storage suspend routine and the main I/O thread are mutually exclusive (they both grab the private mutex), so a suspend can't occur while a SCSI command is underway. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
