> -----Original Message----- > From: Alan Stern [mailto:stern@xxxxxxxxxxxxxxxxxxx] > Sent: Friday, August 03, 2012 7:15 AM > To: B, Ravi > Cc: Matthew Dharm; Greg Kroah-Hartman; > linux-usb@xxxxxxxxxxxxxxx; usb-storage@xxxxxxxxxxxxxxxxxxxxxxxx > Subject: RE: [PATCH] usb: storage: stop all current urbs when > device is disconnected > > On Fri, 3 Aug 2012, B, Ravi wrote: > > > > > What host controller driver are you using? > > > > It is mentor controller integrated with CPPI41-DMA > > Then you're using the musb driver? > > > > > Why doesn't the controller hardware detect that the > device fails > > > > to send handshake packets and abort the transfer? According > > > to the USB-2 > > > > spec, after three failures the controller must end the > > > transfer. This > > > > sounds like a bug in the controller or its driver. > > > > The usb flash drive is connected directly to root port. > > Hence when the device is disconnected, the controller does not > > continue (no SOF) due to all devices connected to port are > disconnected. > > Hence controller will not retry or transfer the data to device. > > This must be expected behavior. > > Well, I suppose it's the _designed_ behavior. But it's still > arguably a bug. > > Maybe the musb driver should be changed. It should cancel > all the active URBs when all the ports are disconnected or suspended. > > > > > I would expect the command to time out and be unlinked by > > > > command_abort() after 30 seconds or so, and I would expect > > > > scsi_remove_host() to wait until this happens. If this doesn't > > > > happen, it indicates a bug in the SCSI or block layers. > > > > > > > During disconnect event in the middle of transfer, the scsi > knows that > > the device no more exits, I think there is no need to wait > for timeout > > for active URB, it is safe to unlink or cancel the active URB. > > Actually the SCSI layer does _not_ know that the device has > been removed. It only knows that the driver has been unbound > from the device. The behavior is the same as if you did > "rmmod usb-storage" > while leaving the device plugged in. > > Anyway, it seems clear that your patch won't help. The new > code you added won't run until after the 30-second timeout > has expired, and by then it's not needed any more. Alan, I did not understand, if the driver has unbound from the device, what is the need to wait for 30seconds timeout to cancel the URB. Can you explain in detail. > > > > I tried doing a similar experiment on my system. I got > rid of the > > > code that makes ehci-hcd stop retrying after a maximum number of > > > transaction errors (so that it would continue to retry > > > indefinitely), and then pulled out my USB flash drive while a > > > program was reading from it. > > > > > > The result was exactly as predicted: After 30 seconds the current > > > transfer was aborted, and scsi_remove_host() waited for this to > > > happen. > > > > Why scsi to wait for 30 seconds timeout upon receiving the DEVICE > > DICONNECT Notfication ? > > That's the timeout for all the SCSI commands. The timeout > doesn't change when the disconnect notification is received. During disconnect, it is better to cancel all queued and active current URB, why to wait for 30sec timeout. The API usb_stor_stop_transport() does the same. This API is safe it only unlink if there is active URB. > > > Have you connected the device through HUB ? > > No. > > > What happen if the device connected directly to root port > (without HUB). > > As I described above. > > 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
