On Mon, 7 May 2007, Mike Nuss wrote: > Alan Stern wrote: > > > > > > Could be the driver updated the pointers but did so at the wrong > time, > > > with the result that the controller overwrote them with older > values. > > > Or maybe just one of them was overwritten. Would that explain your > > > observations? > > It's probably nothing, but this line in ohci-q.c in td_submit_urb raised > an eyebrow: > > urb_priv->ed->hwHeadP &= ~cpu_to_hc32 (ohci, ED_C); > > There is a comment "resetting toggle is meaningless if the endpoint is > active" above this code. While that's true, I wouldn't expect this > operation to be atomic. What happens if the HC is updating headP during > this block? I would think the driver could potentially overwrite it with > the old value.
I would think the same thing. In fact, the whole reason for that section of code is mysterious. The comment implies that it's not supposed to apply to bulk or interrupt endpoints, and isochronous endpoints don't use toggles anyway. Resetting the toggle at the start of a control transfer makes sense -- but the code doesn't test to see if it's dealing with a control endpoint or if the endpoint is currently running. Maybe it shouldn't be there at all. Dave, do you understand 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
