Mike Nuss wrote: > David Brownell wrote: >> Hmm. Here's a theory. The way that the current code unlinks >> an ED is to set the SKIP bit *AND* remove the ED from the relevant >> part of the schedule. >> >> Maybe ... the hardware gets confused when the ED doesn't seem >> to be on the relevant list. Like maybe it expects it to stay >> at the head of the ED list. ISTR some silicon doesn't much >> like to see null pointers written into the hardware registers, >> and I know for a fact that the ed_deschedule logic was always >> a bit racey. >> >> That suggests that the safest route would be setting SKIP for >> one frame (so all pending TDs get properly retired), and >> only *THEN* taking it out of the queue.
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. C = the device is removed. Then ohci-hcd hangs while waiting to free the outstanding TD, which will never happen since the HC thinks the TD is already finished. The only cases I have observed SKIP being set are after time C. So I don't think that the descheduling code is responsible for the problem. As sort-of good news, I ran some more tests today and now I know for *sure* that the transfer really did complete, and I can even get transfers going again. After time B, my device driver can detect that there's a problem just by the fact that no new data has come in for 30 seconds. So, I added a new hook to ohci-q that "pretends" that the TD really did come back through the donelist, and goes through the normal TD completion routine. My driver calls this hook when it detects that the 30 second timeout has expired. The URB completes normally, with all the data intact. Then it's resubmitted for the next read, and everything works normally again. I'm at a loss. It really looks like the HC just "skipped" a step for no reason. Is there any possibility the USB device itself could be causing a problem? I haven't looked into that possibility yet. Mike ------------------------------------------------------------------------- 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
