On Mon, Apr 11, 2011 at 10:28 AM, Graeme Gill <graeme2@xxxxxxxxxxxxx> wrote: > > I'm wondering if anyone has any insights into the likely nature > of a problem reported with a device that my software is driving. > > It's been a troublesome device from a hardware point of view, > particularly on Linux. On Linux it seems to get in a knot > when faced with a data read, the workaround being to issue > a reset EP prior to each read. I guess this could be > some sort of data toggle issue, because a first read will > work, and then the next read will time out. Interestingly > it doesn't happen with this device on MSWin or OS X. > > So the resetep workaround seems to work happily on Linux, unless the > device is on a secondary hub, whereupon it behaves as if > the reset EP's weren't being issued. > > I've seen this behaviour on Linux version 2.6.23.1-42 and latter, > but interestingly 2.6.9-55 using hotplug behaves differently > - it needs the resetep's, but works through a secondary hub OK. > > Traces from the Linux USB driver debug didn't seem to reveal anything > interesting - the problematic data read just hangs. > > So I have two questions: > > What's the likely nature of the underlying problem, and why > is it specific to Linux ? Hmm, assuming that you are using libusb, I think the issue would have gone with later kernels (say 2.6.32 or later). Alan Stern has already post a real patch to the kernel after the following RFC which was CCed to the libusb mailing list. I think you do not need the resetep work-around with later kernels. http://libusb.6.n5.nabble.com/RFC-Skip-sending-Set-Interface-during-driver-unbinding-td6073.html > Why doesn't the reset EP work through a secondary hub on modern > Linux versions ? > -- Xiaofan -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
