Hi Alan, thanks for your answers. Le Fri, 18 Apr 2014 10:42:14 -0400, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> a écrit : > 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? No, "echo mem > /sys/power/state; cat /dev/sdx > /dev/null" works. > > > <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. yes, I tested with differents usb key and all of them report removable (1 in /sys/devices/pci0000:00/*/usb*/*/*/host*/target*/*/block/sdx/removable). > > > [ 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. ok. I suppose the scsi layer can't ignore "Not-ready to ready change" event at resume time ? Matthieu -- 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
