Hi 

> On Thu, 2 Aug 2012, B, Ravi wrote:
> 
> > > > --- a/drivers/usb/storage/usb.c
> > > > +++ b/drivers/usb/storage/usb.c
> > > > @@ -844,6 +844,8 @@ static void
> > > quiesce_and_remove_host(struct us_data *us)
> > > >          */
> > > >         scsi_lock(host);
> > > >         set_bit(US_FLIDX_DISCONNECTING, &us->dflags);
> > > > +       /* stop the current urbs when the device got 
> disconnected */
> > > > +       usb_stor_stop_transport(us);
> > > 
> > > This shouldn't be necessary.  This code runs after
> > > scsi_remove_host() returns, so there should not be any 
> URBs running 
> > > at this point.
> > > 
> > > Have you actually encountered a problem that this patch fixes?
> > 
> > In specific condition, where the transmit request is in 
> progress and 
> > device is unplugged from host, found that this current tx 
> request is 
> > not dequeued/unlinked during disconnect.
> 
> Please provide more information.  What specific condition?  
> What was the current request?  How did this happen?
> 
> If the device was unplugged while an URB was active, the URB 
> should have completed very quickly with a failure.  Why 
> didn't it fail?
> 
> As far as I can tell, this shouldn't be needed.  
> scsi_remove_host() calls scsi_forget_host(), which calls 
> __scsi_remove_device(), which calls scsi_free_queue(), which 
> calls blk_cleanup_queue(), which calls blk_drain_queue(), 
> which should wait until all pending requests are finished.
>

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

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.

Thanks
Ravi B

> Alan Stern
> 
> --
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to