On 22/09/2010 11:36, Toby Gray wrote: > On 21/09/2010 23:01, Chris Frey wrote: >> On Tue, Sep 21, 2010 at 12:12:57PM +0100, Toby Gray wrote: >>> However there's clearly a reason for the call to usb_set_altinterface, >>> so can anyone remember what devices it was necessary for? >> It wasn't a specific device, it was all devices, I believe. It was to work >> around a change in the kernel, which caused odd timeout issues. Also, >> this fix made things work on Mac OSX and FreeBSD. >> >> The usb_set_altinterface() call is the only one in libusb that >> works directly with the interface, as far as I can tell. >> >> You can read the long, painstaking thread here. I ended up doing >> a git-bisect on the kernel to find the spot where it was having trouble. >> >> http://marc.info/?t=123554440300001&r=1&w=2 >> >> Especially here, where Alan Stern says that calling set_altinterface() >> should always be safe. >> >> http://marc.info/?l=linux-usb&m=123627088604495&w=2 >> > Thanks for those links. It sounds like setting the alternate setting to > 0 for the interface is needed to make the connection work reliably, but > that setting the alternate setting when URBs are outstanding on the > other (usb-storage) interface really confuses most BlackBerry devices > (although luckily not newer OSv5 ones as far as I can tell). > > It's odd that I don't see the original issue described in the above > thread on my Ubuntu 10.04 machine running 2.6.32, but as it was always a > timing related issue that doesn't seem too surprising. I've been able to reproduce this only in QEMU VMs (hosting on Ubuntu 10.04). Using VirtualBox as a VM (with Windows XP or Ubuntu 10.04 as host) leads to Barry not working at all (which is probably something to do with GET CONFIGURATION and SET INTERFACE requests never appearing in host USBmon traces).
I've had a play around with various other attempts at coming up with something which fixes the probe timeout issue and doesn't cause usb-storage to break and have had success with the following options: 1) Keep it how it is. If there is detection of 0 byte reads then it's now immediately obvious to users of Barry when the port has been reset, which is a considerably better user experience than hanging until the timeout occurs. 2) Change the probing code in src/probe.cc so that it tries probing the end points without a call to SET INTERFACE and then, if those probes fail, calls SET INTERFACE and probes again. I think it's probably best to probe all the end points and then call SET INTERFACE, rather than doing a probe, SET INTERFACE, and then a re-probe for each end point in turn. This would still have the usb-storage issue, but only for users where calling SET INTERFACE is necessary. 3) Use Paul O'Keefe's original usleep(100000) patch to solve this issue. This doesn't seem a great idea as arbitrary sleeps in code always worry me and this doesn't solve the issue for me in the VM. 4) Removing the calls to ClearHalt in Probe::PairProbe() and Controller::SetupUsb() also fixes this issue without needing to call SET INTERFACE. However the calls to ClearHalt are there to support the 8830 which does need them, so I'd suggest having the Probe::PairProbe() try to probe without clearing halt and then, if that fails, retrying after clearing halt. The ProbeResult would then contain whether clearing halt was necessary or not for that device, which would be used by Controller::SetupUsb() to determine if ClearHalt should be called. What's your feeling on which of these options is best? I would personally favour 4 as it seems to work nicely on the range of BlackBerry devices that I've tried. Regards, Toby ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Barry-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/barry-devel
