Hi, On Mon, Nov 25, 2013 at 03:41:14PM -0500, Alan Stern wrote: > 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. awesome, thanks for the explanation Alan :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
