Web lists-archives.com

Re: [linux-usb-devel] OHCI hangs after failing to free resources

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.

At least in the case of our device driver, which reuses a single read
URB per device, there should only be one outstanding TD at a time. So
when ed_deschedule gets called, there would not be any TDs outstanding.
This also puts a big hole in my theory, since the timing window I was
imagining shouldn't exist in this case.

For what it's worth, the sample code in the OHCI spec doesn't wait until
the next SOF either when removing an ED from the schedule. But that
doesn't necessarily reflect all real world situations ;) And since the
TD queue never builds up, it doesn't seem like the type of use the spec
was expecting.

The ED (de)scheduling code is completely unknown to me at this point.
I'll get familiar with it.


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.
To unsubscribe, use the last form field at: