On Fri, 2004-01-23 at 15:55, Alan Stern wrote: > > The patch works ... sort of (:-)). It seems to effectively prevent the > > urb-gets-not-unlinked problem. But on the other hand, it has the same > > problem than my mentioned panic workaround. In my case the urb gets > > dequeued when the resume interrupt occurs after the replugging. > > I don't understand. Your URB doesn't get unlinked until after you replug? > The patch was specifically supposed to fix that. The URB should be > unlinked within a fraction of a second after you unplug. It should happen > either when the controller detects a communication problem or when > hcd_endpoint_disable is called.
Sorry, my englisch is obviously not "specific" enough. I'll try to improve: - with your patch the urb gets unlinked when the controller suspends, that happens about a second after the unplugging. - without your patch the urb gets unlinked after the replug. The result at the end seemed to be the same: my device did not enumerate anymore. And this enumeration seemed to fail in a similar way than my test program, there seems to be a pending urb that does not get removed properly if the device gets unplugged again. I tried only a few times, maybe there is some non-determinism involved here as well. > If everything worked correctly at unplug time, there shouldn't be any > problems when you replug. A timeout like this is more likely to be the > result of a bad cable connection or a device error. I thought maybe that "missing" SOF/EOF interrupt, tried to provoke with set_next_interrupt in urb_dequeue, is indeed missing (meaning it actually should occurs even in this situation) and that the controller got indeed in an "ill" state where subsequent enumerations fail. I tried to provoke this interrupt with the cat /proc/drivers/uhci/... trick after the disconnect but before the suspend and it did not work. I read something about a deferred interrupt delivery when a transaction is still in progress in the uhci spec. But I don't know how that fits with the claim that "every 1 ms there is going to be a SOF, whatever the devices may do". Axel. ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
