On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote:
> > ) before
> > deciding the endpoint EPROTO fault calls for tearing it down and
> > setting it back up. Active/submitted URBs potentially have nothing to
> > do with it; it is happening even when my devices are idle.
>
> I'm not terribly familiar with ehci-hcd. Where in qh_completions() does
> the code tear something down and then set it back up again? What does it
> tear down?
/* be sure the hardware's done with the qh before refreshing
* it after fault cleanup, or recovering from silicon wrongly
* overlaying the dummy qtd (which reduces DMA chatter).
*/
if (stopped != 0 || qh->hw_qtd_next == EHCI_LIST_END) {
switch (state) {
case QH_STATE_IDLE:
qh_refresh(ehci, qh);
break;
case QH_STATE_LINKED:
/* should be rare for periodic transfers,
* except maybe high bandwidth ...
*/
if ((__constant_cpu_to_le32 (QH_SMASK)
& qh->hw_info2) != 0) {
/**************************** the two lines below *****************************/
intr_deschedule (ehci, qh);
(void) periodic_qh_schedule (ehci, qh);
} else
unlink_async (ehci, qh);
break;
/* otherwise, unlink already started */
}
}
It is tearing down the hardware schedule [and in my new scheduler,
also the shadow budget] for the given endpoint. The computation of
the schedule/budget is expensive.
> In fact, where in qh_completions() does the code even check for -EPROTO?
It doesn't. The EPROTO is being 'handled' in core/hub.c:hub_irq(),
which resubmits the transaction ten times before alling through. The
comment for the fall-through is 'let khubd handle it'. AFAICT,
qh_completions() is either being called as part of collateral damage
from this process (but I don't know the exact code flow; I only see
the cause/effect in the logs) or is being called simply because
there's still an active QH in the schedule for a disconnected
endpoint. What's clear is that qh_completions() is doing the
deschedule/reschedule.
> When the devices are idle, how can qh_completions() possibly have any work
> to do at all?
>From what I've seen in the logs, a hub always appears to have at least
one active interrupt endpoint in the schedule even when it's not doing
anything. I only know usb from the scheduler down; I've no real
understanding of the higher level device types and how they're set up.
Monty
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
