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/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
