On Wed, 5 Jul 2006, Christopher Montgomery wrote: > /**************************** 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.
I'm hampered by lack of detailed knowledge of the driver. However it seems to me that those two calls should affect the schedule (cheap) and not the budget (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, That's right. Note what you said: the URB is resubmitted by core/hub.c. > > 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. Again, that's right. Since it has an active interrupt URB, it's not truly idle. It only seems that way. > > ehci-hcd doesn't schedule endpoints; it schedules QHs. > > Effectively the same thing. An INTR endpoint maps to one and only one > QH in the schedule. Yes, they are in a one-to-one relation. That doesn't make them the same thing. Precision of expression is important when discussing complicated topics. > > It won't > > reschedule a QH that has no pending URBs (or at least, it won't do this > > more than once for any QH). Each -EPROTO error will terminate an URB, so > > the activity can't continue indefinitely unless URBs continue to be > > submitted. > > The hub is plugged in doing nothing. It has no connected devices. I > unplug it. I log multiple EPROTO errors and see resubmission attemps > as well as schedule teardown/setup. Apparently there are always > pending URBs, so we're once again splitting hairs. No; we're trying to straighten out the confusion caused by you contradicting yourself. You pointed out earlier that hub.c resubmits the interrupt URB up to 10 times. After that it stops and there are no more pending URBs. So the offending activity should stop then as well. > > That's why the URB submitter should throttle its activity. ehci-hcd can't > > do much about it. > > ...except that ehci-hcd is what is resubmitting the URB. Go back and re-read what you yourself wrote above: the URB is resubmitted by core/hub.c. Not by ehci-hcd. > I'm not arguing with this. I'm looking for a way to avoid wasted > computation that *is* occurring. I'm not even claiming it's a huge > problem, just one I'd like to avoid if it's at all easy to do so. The way to avoid excess computation is to have intr_deschedule() and periodic_qh_schedule() do less work. There's no need to tear down and rebuild a scheduler budget when there's not going to be any net change. Alan Stern 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
