On Thu, 30 Jun 2005, Matthias Urlichs wrote: > Hi, Alan Stern schrub am Wed, 29 Jun 2005 10:46:39 -0400: > > > I'm afraid there's no way around it. Timeouts _have_ to work; pretty much > > every device driver depends on them crucially. The best way to fix this > > is to take care of those broken OPTi chip issues you mentioned. > > > And the best way to do *that* is to get hold of the mythical errata > document that says what the actual issues *are*, which unfortunately > I have not been able to do so far. :-(
After thinking some more, I'm puzzled by your earlier statement that the transfer "won't timeout because of broken OPTi chip issues". How can chip issues prevent a timeout from occurring? Timeouts are controlled by the kernel's main clock interrupt handler; if the clock was broken nothing could possibly work, right? Did you really mean that the transfer _did_ time out, but chip issues prevent the _unlink_ from working? > > Other things can be done, however. For instance, it might be a good idea > > to have the usb_remove_hcd routine unlink _all_ the pending URBs before > > calling usb_disconnect. But if the timeout were working this wouldn't be > > necessary. > > I'll have a look at that, thanks. If the unlink is broken then there's pretty much nothing you can do. The HCD drivers won't exit while there are still outstanding URBs. It doesn't matter what's locked or unlocked. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
