Re: Question about change to ehci-hcd

On Wednesday 15 August 2007, Alan Stern wrote:
> It looks like the original code has a mistaken optimization there.  If 
> during a callback some driver submitted an URB and then unlinked it, 
> the unlink would effectively get lost.

Don't think so.  As the comment says, the intent is to ensure that
there's a clear sync point:  URBs submitted after that IRQ triggers
will not be processed by that IRQ.  (Modulo delays actually getting
to that QH.)  And since that's the only path through which unlinks
can ever be processed ... your scenario can't happen.

Why the sync point?  Various reasons, including fairness and wanting
to ensure a "loop forever in IRQ" bug is impossible, regardless of
any driver bugs of the "resubmit forever" variety.

Also ISTR seeing some issues with certain hardware (who knows, maybe
it was VIA again!) if the driver got "ahead" of IRQ issuing ... as if
the silicon did some operations out-of-order and used issuance of the
IRQ as a kind of re-sync point.  Which kind of sucks ... it precluded
using some software polling schemes to shrink IRQ loads.

- Dave



-------------------------------------------------------------------------
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