Theodore Kilgore wrote: > > > On Thu, 14 May 2009, Randy Dunlap wrote: > >> Theodore Kilgore wrote: >>> >>> Working on a driver for the Sonix SN9C2028 dual-mode cameras, I am >>> confronted with the situation that certain usb_control_msg() functions >>> are failing and returning -32. Does anyone know how to look up what -32 >>> is supposed to mean? It appears not to be in the standard errno.h file, >>> so it would apparently be somewhere else. And the on-line man page for >>> usb_control_msg does not seem totally helpful. It says >>> >>> "If successful, it returns the number of bytes transferred; otherwise, >>> it returns a negative error number." >>> >>> but does not otherwise discuss the negative error numbers. >>> >>> However, I am getting things like >>> >>> f60a5680 1488371641 S Ci:5:022:0 s c1 00 0001 0000 0001 1 < >>> f60a5680 1488373478 C Ci:5:022:0 -32 1 = 0c >>> >>> using from the camera, and I do not quite know why. Incidentally, quite >>> aside from the error message, the returned value is also a bit screwy. >>> It ought to be 00 and for no obvious reason it is not. However, even if >>> the returned value is correct, which also can sometimes happen, the >>> error is still there. >>> >>> Also the debug statement from dmesg consistently says (the corresponding >>> function is called read1) >>> >>> sn9c20: read1 error -32 >>> >>> But, what is essentially the same command works just fine in libgphoto2, >>> giving debug output which looks like this >>> >>> f14ca880 2936498715 S Ci:5:023:0 s c1 00 0001 0000 0001 1 < >>> f14ca880 2936499630 C Ci:5:023:0 0 1 = 00 >>> >>> which shows no error and is doing what it should. >>> >>> So if someone knows where the declarations of these error codes are, it >>> might help me to track down what the problem is. >> >> You'll need to look in 2 places. >> Documentation/usb/error-codes.txt uses named error codes >> and include/asm-generic/errno*.h converts names<->numbers. >> >> So 32 is EPIPE (from errno-base.h) and error-codes.txt tells >> what EPIPE is used for in usb-land. > > Thanks. I looked it up now in error-codes.txt and I am still mystfied, > unfortunately. It says there > > -EPIPE (**) Endpoint stalled. For non-control endpoints, > reset this status with usb_clear_halt(). > > Well, it *is* a control pipe, so now what? It's still Endpoint stalled. The other sentence (For ...) just does not apply to your case. > The (**) refers to > > (**) This is also one of several codes that different kinds of host > controller use to indicate a transfer has failed because of device > disconnect. In the interval before the hub driver starts disconnect > processing, devices may receive such fault reports for every request. > > Well, the device did not otherwise appear to get disconnected. The > command sent is, basically, one of those "ping the camera" commands. As > pointed out, it works just fine if called (more indirectly, of course) > from libgphoto2, through libusb. > > > Of course, I could get something syntactically wrong when constructing > the commands. However, comparing > >>> f60a5680 1488371641 S Ci:5:022:0 s c1 00 0001 0000 0001 1 < >>> f60a5680 1488373478 C Ci:5:022:0 -32 1 = 0c > (from the embryonic sn9c2028 module) > > with > >>> f14ca880 2936498715 S Ci:5:023:0 s c1 00 0001 0000 0001 1 < >>> f14ca880 2936499630 C Ci:5:023:0 0 1 = 00 > (originating from libgphoto2/camlibs/sonix, with the same camera plugged > in) > > would surely indicate that the command was given the same way in both > cases. > > So, thanks, Randy, for pointing my nose in the right direction to > decipher the -32 error. > > But now, I am more puzzled than ever because I still can not figure out > how *that* could happen. > > Anyone have any good and clever ideas? I suggest that you ask on the USB mailing list (linux-usb@xxxxxxxxxxxxxxx). -- ~Randy LPC 2009, Sept. 23-25, Portland, Oregon http://linuxplumbersconf.org/2009/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
