Alan Stern wrote:
On Fri, 3 Sep 2004, Toralf Lund wrote:
I'm having some problems with a custom USB device that communicates with a Linux host running usb-uhci (Red Hat Linux 9, kernel-2.4.20-31.9)
Simply put, bulk read (via libusb usb_bulk_read()) from the device will sometimes fail. [ ... ]
Sep 3 15:29:58 indonesia kernel: usb-uhci.c: interrupt, status 2, frame# 915
That doesn't mean anything useful.
That's what I thought.
In fact, that message has been eliminated in later kernel versions.
Sep 3 15:29:58 indonesia kernel: usbdevfs: USBDEVFS_BULK failed dev 2 ep 0x82 len 108 ret -84
Most of that is pretty clear. Device number, endpoint number + direction, transfer length. The return code -84 is -EILSEQ (you can find it in include/asm-generic/errno.h),
Yes. The error id or generic description doesn't tell me a lot, however.
and according to Documentation/usb/error-codes.txt, -EILSEQ is a CRC mismatch.... but this does, of course. The problem was that it never occured to me to look in the Documentation directory.
In other words, the received packet was invalid -- either it was transmitted wrong or it got garbled.Could it be that it was never transferred at all? That looks more likely based on the state of the device; it seems like it's waiting to send data at the point where the problems occur, which might mean that it somehow missed the the data request from the host, or that it was never sent.
Yes. Something I wondered about was if the timeout in question was indeed the one my program specifies - and not one internal to the driver.Sep 3 15:30:01 indonesia kernel: usb_control/bulk_msg: timeout
Sep 3 15:30:01 indonesia kernel: usbdevfs: USBDEVFS_BULK failed dev 2 ep 0x82 len 32 ret -110
Timeout again is pretty clear. Also -110 is -ETIMEDOUT. The device failed to complete the bulk-in request within the time limit specified by your program.
Sep 3 15:30:04 indonesia kernel: usb_control/bulk_msg: timeout
Sep 3 15:30:04 indonesia kernel: usbdevfs: USBDEVFS_BULK failed dev 2 ep 0x82 len 32 ret -110
Same as before.
Also, is there anything else I can do to make it easier to track down the problem? It is probably a device error, but can the driver help me identify it?
Maybe it's not a device problem, maybe it's a bad cable connection. It's impossible to say for sure, since all you know is what the computer received. At this point you probably know almost everything that the driver knows. But you could try looking at the source code for the driver; there might DEBUG options that have been disabled. If you enable them maybe you'll learn more.
Yeah, I guess I may have to try that.
BTW, I just tested with a cable that I think has quite definitely gone bad, and got similar behaviour, then - but there seemed to be a lot more going on in terms of reset signalling etc.
Alan Stern
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
