On Wed, 5 Jul 2006, Christopher Montgomery wrote: > On 7/5/06, Alan Stern <[EMAIL PROTECTED]> wrote: > > > Ummm... I've lost track of the original question. What is suboptimal and > > would be painful to fix? > > The fact that when I unplug a hub/device the ehci work handler is > descheduling/rescheduling the endpoints repeatedly [because each hit > in the hardware schedule is generating an EPROTO error] before other > code manages to eventually mark them disconnected.
ehci-hcd doesn't schedule endpoints; it schedules QHs. 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. > I am concerned the CPU spike could cause machines with slow CPUs to > miss servicing frames for other still-connected, active devices. That's why the URB submitter should throttle its activity. ehci-hcd can't do much about it. 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
