On Tue, 2 Jul 2013, Martin van Es wrote: > On Tue, Jul 2, 2013 at 6:47 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2 Jul 2013, Martin van Es wrote: > > > > Maybe that's the explanation: The scanner isn't able to cope when the > > packets arrive too rapidly. It _is_ clear from the usbmon data that > > the scanner is at least slightly buggy. > > So the scanner might be incompatible with USB3 and maybe a USB2 hub > could alleviate these problems? > I know you can't give any guarantees, but is the idea plausible? I don't think a USB-2 hub will make any difference. Try it and see. > Isn't USB3 supposed to "scale back" when confronted with USB2 devices? Yes, USB-3 ports do "scale back" when connected to a USB-2 device -- and also when connected to a USB-3 device via a USB-2 cable. In your case, the port did "scale back"; otherwise it wouldn't have been able to communicate with the scanner at all. I was talking about how quickly the USB controller tells the CPU when a transfer is complete. A USB-1.1 controller (like your OHCI) will wait for up to 1 ms before telling the CPU; therefore adjacent transfers tend to occur at 1-ms intervals. A USB-2 controller (EHCI) will wait for up to 125 us before telling the CPU, so adjacent transfers tend to occur at 125-us intervals. The usbmon trace shows that your USB-3 controller (xHCI) waited about 60 us; that was roughly the interval between adjacent transfers. So even though each transfer took the same amount of time on OHCI and xHCI, with xHCI the time _between_ transfers was shorter by a factor of about 16. Therefore the scanner received packets much more rapidly. Alan Stern -- 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
