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. > > 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. > 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
