On Thu, 2 Aug 2012, B, Ravi wrote: > 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? 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. > 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. 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
