Hi Thanks for the quick response. > > > > > Alan you may be correct. Let me explain, the issue occurs while > > > unplugging the device during Tx transfer, > > > 1) During Tx transfer, TX-DMA is programmed to transfer the data. > > > 2) The TX-DMA completes the transfer and generates > completion interrupt. > > > 3) On tx completion interrupt context the URB is given back. > > > In normal scenario, the sequence 1 to 3 occurs during tx > transfers. > > > Issue occurs when the device is unplugged while TX-DMA > transfer is > > > in progress. The DMA halts and never generates completion > interrupt. > > > In > > > > What host controller driver are you using? It is mentor controller integrated with CPPI41-DMA > > > > 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. > > > > > this scenario, this active request at DMA is given back when > > > application calls dequeue or unlink the URB. Since in > this scenario > > > since there is no timeout occurs on the URB, we expect the scsi > > > layer should unlink the active URB upon DISCONNECT of device. > > > > Not until the command times out. > > > > > In this scenario, when the DISCONNECT occur, scsi does not unlink > > > the active URB, this patch fixing this issue. > > > Can you point me which function unlink the active URB > (which is not > > > returned). > > > Let me know if you have better solution or any suggestion. > > > > 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. > 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 ? Have you connected the device through HUB ? What happen if the device connected directly to root port (without HUB). Regards Ravi Babu > > 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
