On 7/5/06, David Brownell <[EMAIL PROTECTED]> wrote: > To repeat myself: the instant the physical disconnect happens, > then pending transfers to that device's endpoints may trigger > USB transfer errors. And that can happen a LONG time before any > component of the USB stack (e.g. qh_completions) can know that > there was a disconnect.
To repeat myself: We agree in entirety. > If you think qh_completions() tears down endpoints, re-read it; intr_descedule(), as it appears in qh_completions, tears down the *scheduling* for an endpoint. > there is in fact a fair amount of effort to avoid doing that > (in favor of just leaving the QH marked "halted") because of > low level races that could trigger. I believe you, but I still see it happening reliably, 100% reliably, on every unplug. > And in any case, the only way qh_completions would reactivate > a halted endpoint is if its queue were non-empty after a fault > got reported. And that's solidly in the hands of the driver > which filled that queue. If the queue is logically one big > transfer, then the driver must already abort it on any fault. I plug in a hub. I unplug a hub. Nothing else happens in between and I see the resubmission loop happen until the disconnect code catches up and removes the hub's intr endpoint. Exactly what driver are you talking about? > I don't follow. If the device is idle, then there are no > URBs going to it, so qh_completions() will never be called. > When there's an URB queued, the device is actively polled. Then the simple act of having the hub plugged in means it's never actually idle. Since I assume everything you're saying is true and that my logs are telling me what's really happening, this is the only conclusion that currently makes sense. 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
