Lost IAA and EHCI reclaim problems

Dave:

I just read through your old iaa_watchdog patch, and there are several 
things about it (maybe about the pre-patch code too) that seem strange.

Management of the reclaim list is wrong.  Every qh that was added 
before the IAA doorbell bit was set should get unlinked when 
end_unlink_async() runs, whereas qhs added after the IAAD bit should 
cause another IAA cycle.  However end_unlink_async() never changes
more than one qh's state to QH_STATE_IDLE.

The iaa_watchdog routine seems to assume that STS_IAA gets set properly
and the interrupt is never delivered.  Isn't it likely that some
controllers may fail to set STS_IAA at all?  Shouldn't the watchdog
routine take a more careful approach?  For example, it could disable
the async schedule, wait until the schedule really was off, then clear
CMD_IAAD and handle all the pending unlinks.

Here's a somewhat unrelated question that came up earlier:  When an
async transfer stops because of an error the endpoint queue has to be
restarted, presumably by setting qh->hw_current to point to the first
qtd in the next URB.  But the driver never does this.  How does a
stopped queue get restarted?  Does it go through an unlink cycle first?

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel