On Fri, 18 Apr 2014, Matthieu CASTET wrote: > Hi, > > while playing with suspend to ram I found a strange behavior with usb > persistence. > > This can be easily reproduce by doing : > - plug a usb key > - start to read the usb key : "cat /dev/sdx > /dev/null" > - go to suspend : "echo mem > /sys/power/state" > - while in suspend, unplug and replug the usb key (simulate usb power > loss for computer that keep power) > - exit suspend > - there is read error on the usb key
Does the same thing happen if you start the "cat" command after the suspend/resume instead of before? > Because the power was cut during s2ram, the usb stack reset the device > <1>. > But when the user task restart, the usb storage device do not seem > ready to accept data traffic <2>, and IO error are returned to user > space application. > > It look like the device need some delay after the reset (800ms between > reset and <3>). No, that's not right. The device doesn't need any delay. You can verify this by pausing the "cat" command with ^Z before suspending and then restarting it with "fg" several seconds after resuming. Even with an arbitrarily long delay, the command will fail in the same way. > Shouldn't we wait that the device is ready before > restart IO on the device ? The device _is_ ready, so waiting won't help. Here's the problem: > <1> > [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using ehci-pci > [...] > [ 117.543922] Restarting tasks ... done. > [ 117.548390] video LNXVIDEO:01: Restoring backlight state > <2> > [ 117.549179] sd 6:0:0:0: [sdb] Media Changed > [ 117.549184] sd 6:0:0:0: [sdb] > [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE > [ 117.549189] sd 6:0:0:0: [sdb] > [ 117.549191] Sense Key : Unit Attention [current] > [ 117.549195] Info fld=0x0 > [ 117.549197] sd 6:0:0:0: [sdb] > [ 117.549201] Add. Sense: Not ready to ready change, medium may have changed The device reported a "Not-ready to ready change" because the power was lost and then restored. The SCSI layer interprets this as meaning that the media was changed, even though USB keys don't have changeable media -- evidently your key tells the computer that it does. > [ 117.549203] sd 6:0:0:0: [sdb] CDB: > [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00 > [ 117.549212] end_request: I/O error, dev sdb, sector 182528 Since the SCSI layer thinks the media was changed, it has no choice but to fail the read request. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
