Re: OHCI hangs after failing to free resources

On Fri, 6 Jul 2007, Mike Nuss wrote:

> Alan Stern wrote:
> > On Thu, 5 Jul 2007, Mike Nuss wrote:
> > 
> >> There are three time periods in question.
> >>
> >> A = before there is any problem
> >>
> >> B = a read seems to have completed, the HC has advanced HeadP, but
> >> failed to put the completed TD on the donelist. At this point, something
> >> is seriously wrong, but ohci-hcd has no way of knowing this.
> > 
> > Are you really sure about that?  Isn't the HC allowed to delay updated 
> > the donelist pointers until the end of the frame?
> 
> All the other endpoints continue to function normally. Since NextED
> happens to be null in the cases I've seen, that means that it's on the
> end of its list and the other endpoints must be on other lists, which
> implies that at least one frame boundary must be crossed between
> handling the 'hung' endpoint and any others. Is that right?

AFAIK there are only two lists (apart from the "done" list): the
periodic list and the async list.  The HC is allowed and expected to
jump between them during the course of a single frame.

> > Now if you know for certain that at least one frame boundary has passed 
> > since the transfer completed and the TD still isn't on the donelist, 
> > then I'd say you've found a bug in the controller hardware.  Under such 
> > circumstances the driver would be justified in retiring the TD on its 
> > own initiative.
> 
> I have working code that does this now and seems to be harmless, but I
> don't think this chipset (ZF Micro "CS5540") is very common, so it would
> probably be difficult for anyone else to validate the fix. The bigger
> problem is that it requires the higher level device driver to kick
> ohci-hcd to let it know there's a problem. I'm not sure how else
> ohci-hcd would know that the TD was really done unless it monitored the
> contents of HeadP and HccaDoneHead periodically to look for the
> inconsistency, but I'm open to suggestions.

The only way it can know is by scanning through the data structures.  
But this doesn't have to be done in response to a kick from a
higher-level driver.  It could be done whenever a SOF or URB-completion
interrupt is received, for example.

> We're thinking about looking at this on a logic analyzer to try to see
> if the HC seems to have attempted to update HeadP, but unfortunately we
> didn't have room on the board for test points, so it's going to be messy.

Suppose it really does turn out to be a hardware bug in your particular 
brand of HC.  Then what would you like to do about it?

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel