123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175 |
- Revised: 2004-Oct-21
- This is the documentation of (hopefully) all possible error codes (and
- their interpretation) that can be returned from usbcore.
- Some of them are returned by the Host Controller Drivers (HCDs), which
- device drivers only see through usbcore. As a rule, all the HCDs should
- behave the same except for transfer speed dependent behaviors and the
- way certain faults are reported.
- **************************************************************************
- * Error codes returned by usb_submit_urb *
- **************************************************************************
- Non-USB-specific:
- 0 URB submission went fine
- -ENOMEM no memory for allocation of internal structures
- USB-specific:
- -EBUSY The URB is already active.
- -ENODEV specified USB-device or bus doesn't exist
- -ENOENT specified interface or endpoint does not exist or
- is not enabled
- -ENXIO host controller driver does not support queuing of this type
- of urb. (treat as a host controller bug.)
- -EINVAL a) Invalid transfer type specified (or not supported)
- b) Invalid or unsupported periodic transfer interval
- c) ISO: attempted to change transfer interval
- d) ISO: number_of_packets is < 0
- e) various other cases
- -EXDEV ISO: URB_ISO_ASAP wasn't specified and all the frames
- the URB would be scheduled in have already expired.
- -EFBIG Host controller driver can't schedule that many ISO frames.
- -EPIPE The pipe type specified in the URB doesn't match the
- endpoint's actual type.
- -EMSGSIZE (a) endpoint maxpacket size is zero; it is not usable
- in the current interface altsetting.
- (b) ISO packet is larger than the endpoint maxpacket.
- (c) requested data transfer length is invalid: negative
- or too large for the host controller.
- -ENOSPC This request would overcommit the usb bandwidth reserved
- for periodic transfers (interrupt, isochronous).
- -ESHUTDOWN The device or host controller has been disabled due to some
- problem that could not be worked around.
- -EPERM Submission failed because urb->reject was set.
- -EHOSTUNREACH URB was rejected because the device is suspended.
- -ENOEXEC A control URB doesn't contain a Setup packet.
- **************************************************************************
- * Error codes returned by in urb->status *
- * or in iso_frame_desc[n].status (for ISO) *
- **************************************************************************
- USB device drivers may only test urb status values in completion handlers.
- This is because otherwise there would be a race between HCDs updating
- these values on one CPU, and device drivers testing them on another CPU.
- A transfer's actual_length may be positive even when an error has been
- reported. That's because transfers often involve several packets, so that
- one or more packets could finish before an error stops further endpoint I/O.
- For isochronous URBs, the urb status value is non-zero only if the URB is
- unlinked, the device is removed, the host controller is disabled, or the total
- transferred length is less than the requested length and the URB_SHORT_NOT_OK
- flag is set. Completion handlers for isochronous URBs should only see
- urb->status set to zero, -ENOENT, -ECONNRESET, -ESHUTDOWN, or -EREMOTEIO.
- Individual frame descriptor status fields may report more status codes.
- 0 Transfer completed successfully
- -ENOENT URB was synchronously unlinked by usb_unlink_urb
- -EINPROGRESS URB still pending, no results yet
- (That is, if drivers see this it's a bug.)
- -EPROTO (*, **) a) bitstuff error
- b) no response packet received within the
- prescribed bus turn-around time
- c) unknown USB error
- -EILSEQ (*, **) a) CRC mismatch
- b) no response packet received within the
- prescribed bus turn-around time
- c) unknown USB error
- Note that often the controller hardware does not
- distinguish among cases a), b), and c), so a
- driver cannot tell whether there was a protocol
- error, a failure to respond (often caused by
- device disconnect), or some other fault.
- -ETIME (**) No response packet received within the prescribed
- bus turn-around time. This error may instead be
- reported as -EPROTO or -EILSEQ.
- -ETIMEDOUT Synchronous USB message functions use this code
- to indicate timeout expired before the transfer
- completed, and no other error was reported by HC.
- -EPIPE (**) Endpoint stalled. For non-control endpoints,
- reset this status with usb_clear_halt().
- -ECOMM During an IN transfer, the host controller
- received data from an endpoint faster than it
- could be written to system memory
- -ENOSR During an OUT transfer, the host controller
- could not retrieve data from system memory fast
- enough to keep up with the USB data rate
- -EOVERFLOW (*) The amount of data returned by the endpoint was
- greater than either the max packet size of the
- endpoint or the remaining buffer size. "Babble".
- -EREMOTEIO The data read from the endpoint did not fill the
- specified buffer, and URB_SHORT_NOT_OK was set in
- urb->transfer_flags.
- -ENODEV Device was removed. Often preceded by a burst of
- other errors, since the hub driver doesn't detect
- device removal events immediately.
- -EXDEV ISO transfer only partially completed
- (only set in iso_frame_desc[n].status, not urb->status)
- -EINVAL ISO madness, if this happens: Log off and go home
- -ECONNRESET URB was asynchronously unlinked by usb_unlink_urb
- -ESHUTDOWN The device or host controller has been disabled due
- to some problem that could not be worked around,
- such as a physical disconnect.
- (*) Error codes like -EPROTO, -EILSEQ and -EOVERFLOW normally indicate
- hardware problems such as bad devices (including firmware) or cables.
- (**) 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.
- **************************************************************************
- * Error codes returned by usbcore-functions *
- * (expect also other submit and transfer status codes) *
- **************************************************************************
- usb_register():
- -EINVAL error during registering new driver
- usb_get_*/usb_set_*():
- usb_control_msg():
- usb_bulk_msg():
- -ETIMEDOUT Timeout expired before the transfer completed.
|