Re: [PATCH] usb: core: update wait routine to set a timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 29, 2014 at 11:31:54AM -0400, Alan Stern wrote:
> On Thu, 29 May 2014, Huang Rui wrote:
> 
> > On Thu, May 29, 2014 at 10:50:03AM -0400, Alan Stern wrote:
> > > On Thu, 29 May 2014, Huang Rui wrote:
> > > 
> > > > Currently, in usb_sg_wait routine there isn't a timeout on waiting for
> > > > completion signal. When using TEST 5 -> 8 at usbtest module to verify
> > > > a new device controller with gadget zero, it would be hang on this
> > > > phase and this routine waits forever.
> > > 
> > > Why did it hang?  That's the real problem; you should fix that instead 
> > > of adding a timeout.
> > > 
> > 
> > Right, it might be a HW issue and still under analysis.
> > 
> > > > So it should add a timeout about
> > > > 10s to export a TIMEOUT error to return.
> > > 
> > > What makes you think 10 seconds is a good timeout value?
> > > 
> > 
> > This value is rough estimate, and can be changed.
> > 
> > > Sorry, this is not acceptable.  Any timeout value you specify has to 
> > > work for _all_ places that call this routine.  10 minutes might be 
> > > okay.
> > > 
> > 
> > But as a developer's view, when I run the tests, it should be better
> > to report a error even though it fails. But in some specail error
> > cases, usbtest TEST 5 -> 8 which used usb_sg_wait might wait forever
> > and the test is unable to stop. I think it is still not expected,
> > right? So do you have any idea to resolve this issue to make the
> > usbtest report the error codes and complete normally?
> 
> You could disconnect the gadget from the host.  Then usb_sg_wait() 
> would complete.  :-)
> 

Ahh, yes, you're right. :)

> Seriously, the right way to handle timeouts with usb_sg_wait() is to
> have a timer routine call usb_sg_cancel() when the timeout expires.  
> You could add such a timer to tests 5-8 in usbtest.
> 

So you mean I should do it in special class driver, not in core level,
right?

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]