On Tue, 14 Apr 2015, Graeme Gill wrote: > Hi, > > I have a user reporting a problem with a particular USB HID device > on Linux that I suspect is a Linux driver issue, or possibly > a failure in my (user mode driver) to handle an unexpected > Linux USB response. > > The device is an X-Rite ColorMunki Display colorimeter (== i1d3). I've not > seen any issues with this device in my testing on (older version of) Linux, > and can't reproduce the problem: > > Peter Wiesboeck wrote: > > On my new computer dispcal dosn't work. > > OS is Ubutu 14.10 (64 Bit), ArgyllCMS version is 1.6.3 (64Bit-Version). > > Colorimeter is Colormunki Display. This device works well on my old machine > > Ubuntu 14.4 (32 Bit) as well as on Win7. > > I tested different USB-Ports but without any success. > > Dispcal is started with command `dispcal -v -yl -ql -d1 -D6 -o viewsonic`. > > Some times it fails on cmd 'GetLockedStatus', some times at cmd > > 'ReadInternalEEPROM' > > Attached is the debug output of the ArgyllCMS instrument driver, plus > a usbmon trace. One of a couple of transactions returns an error from > the Linux USB driver after initially communicating successfully. > My (user mode) driver returns an "ICOM err 0x100" if the urb.status > has a value < 0 and it's not -ECONNRESET > > The Colormunki is on Bus 3 Device 6. > > The interrupt data read that fails seems to return error -71, EPROTO > > Does anyone have any insights into the nature and cause of this error ?
-71 is a low-level communication error. It generally means that the computer did not receive a reply packet that it was expecting, or the packet it received was corrupted. Two possibilities seem most likely. First, the device itself might be a little flakey. The usbmon trace shows several places where communication errors occurred. The first two were during enumeration, and the system recovered simply by retrying the failed transfers. The third was while the user-mode driver was running (the -71 error you encountered). The driver did not attempt to retry the failed transfer; it just gave up. Second, it's possible that the device isn't interacting well with the xHCI host controller on the computer. People have reported similar behavior in the past: Devices that are a little bit on the edge will work okay with EHCI or OHCI but occasionally fail with xHCI. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
