On Tue, 30 Jul 2013, Philipp Dreimann wrote: > On Mon, Jul 29, 2013 at 7:04 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > It turns out I was probably wrong. Take a look at this message: > > > > http://marc.info/?l=linux-scsi&m=137511040432420&w=2 > > > > The patch in that email may fix your problem. > It does. Thanks! > > I am unfortunately still seeing the suspend/resume issue which I > linked in the inital report: > The drive works if it is attached while the system is running. It is > not accessible anymore after a syspend/resume cycle that lasts a bit. > (A few minutes seem to be sufficient.) I do not know any good kernel > version for this problem. > Plugging the device in while the system is suspended does not work > reliably too, yielding a similar error, just with a few more retries: > > Suspend/Resume: > usb 4-2: USB disconnect, device number 9 > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 10, error -71 > > Plugged before resume: > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 12, error -71 > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 14, error -71 > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 16, error -71 > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 18, error -71 > usb 4-2: Device not responding to set address. > usb 4-2: Device not responding to set address. > usb 4-2: device not accepting address 20, error -71 > > > A usbmon log is attached for the Suspend/Resume case running 3.11-rc3 > + the patch you pointed me at. The usbmon trace shows that the drive disconnects from the USB bus while the system is suspended. It doesn't reconnect until the system has been awake for a couple of seconds. This appears to be a hardware or firmware bug in the drive itself. As for why the errors occur after that, I can't tell. Sarah, the usbmon trace shows that after doing a successful port reset and clearing a bunch of port features, the system tells the port to go into the SS.disabled state for no apparent reason: ffff88014649f3c0 1804119918 S Co:4:001:0 s 23 03 0004 0002 0000 0 ffff88014649f3c0 1804119924 C Co:4:001:0 0 0 ffff88020a1dd000 1804170382 S Ci:4:001:0 s a3 00 0000 0002 0004 4 < ffff88020a1dd000 1804170389 C Ci:4:001:0 0 4 = 03021000 ffff8801b7173300 1804221388 S Co:4:001:0 s 23 01 0014 0002 0000 0 ffff8801b7173300 1804221397 C Co:4:001:0 0 0 ffff8801b7173300 1804221398 S Co:4:001:0 s 23 01 001d 0002 0000 0 ffff8801b7173300 1804221403 C Co:4:001:0 0 0 ffff8801b7173300 1804221403 S Co:4:001:0 s 23 01 0019 0002 0000 0 ffff8801b7173300 1804221407 C Co:4:001:0 0 0 ffff8801b7173300 1804221408 S Co:4:001:0 s 23 01 0010 0002 0000 0 ffff8801b7173300 1804221412 C Co:4:001:0 0 0 ffff8801b7173300 1804221414 S Ci:4:001:0 s a3 00 0000 0002 0004 4 < ffff8801b7173300 1804221417 C Ci:4:001:0 0 4 = 03020000 ffff88014649f3c0 1804623388 S Co:4:001:0 s 23 03 0005 0402 0000 0 ffff88020ceb1600 1804623409 C Ii:4:001:1 0:2048 1 = 04 ffff88020ceb1600 1804623410 S Ii:4:001:1 -115:2048 4 < ffff88014649f3c0 1804623415 C Co:4:001:0 0 0 Do you have any idea why it is doing this? 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
