On Wed, 1 Mar 2006, Pete Zaitcev wrote: > On Wed, 22 Feb 2006 15:28:02 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> > wrote: > > On Wed, 22 Feb 2006, Pete Zaitcev wrote: > > > > Frankly, I cannot fathom Alan's resistance to it when he actually > > > suggested > > > the main idea for the patch. > > > > I'm not at all resistant to the idea. It's just that the patch you wrote > > doesn't apply to the current USB development tree because of other, > > large-scale changes to the driver. As far as I can see, it should work > > fine on earlier kernels, i.e., anything < 2.6.17-rc1. > > I checked out your patches and it appears that they keep FSBR on as long as > there's an URB submitted.
That's right. The idea was to tune this behavior at some point in the future, after the current batch of changes had proved to be okay. In the meantime I've been busy with other things and haven't gotten around to doing it. In fact there's a prerequisite that I haven't written yet, either. When the driver scans a partially-completed URB, it should remove the TDs that have already finished from the schedule. Then it won't waste time scanning them again, and if a transfer gets stuck somewhere in the middle of an URB we'll know which TD to use for FSBR -- it will be the one at the start of the queue. > If that's the case, I am afraid there may be a > problem with that. I envision a scenario of a guy who has PCI bus hogged > by his UHCI executing FSBR whenever he has a USB serial device and something > like pilot-link, kermit, or getty opening the device. I remember someone > complaining that his I/O speed getting 5 times slower whenever he hooked > up his Pilot. The same thought had crossed my mind. Some devices (printers, for example) tend to use bulk transfers for intermittent notifications, something which interrupt transfers are better suited for. Such devices will consume extra PCI bandwidth until the driver is fixed up. > However, I tested the new driver at my laptops, and there was no such > effect on them (with Intel north- and southbridges). So, I think we best > proceed with what we have and fall back on my patch if a real-life problem > appears. I am attaching a version which works with the new UHCI, for > the archives. Okay, that seems reasonable. Thanks for updating your patch. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&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
