USB Error codes

Revised:

2004-Oct-21

This is the documentation of (hopefully) all possible error codes (andtheir interpretation) that can be returned from usbcore.

Some of them are returned by the Host Controller Drivers (HCDs), whichdevice drivers only see through usbcore. As a rule, all the HCDs shouldbehave the same except for transfer speed dependent behaviors and theway certain faults are reported.

Error codes returned byusb_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 oris not enabled

-ENXIO

host controller driver does not support queuing ofthis type of urb. (treat as a host controller bug.)

-EINVAL

  1. Invalid transfer type specified (or not supported)

  2. Invalid or unsupported periodic transfer interval

  3. ISO: attempted to change transfer interval

  4. ISO:number_of_packets is < 0

  5. various other cases

-EXDEV

ISO:URB_ISO_ASAP wasn’t specified and all theframes the URB would be scheduled in have alreadyexpired.

-EFBIG

Host controller driver can’t schedule that many ISOframes.

-EPIPE

The pipe type specified in the URB doesn’t match theendpoint’s actual type.

-EMSGSIZE

  1. endpoint maxpacket size is zero; it is not usablein the current interface altsetting.

  2. ISO packet is larger than the endpoint maxpacket.

  3. requested data transfer length is invalid: negativeor too large for the host controller.

-EBADR

The wLength value in a control URB’s setup packet doesnot match the URB’s transfer_buffer_length.

-ENOSPC

This request would overcommit the usb bandwidth reservedfor periodic transfers (interrupt, isochronous).

-ESHUTDOWN

The device or host controller has been disabled due tosome problem that could not be worked around.

-EPERM

Submission failed becauseurb->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 byinurb->status or iniso_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 updatingthese 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 beenreported. That’s because transfers often involve several packets, so thatone 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 isunlinked, the device is removed, the host controller is disabled, or the totaltransferred length is less than the requested length and theURB_SHORT_NOT_OK flag is set. Completion handlers for isochronous URBsshould only seeurb->status set to zero,-ENOENT,-ECONNRESET,-ESHUTDOWN, or-EREMOTEIO. Individual frame descriptor status fieldsmay report more status codes.

0

Transfer completed successfully

-ENOENT

URB was synchronously unlinked byusb_unlink_urb()

-EINPROGRESS

URB still pending, no results yet(That is, if drivers see this it’s a bug.)

-EPROTO[1],[2]

  1. bitstuff error

  2. no response packet received within theprescribed bus turn-around time

  3. unknown USB error

-EILSEQ[1],[2]

  1. CRC mismatch

  2. no response packet received within theprescribed bus turn-around time

  3. unknown USB error

Note that often the controller hardware doesnot distinguish among cases a), b), and c), soa driver cannot tell whether there was aprotocol error, a failure to respond (oftencaused by device disconnect), or some otherfault.

-ETIME[2]

No response packet received within theprescribed bus turn-around time. This errormay instead be reported as-EPROTO or-EILSEQ.

-ETIMEDOUT

Synchronous USB message functions use this codeto indicate timeout expired before the transfercompleted, and no other error was reportedby HC.

-EPIPE[2]

Endpoint stalled. For non-control endpoints,reset this status withusb_clear_halt().

-ECOMM

During an IN transfer, the host controllerreceived data from an endpoint faster than itcould be written to system memory

-ENOSR

During an OUT transfer, the host controllercould not retrieve data from system memory fastenough to keep up with the USB data rate

-EOVERFLOW[1]

The amount of data returned by the endpoint wasgreater than either the max packet size of theendpoint or the remaining buffer size.“Babble”.

-EREMOTEIO

The data read from the endpoint did not fillthe specified buffer, andURB_SHORT_NOT_OKwas set inurb->transfer_flags.

-ENODEV

Device was removed. Often preceded by a burstof other errors, since the hub driver doesn’tdetect device removal events immediately.

-EXDEV

ISO transfer only partially completed(only set iniso_frame_desc[n].status,noturb->status)

-EINVAL

ISO madness, if this happens: Log off andgo home

-ECONNRESET

URB was asynchronously unlinked byusb_unlink_urb()

-ESHUTDOWN

The device or host controller has beendisabled due to some problem that could notbe worked around, such as a physicaldisconnect.

[1](1,2,3)

Error codes like-EPROTO,-EILSEQ and-EOVERFLOW normallyindicate hardware problems such as bad devices (including firmware)or cables.

[2](1,2,3,4)

This is also one of several codes that different kinds of hostcontroller use to indicate a transfer has failed because of devicedisconnect. In the interval before the hub driver starts disconnectprocessing, devices may receive such fault reports for every request.

Error codes returned by usbcore-functions

Note

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.