Documentation/driver-api/usb/error-codes.rst GitHub 원문 ↗

Linux 6.18.37 · Driver API

USB Error Codes

usb_submit_urb 반환값, URB·ISO completion status, hardware fault와 usbcore helper 오류 의미를 정리한 한국어 전문 번역입니다.

Source pathDocumentation/driver-api/usb/error-codes.rst
Source versionLinux v6.18.37
TranslationDUJINLABS 전문 번역 + 해설

요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.

1. 요약·해설

원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.

요약·해설

error-codes.rst:1-210

USB 오류는 제출 단계, HCD 전송 완료, ISO frame, device disconnect와 usbcore 동기 helper에서 서로 다른 의미로 나타납니다. Status는 completion handler에서만 읽고 부분 전송 길이와 controller별 fault 표현 차이를 함께 해석해야 합니다.

문서 구성
원문 줄핵심 내용
1-16오류 전달 계층
17-79usb_submit_urb() 반환값
80-99URB·ISO status 판독 규칙
100-177completion status 코드
178-210하드웨어 각주와 usbcore helper

2. 영어 원문 전체

번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.

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

3. 한국어 전문 번역

영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.

USB 오류 코드 개요

1-16

이 문서는 usbcore가 반환할 수 있는 모든 오류 코드와 그 해석을 정리합니다. 2004년 10월 21일에 개정되었습니다.

일부 오류는 Host Controller Driver(HCD)가 생성하고 device driver는 usbcore를 통해서만 봅니다. 원칙적으로 모든 HCD는 전송 속도에 따른 동작과 특정 fault를 보고하는 방식만 제외하면 같은 의미로 동작해야 합니다.

오류 코드 전달 계층
계층역할
USB device driverusbcore API 반환값과 URB completion status를 해석
usbcoreHCD 오류를 공통 USB 오류 의미로 전달
Host Controller Driver하드웨어 전송 결과와 fault를 보고
예외속도 의존 동작과 일부 fault code 선택은 HCD마다 다를 수 있음

.. _usb-error-codes:

USB Error codes
~~~~~~~~~~~~~~~

: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.

usb_submit_urb() 반환 코드

17-79

`usb_submit_urb()`의 일반 반환값에서 `0`은 URB 제출 성공을 뜻하고 `-ENOMEM`은 내부 구조체를 할당할 메모리가 없음을 뜻합니다.

USB 전용 제출 오류는 URB의 활성 상태, device·interface·endpoint 존재 여부, HCD 기능, 전송 유형과 주기, ISO frame 예약, pipe 유형, packet·buffer 크기, control setup packet, bandwidth, controller 상태와 suspend 상태를 검사하는 단계에서 발생합니다.

`usb_submit_urb()` 오류
코드의미
`0`URB 제출 성공
`-ENOMEM`내부 구조체 할당 메모리 부족
`-EBUSY`URB가 이미 활성 상태
`-ENODEV`지정한 USB device 또는 bus가 존재하지 않음
`-ENOENT`지정한 interface·endpoint가 없거나 enable되지 않음
`-ENXIO`HCD가 해당 URB 유형의 queueing을 지원하지 않음. host controller bug로 취급
`-EINVAL`전송 유형·주기 값이 잘못됐거나 미지원, ISO interval 변경 시도, 음수 `number_of_packets` 또는 기타 잘못된 인자
`-EXDEV`ISO에서 `URB_ISO_ASAP`이 없고 예약 가능한 frame이 모두 만료됨
`-EFBIG`HCD가 요청한 수의 ISO frame을 schedule할 수 없음
`-EPIPE`URB의 pipe 유형이 endpoint 실제 유형과 다름
`-EMSGSIZE`endpoint maxpacket이 0, ISO packet이 maxpacket보다 큼, 또는 전송 길이가 음수이거나 HCD 한계를 넘음
`-EBADR`control URB setup packet의 `wLength`가 `transfer_buffer_length`와 다름
`-ENOSPC`interrupt·isochronous 주기 전송용 USB bandwidth를 초과 예약하게 됨
`-ESHUTDOWN`우회할 수 없는 문제로 device 또는 host controller가 disable됨
`-EPERM``urb->reject`가 설정되어 제출 거부
`-EHOSTUNREACH`device가 suspend 상태라 URB 거부
`-ENOEXEC`control URB에 Setup packet이 없음

Error codes returned by :c:func:`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.

``-EBADR``                The wLength value in a control URB's setup packet does
                        not match the URB's transfer_buffer_length.

``-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.
=======================        =======================================================

URB와 ISO frame status 판독 규칙

80-99

`urb->status`와 ISO의 `iso_frame_desc[n].status`는 completion handler 안에서만 검사해야 합니다. 다른 위치에서 읽으면 한 CPU에서 HCD가 값을 갱신하는 동안 다른 CPU에서 device driver가 검사하는 race가 생길 수 있습니다.

오류가 보고되어도 `actual_length`는 양수일 수 있습니다. 전송은 흔히 여러 packet으로 구성되므로 오류가 이후 endpoint I/O를 중단하기 전에 일부 packet이 완료될 수 있기 때문입니다.

Isochronous URB의 `urb->status`는 URB가 unlink됐거나, device가 제거됐거나, host controller가 disable됐거나, 전체 전송 길이가 요청보다 짧고 `URB_SHORT_NOT_OK`가 설정된 경우에만 0이 아닙니다.

따라서 ISO completion handler의 `urb->status`에는 `0`, `-ENOENT`, `-ECONNRESET`, `-ESHUTDOWN`, `-EREMOTEIO`만 나타나야 합니다. 개별 frame descriptor의 status에는 더 다양한 코드가 올 수 있습니다.

Completion status를 읽는 순서
Completion handler 진입이 시점에만 `urb->status` 검사
`actual_length` 확인오류여도 완료된 packet만큼 양수일 수 있음
Isochronous URB전체 `urb->status`는 제한된 다섯 값만 기대
개별 ISO frame`iso_frame_desc[n].status`에서 세부 오류 확인

동시성과 부분 전송을 고려한 판독 흐름입니다.

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.

전송 완료 status 코드

100-177

완료 status의 `0`은 성공입니다. unlink 방식에 따라 동기식 `usb_unlink_urb()`는 `-ENOENT`, 비동기식 unlink는 `-ECONNRESET`을 남깁니다. `-EINPROGRESS`는 아직 결과가 없는 pending 상태이므로 completion handler에서 driver가 보게 되면 bug입니다.

`-EPROTO`, `-EILSEQ`, `-ETIME`은 bitstuff, CRC, 응답 시간 초과 또는 알 수 없는 USB 오류를 표현할 수 있습니다. controller hardware가 원인을 구별하지 못하는 경우가 많아 protocol 오류, device disconnect에 따른 무응답, 다른 fault를 driver가 확정할 수 없을 수 있습니다.

전송 오류가 있더라도 endpoint에서 반환한 data가 max packet 또는 남은 buffer를 넘으면 `-EOVERFLOW`, 짧은 read와 `URB_SHORT_NOT_OK` 조합이면 `-EREMOTEIO`가 됩니다. IN·OUT 방향에서 system memory 처리 속도가 USB data rate를 따라가지 못하는 경우에는 각각 `-ECOMM`, `-ENOSR`을 사용합니다.

URB completion과 ISO frame status
코드의미
`0`전송 성공
`-ENOENT``usb_unlink_urb()`로 동기 unlink됨
`-EINPROGRESS`URB가 pending 상태이며 아직 결과 없음. completion에서 보이면 bug
`-EPROTO`bitstuff 오류, bus turn-around 시간 내 응답 없음 또는 알 수 없는 USB 오류
`-EILSEQ`CRC 불일치, 응답 시간 초과 또는 알 수 없는 USB 오류
`-ETIME`규정된 bus turn-around 시간 안에 응답 packet이 없음. `-EPROTO`나 `-EILSEQ`로 보고될 수도 있음
`-ETIMEDOUT`동기 USB message가 완료되기 전에 timeout됐고 HC가 다른 오류를 보고하지 않음
`-EPIPE`endpoint stall. non-control endpoint는 `usb_clear_halt()`로 해제
`-ECOMM`IN data가 system memory에 기록할 수 있는 속도보다 빠르게 들어옴
`-ENOSR`OUT data를 system memory에서 USB 속도에 맞춰 가져오지 못함
`-EOVERFLOW`endpoint가 max packet 또는 남은 buffer보다 많은 data를 반환한 babble
`-EREMOTEIO`짧은 read가 발생했고 `urb->transfer_flags`에 `URB_SHORT_NOT_OK`가 설정됨
`-ENODEV`device 제거. hub driver가 즉시 감지하지 못해 다른 오류가 먼저 연속될 수 있음
`-EXDEV`ISO 전송이 일부만 완료됨. `iso_frame_desc[n].status`에만 설정
`-EINVAL`예상하지 못한 ISO 내부 오류
`-ECONNRESET``usb_unlink_urb()`로 비동기 unlink됨
`-ESHUTDOWN`물리적 disconnect 등 우회 불가능한 문제로 device 또는 host controller가 disable됨

===============================        ===============================================
0                                Transfer completed successfully

``-ENOENT``                        URB was synchronously unlinked by
                                :c:func:`usb_unlink_urb`

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

``-EPROTO`` [#f1]_, [#f2]_        a) bitstuff error
                                b) no response packet received within the
                                   prescribed bus turn-around time
                                c) unknown USB error

``-EILSEQ`` [#f1]_, [#f2]_        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`` [#f2]_                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`` [#f2]_                Endpoint stalled.  For non-control endpoints,
                                reset this status with
                                :c:func:`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`` [#f1]_                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
                                :c:func:`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.
===============================        ===============================================

하드웨어 fault 각주와 usbcore 함수

178-210

`-EPROTO`, `-EILSEQ`, `-EOVERFLOW` 같은 코드는 보통 device·firmware 불량이나 cable 문제 같은 hardware fault를 나타냅니다.

`-EPROTO`, `-EILSEQ`, `-ETIME`, `-EPIPE` 등은 host controller 종류에 따라 device disconnect 때문에 전송이 실패했음을 나타내는 코드로도 사용됩니다. Hub driver가 disconnect 처리를 시작하기 전까지 device의 모든 request에 이런 fault가 보고될 수 있습니다.

usbcore 함수는 아래 값 외에도 앞에서 설명한 제출 오류와 전송 status를 반환할 수 있습니다. `usb_register()`의 `-EINVAL`은 새 driver 등록 중 오류를 뜻합니다.

`usb_get_*()`·`usb_set_*()`, `usb_control_msg()`, `usb_bulk_msg()`의 `-ETIMEDOUT`은 전송이 완료되기 전에 timeout이 만료됐음을 뜻합니다.

usbcore helper 반환값
함수코드와 의미
`usb_register()``-EINVAL`: 새 driver 등록 중 오류
`usb_get_*()` / `usb_set_*()``-ETIMEDOUT`: 전송 완료 전 timeout
`usb_control_msg()``-ETIMEDOUT`: control message 완료 전 timeout
`usb_bulk_msg()``-ETIMEDOUT`: bulk message 완료 전 timeout
공통다른 submit 오류와 transfer status도 반환 가능

.. [#f1]

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

.. [#f2]

   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
=========================================

.. note:: expect also other submit and transfer status codes

:c:func:`usb_register`:

======================= ===================================
``-EINVAL``                error during registering new driver
======================= ===================================

``usb_get_*/usb_set_*()``,
:c:func:`usb_control_msg`,
:c:func:`usb_bulk_msg()`:

======================= ==============================================
``-ETIMEDOUT``                Timeout expired before the transfer completed.
======================= ==============================================