| 1 |
3 |
xianfeng |
Revised: 2004-Oct-21
|
| 2 |
|
|
|
| 3 |
|
|
This is the documentation of (hopefully) all possible error codes (and
|
| 4 |
|
|
their interpretation) that can be returned from usbcore.
|
| 5 |
|
|
|
| 6 |
|
|
Some of them are returned by the Host Controller Drivers (HCDs), which
|
| 7 |
|
|
device drivers only see through usbcore. As a rule, all the HCDs should
|
| 8 |
|
|
behave the same except for transfer speed dependent behaviors and the
|
| 9 |
|
|
way certain faults are reported.
|
| 10 |
|
|
|
| 11 |
|
|
|
| 12 |
|
|
**************************************************************************
|
| 13 |
|
|
* Error codes returned by usb_submit_urb *
|
| 14 |
|
|
**************************************************************************
|
| 15 |
|
|
|
| 16 |
|
|
Non-USB-specific:
|
| 17 |
|
|
|
| 18 |
|
|
|
| 19 |
|
|
|
| 20 |
|
|
-ENOMEM no memory for allocation of internal structures
|
| 21 |
|
|
|
| 22 |
|
|
USB-specific:
|
| 23 |
|
|
|
| 24 |
|
|
-ENODEV specified USB-device or bus doesn't exist
|
| 25 |
|
|
|
| 26 |
|
|
-ENOENT specified interface or endpoint does not exist or
|
| 27 |
|
|
is not enabled
|
| 28 |
|
|
|
| 29 |
|
|
-ENXIO host controller driver does not support queuing of this type
|
| 30 |
|
|
of urb. (treat as a host controller bug.)
|
| 31 |
|
|
|
| 32 |
|
|
-EINVAL a) Invalid transfer type specified (or not supported)
|
| 33 |
|
|
b) Invalid or unsupported periodic transfer interval
|
| 34 |
|
|
c) ISO: attempted to change transfer interval
|
| 35 |
|
|
d) ISO: number_of_packets is < 0
|
| 36 |
|
|
e) various other cases
|
| 37 |
|
|
|
| 38 |
|
|
-EAGAIN a) specified ISO start frame too early
|
| 39 |
|
|
b) (using ISO-ASAP) too much scheduled for the future
|
| 40 |
|
|
wait some time and try again.
|
| 41 |
|
|
|
| 42 |
|
|
-EFBIG Host controller driver can't schedule that many ISO frames.
|
| 43 |
|
|
|
| 44 |
|
|
-EPIPE Specified endpoint is stalled. For non-control endpoints,
|
| 45 |
|
|
reset this status with usb_clear_halt().
|
| 46 |
|
|
|
| 47 |
|
|
-EMSGSIZE (a) endpoint maxpacket size is zero; it is not usable
|
| 48 |
|
|
in the current interface altsetting.
|
| 49 |
|
|
(b) ISO packet is larger than the endpoint maxpacket.
|
| 50 |
|
|
(c) requested data transfer length is invalid: negative
|
| 51 |
|
|
or too large for the host controller.
|
| 52 |
|
|
|
| 53 |
|
|
-ENOSPC This request would overcommit the usb bandwidth reserved
|
| 54 |
|
|
for periodic transfers (interrupt, isochronous).
|
| 55 |
|
|
|
| 56 |
|
|
-ESHUTDOWN The device or host controller has been disabled due to some
|
| 57 |
|
|
problem that could not be worked around.
|
| 58 |
|
|
|
| 59 |
|
|
-EPERM Submission failed because urb->reject was set.
|
| 60 |
|
|
|
| 61 |
|
|
-EHOSTUNREACH URB was rejected because the device is suspended.
|
| 62 |
|
|
|
| 63 |
|
|
|
| 64 |
|
|
**************************************************************************
|
| 65 |
|
|
* Error codes returned by in urb->status *
|
| 66 |
|
|
* or in iso_frame_desc[n].status (for ISO) *
|
| 67 |
|
|
**************************************************************************
|
| 68 |
|
|
|
| 69 |
|
|
USB device drivers may only test urb status values in completion handlers.
|
| 70 |
|
|
This is because otherwise there would be a race between HCDs updating
|
| 71 |
|
|
these values on one CPU, and device drivers testing them on another CPU.
|
| 72 |
|
|
|
| 73 |
|
|
A transfer's actual_length may be positive even when an error has been
|
| 74 |
|
|
reported. That's because transfers often involve several packets, so that
|
| 75 |
|
|
one or more packets could finish before an error stops further endpoint I/O.
|
| 76 |
|
|
|
| 77 |
|
|
|
| 78 |
|
|
|
| 79 |
|
|
|
| 80 |
|
|
-ENOENT URB was synchronously unlinked by usb_unlink_urb
|
| 81 |
|
|
|
| 82 |
|
|
-EINPROGRESS URB still pending, no results yet
|
| 83 |
|
|
(That is, if drivers see this it's a bug.)
|
| 84 |
|
|
|
| 85 |
|
|
-EPROTO (*, **) a) bitstuff error
|
| 86 |
|
|
b) no response packet received within the
|
| 87 |
|
|
prescribed bus turn-around time
|
| 88 |
|
|
c) unknown USB error
|
| 89 |
|
|
|
| 90 |
|
|
-EILSEQ (*, **) a) CRC mismatch
|
| 91 |
|
|
b) no response packet received within the
|
| 92 |
|
|
prescribed bus turn-around time
|
| 93 |
|
|
c) unknown USB error
|
| 94 |
|
|
|
| 95 |
|
|
Note that often the controller hardware does not
|
| 96 |
|
|
distinguish among cases a), b), and c), so a
|
| 97 |
|
|
driver cannot tell whether there was a protocol
|
| 98 |
|
|
error, a failure to respond (often caused by
|
| 99 |
|
|
device disconnect), or some other fault.
|
| 100 |
|
|
|
| 101 |
|
|
-ETIME (**) No response packet received within the prescribed
|
| 102 |
|
|
bus turn-around time. This error may instead be
|
| 103 |
|
|
reported as -EPROTO or -EILSEQ.
|
| 104 |
|
|
|
| 105 |
|
|
-ETIMEDOUT Synchronous USB message functions use this code
|
| 106 |
|
|
to indicate timeout expired before the transfer
|
| 107 |
|
|
completed, and no other error was reported by HC.
|
| 108 |
|
|
|
| 109 |
|
|
-EPIPE (**) Endpoint stalled. For non-control endpoints,
|
| 110 |
|
|
reset this status with usb_clear_halt().
|
| 111 |
|
|
|
| 112 |
|
|
-ECOMM During an IN transfer, the host controller
|
| 113 |
|
|
received data from an endpoint faster than it
|
| 114 |
|
|
could be written to system memory
|
| 115 |
|
|
|
| 116 |
|
|
-ENOSR During an OUT transfer, the host controller
|
| 117 |
|
|
could not retrieve data from system memory fast
|
| 118 |
|
|
enough to keep up with the USB data rate
|
| 119 |
|
|
|
| 120 |
|
|
-EOVERFLOW (*) The amount of data returned by the endpoint was
|
| 121 |
|
|
greater than either the max packet size of the
|
| 122 |
|
|
endpoint or the remaining buffer size. "Babble".
|
| 123 |
|
|
|
| 124 |
|
|
-EREMOTEIO The data read from the endpoint did not fill the
|
| 125 |
|
|
specified buffer, and URB_SHORT_NOT_OK was set in
|
| 126 |
|
|
urb->transfer_flags.
|
| 127 |
|
|
|
| 128 |
|
|
-ENODEV Device was removed. Often preceded by a burst of
|
| 129 |
|
|
other errors, since the hub driver doesn't detect
|
| 130 |
|
|
device removal events immediately.
|
| 131 |
|
|
|
| 132 |
|
|
-EXDEV ISO transfer only partially completed
|
| 133 |
|
|
look at individual frame status for details
|
| 134 |
|
|
|
| 135 |
|
|
-EINVAL ISO madness, if this happens: Log off and go home
|
| 136 |
|
|
|
| 137 |
|
|
-ECONNRESET URB was asynchronously unlinked by usb_unlink_urb
|
| 138 |
|
|
|
| 139 |
|
|
-ESHUTDOWN The device or host controller has been disabled due
|
| 140 |
|
|
to some problem that could not be worked around,
|
| 141 |
|
|
such as a physical disconnect.
|
| 142 |
|
|
|
| 143 |
|
|
|
| 144 |
|
|
(*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
|
| 145 |
|
|
hardware problems such as bad devices (including firmware) or cables.
|
| 146 |
|
|
|
| 147 |
|
|
(**) This is also one of several codes that different kinds of host
|
| 148 |
|
|
controller use to indicate a transfer has failed because of device
|
| 149 |
|
|
disconnect. In the interval before the hub driver starts disconnect
|
| 150 |
|
|
processing, devices may receive such fault reports for every request.
|
| 151 |
|
|
|
| 152 |
|
|
|
| 153 |
|
|
|
| 154 |
|
|
**************************************************************************
|
| 155 |
|
|
* Error codes returned by usbcore-functions *
|
| 156 |
|
|
* (expect also other submit and transfer status codes) *
|
| 157 |
|
|
**************************************************************************
|
| 158 |
|
|
|
| 159 |
|
|
usb_register():
|
| 160 |
|
|
-EINVAL error during registering new driver
|
| 161 |
|
|
|
| 162 |
|
|
usb_get_*/usb_set_*():
|
| 163 |
|
|
usb_control_msg():
|
| 164 |
|
|
usb_bulk_msg():
|
| 165 |
|
|
-ETIMEDOUT Timeout expired before the transfer completed.
|
